Bi yakozunaren gudua, edo Cassandra vs HBase. Sberbank taldearen esperientzia

Hau ez da txantxa bat ere, badirudi irudi zehatz honek datu-base horien funtsa islatzen duela zehatzen, eta azkenean argi geratuko da zergatik:

DB-Engines Ranking-en arabera, NoSQL zutabe-datu-base ezagunenak Cassandra (aurrerantzean CS) eta HBase (HB) dira.

Patuaren borondatearen arabera, Sberbank-eko gure datuak kargatzeko kudeaketa taldeak dagoeneko egin du aspaldi eta HBrekin lankidetza estuan lan egiten du. Denbora horretan, bere indarguneak eta ahuleziak nahiko ondo aztertu genituen eta sukaldatzen ikasi genuen. Dena den, CS moduan alternatiba bat egoteak beti behartu gintuen geure burua apur bat oinazea dudaz: aukera egokia egin al dugu? Gainera, emaitzak konparazioak, DataStax-ek egindakoa, esan zuten CSk erraz irabazten duela HB ia puntuazio birringarriarekin. Bestalde, DataStax interesdun bat da, eta ez zenuke haien hitza hartu behar. Proba-baldintzei buruzko informazio kopuru txiki samarra ere nahastu gintuzten, beraz, BigData NoSql-en erregea nor den gure kabuz jakitea erabaki genuen, eta lortutako emaitzak oso interesgarriak izan ziren.

Hala ere, egindako proben emaitzei ekin baino lehen, beharrezkoa da ingurunearen konfigurazioen alderdi esanguratsuak deskribatzea. Kontua da CS datuak galtzea ahalbidetzen duen moduan erabil daitekeela. Horiek. hau da, zerbitzari (nodo) bakarra gako jakin baten datuez arduratzen denean, eta arrazoiren batengatik huts egiten badu, orduan gako honen balioa galduko da. Zeregin askotan hori ez da kritikoa, baina banku-sektorearentzat araua baino salbuespena da. Gure kasuan, garrantzitsua da datuen hainbat kopia edukitzea fidagarri biltegiratzeko.

Hori dela eta, erreplikazio hirukoitzeko moduan CS funtzionamendu-modua bakarrik hartu zen kontuan, hau da. Kasu-espazioaren sorrera parametro hauekin egin da:

CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};

Ondoren, behar den koherentzia-maila bermatzeko bi modu daude. Arau orokorra:
NW + NR > RF

Horrek esan nahi du nodoen baieztapenen kopurua idaztean (NW) gehi nodoen baieztapenen kopurua irakurtzean (NR) erreplikazio-faktorea baino handiagoa izan behar dela. Gure kasuan, RF = 3, hau da, aukera hauek egokiak dira:
2 + 2 > 3
3 + 1 > 3

Guretzat datuak ahalik eta fidagarrien gordetzea funtsezkoa denez, 3+1 eskema aukeratu zen. Horrez gain, HBk antzeko printzipio batean lan egiten du, hau da. konparaketa hori justuagoa izango da.

Kontuan izan behar da DataStax-ek bere azterketan alderantziz egin zuela, RF = 1 ezarri zutela bai CS bai HBrako (azken honetarako HDFS ezarpenak aldatuz). Alderdi benetan garrantzitsua da, kasu honetan CSren errendimenduan eragina handia delako. Adibidez, beheko irudian datuak CSn kargatzeko behar den denboraren hazkundea erakusten da:

Hemen honako hau ikusten dugu: zenbat eta hari lehiakide gehiago idatzi datuak, orduan eta denbora gehiago behar da. Hau naturala da, baina garrantzitsua da RF=3-ren errendimenduaren degradazioa nabarmen handiagoa izatea. Beste era batera esanda, bakoitzean 4 tauletan 5 hari idazten baditugu (20 guztira), orduan RF=3 2 aldiz gutxi gorabehera galtzen da (150 segundo RF=3 eta 75 RF=1). Baina karga handitzen badugu datuak 8 hari dituzten 5 taulatan kargatuz (guztira 40), orduan RF=3 galera 2,7 aldiz da jada (375 segundo eta 138).

Agian hau da, neurri batean, DataStax-ek CS-rako egindako karga proba arrakastatsuaren sekretua, gure standeko HBrentzat 2tik 3ra erreplikazio-faktorea aldatzeak ez zuelako inolako eraginik izan. Horiek. diskoak ez dira gure konfiguraziorako HBko botila-lepoa. Dena den, hemen beste hondamendi asko daude, kontuan izan behar baita gure HBren bertsioa apur bat adabaki eta moldatua zegoela, inguruneak guztiz desberdinak direla, etab. Aipatzekoa da, halaber, agian ez dakidala CS behar bezala prestatzen eta badirela lan egiteko modu eraginkorragoak, eta espero dut iruzkinetan jakitea. Baina lehenik eta behin.

Proba guztiak 4 zerbitzariz osatutako hardware-kluster batean egin ziren, bakoitza konfigurazio honekin:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 hari.
Diskoak: 12 pieza SATA HDD
java bertsioa: 1.8.0_111

CS bertsioa: 3.11.5

cassandra.yml parametroaktoken_zenbakia: 256
hinted_handoff_enabled: egia
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_direktorioa: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
autentifikatzailea: AllowAllAuthenticator
baimentzailea: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
partitzailea: org.apache.cassandra.dht.Murmur3Partitioner
datu_fitxategi_direktorioak:
- /data1/cassandra/data # dataN direktorio bakoitza disko bereizia da
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_direktorioa: /data9/cassandra/commitlog
cdc_enabled: false
disk_failure_policy: gelditu
commit_failure_policy: gelditu
prepared_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
row_cache_size_in_mb: 0
row_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
gordetako_caches_direktorioa: /data10/cassandra/saved_caches
commitlog_sync: periodikoa
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
hazia_hornitzailea:
- klase_izena: org.apache.cassandra.locator.SimpleSeedProvider
parametroak:
- haziak: "*,*"
concurrent_reads: 256 # saiatu 64 - ez da alderik nabaritu
concurrent_writes: 256 # saiatu 64 - ez da alderik nabaritu
concurrent_counter_writes: 256 # saiatu 64 - ez da alderik nabaritu
aldibereko_materializatutako_ikuspegiak: 32
memtable_heap_space_in_mb: 2048 # saiatu 16 GB - motelagoa zen
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: faltsua
trickle_fsync_interval_in_kb: 10240
biltegiratze_portua: 7000
ssl_storage_port: 7001
entzun_helbidea: *
igorpen_helbidea: *
listen_on_broadcast_address: egia
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
hasiera_bertako_garraioa: egia
jatorrizko_garraioa_garraioa: 9042
start_rpc: egia
rpc_helbidea: *
rpc_port: 9160
rpc_keepalive: egia
rpc_server_type: sinkronizazioa
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: faltsua
auto_snapshot: egia
zutabe_indizearen_tamaina_kb: 64
zutabe_indizea_cache_tamaina_kb: 2
aldibereko_konpaktatzaileak: 4
compactation_throughput_mb_sec_per: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
write_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: false
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: bat ere ez
client_encryption_options:
gaituta: false
barnekode_konpresioa: dc
inter_dc_tcp_nodelay: faltsua
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
garden_data_encryption_options:
gaituta: false
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compactation_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: faltsua
enable_materialized_views: egia
enable_sasi_indexes: egia

GC ezarpenak:

### CMS ezarpenak-XX:+ErabiliParNewGC
-XX:+ErabiliConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+Erabili CMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

jvm.options memoria 16Gb esleitu zen (32 Gb ere saiatu ginen, ez zen desberdintasunik nabaritu).

Taulak komandoarekin sortu dira:

CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};

HB bertsioa: 1.2.0-cdh5.14.2 (org.apache.hadoop.hbase.regionserver.HRegion klasean MetricsRegion baztertu genuen eta horrek GCra eraman zuen RegionServer-en eskualde kopurua 1000 baino gehiagokoa zenean)

Lehenetsiak ez diren HBase parametroakzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minutu(s)
hbase.client.scanner.timeout.period: 2 minutu(s)
hbase.master.handler.kopurua: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minutu(s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 ordu(s)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.tamaina: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 egun
HBase Zerbitzuaren konfigurazio aurreratuaren zatia (segurtasun balbula) hbase-site.xml-rako:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.handi12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase RegionServer-erako Java konfigurazio aukerak:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minutu(s)
hbase.snapshot.region.timeout: 2 minutu(s)
hbase.snapshot.master.timeout.millis: 2 minutu(s)
HBase REST zerbitzariaren gehienezko erregistroaren tamaina: 100 MiB
HBase REST zerbitzariaren erregistro-fitxategien gehieneko babeskopiak: 5
HBase Thrift zerbitzariaren gehienezko erregistroaren tamaina: 100 MiB
HBase Thrift zerbitzariaren gehieneko erregistro-fitxategien babeskopiak: 5
Gehienezko erregistroaren tamaina: 100 MiB
Gehienezko erregistro-fitxategien babeskopiak: 5
RegionServer Gehienezko erregistroaren tamaina: 100 MiB
RegionServer Log-fitxategien gehieneko babeskopiak: 5
HBase Active Master detektatzeko leihoa: 4 minutu(s)
dfs.client.hedged.read.threadpool.tamaina: 40
dfs.client.hedged.read.threshold.millis: 10 milisegundo(s)
hbase.atseden.hariak.min: 8
hbase.rest.hariak.gehienez: 150
Gehienezko Prozesu-fitxategien deskribatzaileak: 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.hariak: 30
hbase.master.executor.closeregion.hariak: 30
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.tamaina: 20
Eskualde-mugitzaileen hariak: 6
Bezeroaren Java Heap Tamaina bytetan: 1 GiB
HBase REST zerbitzariaren talde lehenetsia: 3 GiB
HBase Thrift Server Talde lehenetsia: 3 GiB
HBase Master-aren Java Heap Tamaina bytetan: 16 GiB
HBase RegionServer-en Java heap tamaina bytetan: 32 GiB

+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Taulak sortzea:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
aldatu 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

Puntu garrantzitsu bat dago hemen: DataStax deskribapenak ez du esaten zenbat eskualde erabili ziren HB taulak sortzeko, hau garrantzitsua den arren bolumen handietarako. Hori dela eta, probetarako kantitatea = 64 aukeratu da, eta horrek 640 GB-ra arte gordetzeko aukera ematen du, hau da. tamaina ertaineko mahaia.

Proba egiteko garaian, HBase-k 22 mila taula eta 67 mila eskualde zituen (hau hilgarria izango zen 1.2.0 bertsiorako, goian aipatutako adabakiagatik ez balitz).

Orain kodea. Datu-base jakin baterako zein konfigurazio ziren onuragarriagoak ez zeudenez, probak hainbat konbinaziotan egin ziren. Horiek. proba batzuetan, 4 taula kargatu ziren aldi berean (4 nodo guztiak konexiorako erabili ziren). Beste probetan 8 mahai ezberdinekin aritu ginen. Zenbait kasutan, lotearen tamaina 100ekoa zen, beste batzuetan 200ekoa (lotearen parametroa - ikusi beheko kodea). Balioaren datuen tamaina 10 byte edo 100 byte da (dataSize). Guztira, 5 milioi erregistro idatzi eta irakurri ziren taula bakoitzean aldi bakoitzean. Aldi berean, taula bakoitzean 5 hari idatzi/irakurtu ziren (hariaren zenbakia - thNum), eta horietako bakoitzak bere gako sorta erabili zuen (zenbaketa = 1 milioi):

if (opType.equals("insert")) {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        StringBuilder sb = new StringBuilder("BEGIN BATCH ");
        for (int i = 0; i < batch; i++) {
            String value = RandomStringUtils.random(dataSize, true, true);
            sb.append("INSERT INTO ")
                    .append(tableName)
                    .append("(id, title) ")
                    .append("VALUES (")
                    .append(key)
                    .append(", '")
                    .append(value)
                    .append("');");
            key++;
        }
        sb.append("APPLY BATCH;");
        final String query = sb.toString();
        session.execute(query);
    }
} else {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        StringBuilder sb = new StringBuilder("SELECT * FROM ").append(tableName).append(" WHERE id IN (");
        for (int i = 0; i < batch; i++) {
            sb = sb.append(key);
            if (i+1 < batch)
                sb.append(",");
            key++;
        }
        sb = sb.append(");");
        final String query = sb.toString();
        ResultSet rs = session.execute(query);
    }
}

Horren arabera, antzeko funtzionaltasuna eman zitzaion HBri:

Configuration conf = getConf();
HTable table = new HTable(conf, keyspace + ":" + tableName);
table.setAutoFlush(false, false);
List<Get> lGet = new ArrayList<>();
List<Put> lPut = new ArrayList<>();
byte[] cf = Bytes.toBytes("cf");
byte[] qf = Bytes.toBytes("value");
if (opType.equals("insert")) {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        lPut.clear();
        for (int i = 0; i < batch; i++) {
            Put p = new Put(makeHbaseRowKey(key));
            String value = RandomStringUtils.random(dataSize, true, true);
            p.addColumn(cf, qf, value.getBytes());
            lPut.add(p);
            key++;
        }
        table.put(lPut);
        table.flushCommits();
    }
} else {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        lGet.clear();
        for (int i = 0; i < batch; i++) {
            Get g = new Get(makeHbaseRowKey(key));
            lGet.add(g);
            key++;
        }
        Result[] rs = table.get(lGet);
    }
}

HBn bezeroak datuen banaketa uniformeaz arduratu behar duenez, gatz-funtzioak honelakoa izan zen:

public static byte[] makeHbaseRowKey(long key) {
    byte[] nonSaltedRowKey = Bytes.toBytes(key);
    CRC32 crc32 = new CRC32();
    crc32.update(nonSaltedRowKey);
    long crc32Value = crc32.getValue();
    byte[] salt = Arrays.copyOfRange(Bytes.toBytes(crc32Value), 5, 7);
    return ArrayUtils.addAll(salt, nonSaltedRowKey);
}

Orain zatirik interesgarriena - emaitzak:

Gauza bera grafiko moduan:

HBren abantaila hain da harrigarria non CS konfigurazioan botila-leporen bat dagoela susmoa dagoela. Hala ere, Google-k eta parametrorik nabarmenenak bilatzea (concurrent_writes edo memtable_heap_space_in_mb) ez zuen gauzak azkartu. Aldi berean, enborrak garbi daude eta ez dute ezer zin egiten.

Datuak uniformeki banatu ziren nodoetan, nodo guztien estatistikak gutxi gorabehera berdinak ziren.

Hau da taularen estatistikak nodoetako baten itxuraKeyspace: ks
Irakurketa kopurua: 9383707
Irakurtzeko Latentzia: 0.04287025042448576 ms
Idatzi kopurua: 15462012
Idazteko latentzia: 0.1350068438699957 ms
Zain dauden husketak: 0
Taula: t1
SSTtable kopurua: 16
Erabilitako espazioa (zuzenekoa): 148.59 MiB
Erabilitako espazioa (guztira): 148.59 MiB
Argazkiek erabiltzen duten espazioa (guztira): 0 byte
Erabilitako memoria-pilatik kanpo (guztira): 5.17 MiB
SSTegonko konpresio-erlazioa: 0.5720989576459437
Tabike kopurua (aurreikuspena): 3970323
Memoragarria den zelula kopurua: 0
Datu metagarrien tamaina: 0 byte
Erabilitako memoria-memtable off memoria: 0 byte
Memtable switch kopurua: 5
Tokiko irakurketa kopurua: 2346045
Irakurketa lokaleko latentzia: NaN ms
Tokiko idazketa kopurua: 3865503
Idazketa lokalaren latentzia: NaN ms
Hustuketa zain daudenak: 0
Konpontzen den ehunekoa: 0.0
Bloom iragazkia positibo faltsuak: 25
Bloom-iragazkiaren erlazio faltsua: 0.00000
Erabilitako Bloom iragazki espazioa: 4.57 MiB
Bloom-iragazkia erabilitako memoria-pilatik kanpo: 4.57 MiB
Erabilitako pila-memoriaren laburpena: 590.02 KiB
Erabilitako pila-memoritik kanpoko konpresioaren metadatuak: 19.45 KiB
Partizio trinkotua gutxieneko byte: 36
Partizio trinkotua gehienezko byte: 42
Partizio trinkotutako batez besteko byteak: 42
Batez besteko zelula biziak zati bakoitzeko (azken bost minutu): NaN
Gehienezko zelula biziak zati bakoitzeko (azken bost minutu): 0
Batez besteko hilarri xerra bakoitzeko (azken bost minutu): NaN
Gehienezko hilarri xerra bakoitzeko (azken bost minutu): 0
Eredatutako mutazioak: 0 byte

Lotaren tamaina murrizteko saiakerak (banaka bidaliz ere) ez zuen eraginik izan, okerrera egin zuen. Baliteke CS-ren errendimendu handiena benetan hori izatea, CSrako lortutako emaitzak DataStax-erako lortutakoen antzekoak baitira - ehunka mila eragiketa segundoko gutxi gorabehera. Gainera, baliabideen erabilerari erreparatzen badiogu, CS-k CPU eta disko askoz gehiago erabiltzen dituela ikusiko dugu:

Irudiak bi datu-baseetarako proba guztiak jarraian exekutatzen diren bitartean izandako erabilera erakusten du.

HBren irakurketa abantaila indartsuari buruz. Hemen ikus dezakezu bi datu-baseetarako, irakurketan zehar diskoaren erabilera oso baxua dela (irakurketa-probak datu-base bakoitzaren proba-zikloaren azken zatia dira, adibidez CSrako hau 15:20etik 15:40era da). HBren kasuan, arrazoia argia da: datu gehienak memorian zintzilikatzen dira, memstorean, eta batzuk blockcache-n gordetzen dira. CSri dagokionez, ez dago oso argi nola funtzionatzen duen, baina diskoaren birziklapena ere ez da ikusten, baina badaezpada, cachea row_cache_size_in_mb = 2048 gaitu eta caching = {'keys': 'ALL' ezartzeko saiakera egin zen, 'rows_per_partition': '2000000'}, baina horrek are okerrago egin zuen.

Aipatzekoa da beste behin ere HBko eskualde kopuruari buruzko puntu garrantzitsu bat. Gure kasuan, balioa 64 gisa zehaztu zen. Murrizten baduzu eta berdin egiten baduzu, adibidez, 4, irakurtzean, abiadura 2 aldiz jaisten da. Arrazoia da memstore azkarrago beteko dela eta fitxategiak maizago garbituko direla eta irakurtzean, fitxategi gehiago prozesatu beharko direla, hau da, eragiketa konplikatu samarra HBrentzat. Baldintza errealetan, hau aurre-zatiketa eta trinkotze estrategia baten bidez pentsatuz trata daiteke; bereziki, zaborra bildu eta HFiletak etengabe konprimitzen dituen erabilgarritasun bat erabiltzen dugu. Litekeena da DataStax probetarako eskualde bakarra esleitu izana taula bakoitzeko (ez da zuzena) eta horrek zertxobait argituko luke zergatik HB izan zen hain apalagoa irakurketa probetan.

Hortik aurretiazko ondorio hauek ateratzen dira. Probetan akats handirik egin ez zela suposatuz, Cassandra buztinezko oinak dituen koloso baten itxura du. Zehatzago esanda, hanka batean orekatzen duen bitartean, artikuluaren hasierako irudian bezala, emaitza nahiko onak erakusten ditu, baina baldintza bereko borrokan erabat galtzen du. Aldi berean, gure hardwarearen CPU erabilera baxua kontuan hartuta, ostalari bakoitzeko bi RegionServer HB plantatzen ikasi genuen eta, horrela, errendimendua bikoiztu genuen. Horiek. Baliabideen erabilera kontuan hartuta, are tamalgarriagoa da CSren egoera.

Noski, proba hauek nahiko sintetikoak dira eta hemen erabili zen datu kopurua nahiko apala da. Baliteke terabytera aldatuz gero, egoera ezberdina izatea, baina HBrentzat terabyte-k karga ditzakegun bitartean, CSrentzat arazoa suertatu zen. Bolumen horiekin ere OperationTimedOutException bat botatzen zuen, nahiz eta erantzunaren zain egoteko parametroak lehenetsitakoekin alderatuta hainbat aldiz handitu ziren.

Esfortzu bateratuen bidez CSren oztopoak aurkitzea espero dut eta bizkortzen badugu, argitalpenaren amaieran behin betiko emaitzei buruzko informazioa gehituko dut.

UPD: Kamaraden aholkuei esker irakurketa bizkortzea lortu nuen. izan zen:
159 operazio (644 taula, 4 korronte, 5 multzoa).
Added:
.withLoadBalancingPolicy(TokenAwarePolicy berria(DCAwareRoundRobinPolicy.builder().build()))
Eta hari kopuruarekin jolastu nuen. Emaitza hau da:
4 taula, 100 hari, lote = 1 (piezaz pieza): 301 ops
4 taula, 100 hari, lote = 10: 447 epe
4 taula, 100 hari, lote = 100: 625 epe

Geroago beste sintonizazio aholku batzuk aplikatuko ditut, proba-ziklo osoa exekutatu eta emaitzak gehituko ditut mezuaren amaieran.

Iturria: www.habr.com