Dit is nie eers 'n grap nie, dit blyk dat hierdie spesifieke prentjie die essensie van hierdie databasisse die akkuraatste weerspieël, en op die ou end sal dit duidelik wees hoekom:
Volgens DB-Engines Ranking is die twee gewildste NoSQL-kolomdatabasisse Cassandra (hierna CS) en HBase (HB).
Volgens die wil van die noodlot het ons datalaaibestuurspan by Sberbank reeds en werk nou saam met HB. Gedurende hierdie tyd het ons die sterk- en swakpunte daarvan redelik goed bestudeer en geleer hoe om dit te kook. Die teenwoordigheid van 'n alternatief in die vorm van CS het ons egter altyd gedwing om onsself 'n bietjie te torring met twyfel: het ons die regte keuse gemaak? Verder, die resultate , uitgevoer deur DataStax, het hulle gesê dat CS maklik HB klop met amper 'n verpletterende telling. Aan die ander kant is DataStax 'n belangstellende party, en jy moet nie hul woord daarvoor aanvaar nie. Ons was ook verward deur die taamlik klein hoeveelheid inligting oor die toetstoestande, so ons het besluit om op ons eie uit te vind wie die koning van BigData NoSql is, en die resultate wat verkry is, was baie interessant.
Voordat u egter verder gaan met die resultate van die toetse wat uitgevoer is, is dit nodig om die beduidende aspekte van die omgewingskonfigurasies te beskryf. Die feit is dat CS gebruik kan word in 'n modus wat dataverlies toelaat. Dié. dit is wanneer slegs een bediener (nodus) verantwoordelik is vir die data van 'n sekere sleutel, en as dit om een of ander rede misluk, dan sal die waarde van hierdie sleutel verlore gaan. Vir baie take is dit nie krities nie, maar vir die banksektor is dit die uitsondering eerder as die reël. In ons geval is dit belangrik om verskeie kopieë van data te hê vir betroubare berging.
Daarom is slegs die CS-bedryfsmodus in driedubbele replikasie-modus oorweeg, m.a.w. Die skepping van die saakruimte is uitgevoer met die volgende parameters:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Vervolgens is daar twee maniere om die vereiste vlak van konsekwentheid te verseker. Algemene reël:
NW + NR > RF
Wat beteken dat die aantal bevestigings vanaf nodusse tydens skryf (NW) plus die aantal bevestigings vanaf nodusse tydens lees (NR) groter as die replikasiefaktor moet wees. In ons geval is RF = 3, wat beteken dat die volgende opsies geskik is:
2 + 2 > 3
3 + 1 > 3
Aangesien dit vir ons fundamenteel belangrik is om die data so betroubaar moontlik te stoor, is die 3+1-skema gekies. Daarbenewens werk HB op 'n soortgelyke beginsel, m.a.w. so 'n vergelyking sal meer regverdig wees.
Daar moet kennis geneem word dat DataStax die teenoorgestelde in hul studie gedoen het, hulle het RF = 1 vir beide CS en HB gestel (vir laasgenoemde deur die HDFS-instellings te verander). Dit is 'n baie belangrike aspek, want die impak op CS prestasie in hierdie geval is groot. Byvoorbeeld, die prent hieronder toon die toename in die tyd wat nodig is om data in CS te laai:
Hier sien ons die volgende: hoe meer mededingende drade data skryf, hoe langer neem dit. Dit is natuurlik, maar dit is belangrik dat die prestasiedegradasie vir RF=3 aansienlik hoër is. Met ander woorde, as ons 4 drade in 5 tabelle elk skryf (20 in totaal), dan verloor RF=3 ongeveer 2 keer (150 sekondes vir RF=3 teenoor 75 vir RF=1). Maar as ons die las verhoog deur data in 8 tabelle te laai met 5 drade elk (40 in totaal), dan is die verlies van RF=3 reeds 2,7 keer (375 sekondes teenoor 138).
Miskien is dit deels die geheim van die suksesvolle vragtoetsing wat deur DataStax vir CS uitgevoer is, want vir HB by ons staanplek het die verandering van die replikasiefaktor van 2 na 3 geen effek gehad nie. Dié. skywe is nie die HB-bottelnek vir ons konfigurasie nie. Hier is egter baie ander slaggate, want daar moet kennis geneem word dat ons weergawe van HB effens gelap en aangepas is, die omgewings is heeltemal anders, ens. Dit is ook opmerklik dat ek miskien net nie weet hoe om CS korrek voor te berei nie en dat daar 'n paar meer effektiewe maniere is om daarmee te werk, en ek hoop ons sal uitvind in die kommentaar. Maar eerste dinge eerste.
Alle toetse is uitgevoer op 'n hardeware-kluster wat uit 4 bedieners bestaan, elk met die volgende konfigurasie:
SVE: Xeon E5-2680 v4 @ 2.40GHz 64 drade.
Skywe: 12 stukke SATA HDD
java weergawe: 1.8.0_111
CS-weergawe: 3.11.5
cassandra.yml parametersgetal_tokens: 256
hinted_handoff_enabled: waar
hinted_handoff_throttle_in_kb: 1024
maksimum_wenke_afleweringsdraad: 2
hints_directory: /data10/cassandra/wenke
wenke_spoelperiode_in_ms: 10000 XNUMX
maksimum_wenke_lêer_grootte_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
authenticator: AllowAllAuthenticator
magtiger: AllowAllAuthorizer
rolbestuurder: CassandraRolbestuurder
rolle_geldigheid_in_ms: 2000
permissions_validity_in_ms: 2000
geloofsbriewe_geldigheid_in_ms: 2000
partitioner: org.apache.cassandra.dht.Murmur3Partitioner
data_lêer_gidse:
- /data1/cassandra/data # elke dataN-gids is 'n aparte skyf
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_directory: /data9/cassandra/commitlog
cdc_enabled: vals
disk_failure_policy: stop
commit_failure_policy: stop
voorbereide_stellings_kas_grootte_mb:
thrift_prepared_statements_cache_size_mb:
sleutel_kas_grootte_in_mb:
key_cache_save_period: 14400
ry_kas_grootte_in_mb: 0
row_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: periodiek
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
saadverskaffer:
- klasnaam: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
— sade: "*,*"
concurrent_reads: 256 # probeer 64 - geen verskil opgemerk nie
concurrent_writes: 256 # probeer 64 - geen verskil opgemerk nie
concurrent_counter_writes: 256 # probeer 64 - geen verskil opgemerk nie
gelyktydige_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # probeer 16 GB - dit was stadiger
memtable_allocation_type: heap_buffers
indeks_opsomming_kapasiteit_in_mb:
indeks_opsomming_verander grootte-interval_in_minute: 60
trickle_fsync: vals
trickle_fsync_interval_in_kb: 10240
stoorpoort: 7000
ssl_stoorpoort: 7001
luister_adres: *
uitsending_adres: *
luister_op_uitsending_adres: waar
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
begin_native_transport: waar
inheemse_vervoer_poort: 9042
start_rpc: waar
rpc_adres: *
rpc_port: 9160
rpc_keepalive: waar
rpc_bediener_tipe: sinchroniseer
spaarsaamheid_raam_vervoer_grootte_in_mb: 15
inkrementele_rugsteun: vals
snapshot_before_compaction: vals
auto_snapshot: waar
kolom_indeks_grootte_in_kb: 64
kolom_indeks_kas_grootte_in_kb: 2
gelyktydige_kompaktors: 4
compaction_throughput_mb_per_sec: 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: vals
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dinamiese_snitch_slegtigheidsdrempel: 0.1
request_scheduler: org.apache.cassandra.scheduler.No Scheduler
bediener_enkripsie_opsies:
internode_enkripsie: geen
kliënt_enkripsie_opsies:
aangeskakel: onwaar
internode_kompressie: dc
inter_dc_tcp_nodelay: onwaar
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: vals
enable_scripted_user_defined_functions: vals
windows_timer_interval: 1
deursigtige_data-enkripsie-opsies:
aangeskakel: onwaar
grafsteen_waarsku_drempel: 1000
grafsteen_mislukkingsdrempel: 100000
bondelgrootte_waarsku_drempel_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_waarsku_drempel_in_ms: 1000
back_pressure_enabled: vals
enable_materialized_views: waar
enable_sasi_indexes: waar
GC-instellings:
### CMS-instellings-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelOpmerkingGeaktiveer
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+Gebruik Slegs CMSIinitiatingOccupancy
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdekBonkiesrekord altyd
-XX:+CMSClassUnloadingEnabled
Die jvm.options geheue is 16Gb toegeken (ons het ook 32 Gb probeer, geen verskil is opgemerk nie).
Die tabelle is geskep met die opdrag:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB weergawe: 1.2.0-cdh5.14.2 (in die klas org.apache.hadoop.hbase.regionserver.HRegion het ons MetricsRegion uitgesluit wat tot GC gelei het toe die aantal streke meer as 1000 op RegionServer was)
Nie-verstek HBase parametersdieretuinoppasser.sessie.time-out: 120000 XNUMX
hbase.rpc.timeout: 2 minuut(e)
hbase.client.scanner.timeout.periode: 2 minuut(e)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.periode: 2 minuut(e)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.periode: 4 uur
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.spoelgrootte: 1 GiB
hbase.hregion.memstore.blok.vermenigvuldiger: 6
hbase.hstore.compactionDrempel: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 dag(e)
HBase Service Advanced Configuration Snippet (Safety Valve) vir hbase-site.xml:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Java-konfigurasie-opsies vir HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minuut(e)
hbase.snapshot.region.timeout: 2 minuut(e)
hbase.snapshot.master.timeout.millis: 2 minuut(e)
HBase REST Server Max Log Grootte: 100 MiB
HBase REST Server maksimum loglêer rugsteun: 5
HBase Thrift Server Max Log Grootte: 100 MiB
HBase Thrift Server maksimum loglêer-rugsteun: 5
Meester maksimum loggrootte: 100 MiB
Bemeester maksimum loglêer-rugsteun: 5
RegionServer Max Log Grootte: 100 MiB
RegionServer maksimum loglêer rugsteun: 5
HBase Active Master Detection Venster: 4 minute(s)
dfs.client.hedged.read.threadpool.grootte: 40
dfs.client.hedged.read.threshold.millis: 10 millisekonde(s)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maksimum proseslêerbeskrywings: 180000 XNUMX
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.threads: 30
hbase.master.executor.closeregion.threads: 30
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.grootte: 20
Streekverskuiwingdrade: 6
Kliënt Java-hoopgrootte in grepe: 1 GiB
HBase REST Server verstekgroep: 3 GiB
HBase Thrift Server verstekgroep: 3 GiB
Java-hoopgrootte van HBase-meester in grepe: 16 GiB
Java-hoopgrootte van HBase RegionServer in grepe: 32 GiB
+ Dieretuinwagter
maxClientCnxns: 601
maxSessionTimeout: 120000
Skep tabelle:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
verander 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Daar is een belangrike punt hier - die DataStax-beskrywing sê nie hoeveel streke gebruik is om die HB-tabelle te skep nie, hoewel dit van kritieke belang is vir groot volumes. Daarom, vir die toetse, is hoeveelheid = 64 gekies, wat dit moontlik maak om tot 640 GB te stoor, d.w.s. medium grootte tafel.
Ten tyde van die toets het HBase 22 duisend tabelle en 67 duisend streke gehad (dit sou dodelik gewees het vir weergawe 1.2.0 as nie vir die pleister hierbo genoem nie).
Nou vir die kode. Aangesien dit nie duidelik was watter konfigurasies voordeliger was vir 'n spesifieke databasis nie, is toetse in verskeie kombinasies uitgevoer. Dié. in sommige toetse is 4 tabelle gelyktydig gelaai (al 4 nodusse is vir verbinding gebruik). In ander toetse het ons met 8 verskillende tabelle gewerk. In sommige gevalle was die bondelgrootte 100, in ander 200 (joernaalparameter - sien kode hieronder). Die datagrootte vir waarde is 10 grepe of 100 grepe (datagrootte). In totaal is 5 miljoen rekords elke keer in elke tabel geskryf en gelees. Terselfdertyd is 5 drade na elke tabel geskryf/gelees (draadnommer - thNum), wat elkeen sy eie reeks sleutels gebruik het (telling = 1 miljoen):
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);
}
}
Gevolglik is soortgelyke funksionaliteit vir HB voorsien:
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);
}
}
Aangesien die kliënt in HB moet sorg vir die eenvormige verspreiding van data, het die sleutelsoutfunksie soos volg gelyk:
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);
}
Nou die interessantste deel - die resultate:
Dieselfde ding in grafiekvorm:
Die voordeel van HB is so verbasend dat daar 'n vermoede bestaan dat daar 'n soort bottelnek in die CS-opstelling is. Google en soek na die mees voor die hand liggende parameters (soos concurrent_writes of memtable_heap_space_in_mb) het dinge egter nie bespoedig nie. Terselfdertyd is die stompe skoon en vloek niks.
Die data is eweredig oor die nodusse versprei, die statistieke van alle nodusse was ongeveer dieselfde.
Dit is hoe die tabelstatistieke vanaf een van die nodusse lykSleutelruimte: ks
Leestelling: 9383707
Lees Latency: 0.04287025042448576 me
Skryftelling: 15462012
Skryfvertraging: 0.1350068438699957 me
Hangende spoelings: 0
Tabel: t1
SSTable telling: 16
Ruimte gebruik (regstreeks): 148.59 MiB
Spasie gebruik (totaal): 148.59 MiB
Spasie wat deur foto's gebruik word (totaal): 0 grepe
Af-hoop geheue gebruik (totaal): 5.17 MiB
SSTable kompressieverhouding: 0.5720989576459437
Aantal partisies (skatting): 3970323
Herinnerbare seltelling: 0
Onthoubare datagrootte: 0 grepe
Memtable off heap memory gebruik: 0 grepe
Telling van onthoubare skakelaars: 5
Plaaslike leestelling: 2346045
Plaaslike leesvertraging: NaN me
Plaaslike skryftelling: 3865503
Plaaslike skryfvertraging: NaN me
Hangende spoele: 0
Persentasie herstel: 0.0
Bloeifilter vals positiewe: 25
Bloei filter vals verhouding: 0.00000
Bloeifilterspasie gebruik: 4.57 MiB
Bloeifilter van hoopgeheue gebruik: 4.57 MiB
Indeksopsomming van hoopgeheue gebruik: 590.02 KiB
Kompressie-metadata van hoopgeheue gebruik: 19.45 KiB
Verpakte partisie minimum grepe: 36
Verpakte partisie maksimum grepe: 42
Gekompakteerde partisie beteken grepe: 42
Gemiddelde lewende selle per sny (laaste vyf minute): NaN
Maksimum lewende selle per sny (laaste vyf minute): 0
Gemiddelde grafstene per sny (laaste vyf minute): NaN
Maksimum grafstene per sny (laaste vyf minute): 0
Mutasies laat val: 0 grepe
'n Poging om die grootte van die bondel te verklein (selfs om dit individueel te stuur) het geen effek gehad nie, dit het net erger geword. Dit is moontlik dat dit in werklikheid die maksimum werkverrigting vir CS is, aangesien die resultate wat vir CS verkry is soortgelyk is aan dié wat vir DataStax verkry is - ongeveer honderdduisende bewerkings per sekonde. Daarbenewens, as ons na hulpbronbenutting kyk, sal ons sien dat CS baie meer SVE en skywe gebruik:
Die figuur toon die gebruik tydens die loop van alle toetse in 'n ry vir beide databasisse.
Wat HB se kragtige leesvoordeel betref. Hier kan jy sien dat vir beide databasisse, skyfbenutting tydens lees uiters laag is (leestoetse is die laaste deel van die toetssiklus vir elke databasis, byvoorbeeld vir CS is dit van 15:20 tot 15:40). In die geval van HB is die rede duidelik - die meeste van die data hang in die geheue, in die memstore, en sommige is in blokkas gekas. Wat CS betref, is dit nie baie duidelik hoe dit werk nie, maar skyfherwinning is ook nie sigbaar nie, maar net vir ingeval, 'n poging is aangewend om die kas row_cache_size_in_mb = 2048 te aktiveer en caching = {'keys': 'ALL', te stel. 'rows_per_partition': ' 2000000'}, maar dit het dit nog 'n bietjie erger gemaak.
Dit is ook die moeite werd om weereens 'n belangrike punt oor die aantal streke in HB te noem. In ons geval is die waarde gespesifiseer as 64. As jy dit verminder en dit gelyk maak aan byvoorbeeld 4, dan daal die spoed by lees met 2 keer. Die rede is dat memstore vinniger vol sal word en lêers meer gereeld gespoel sal word en wanneer dit gelees word, sal meer lêers verwerk moet word, wat 'n taamlik ingewikkelde operasie vir HB is. In werklike omstandighede kan dit behandel word deur deur 'n voorverdeel- en kompakteringsstrategie te dink; ons gebruik veral 'n selfgeskrewe hulpmiddel wat vullis versamel en HFiles voortdurend op die agtergrond saampers. Dit is heel moontlik dat hulle vir DataStax-toetse slegs 1 streek per tabel toegewys het (wat nie korrek is nie) en dit sal ietwat verduidelik hoekom HB so minderwaardig in hul leestoetse was.
Die volgende voorlopige gevolgtrekkings word hieruit gemaak. As daar aangeneem word dat geen groot foute tydens toetsing gemaak is nie, dan lyk Cassandra soos 'n kolos met voete van klei. Meer presies, terwyl sy op een been balanseer, soos in die prentjie aan die begin van die artikel, toon sy relatief goeie resultate, maar in 'n geveg onder dieselfde omstandighede verloor sy reguit. Terselfdertyd, met inagneming van die lae SVE-benutting op ons hardeware, het ons geleer om twee RegionServer HB's per gasheer te plant en daardeur die werkverrigting verdubbel. Dié. As die benutting van hulpbronne in ag geneem word, is die situasie vir CS selfs meer betreurenswaardig.
Natuurlik is hierdie toetse redelik sinteties en die hoeveelheid data wat hier gebruik is, is relatief beskeie. Dit is moontlik dat die situasie anders sou wees as ons na teragrepe oorskakel, maar terwyl ons vir HB teragrepe kan laai, was dit vir CS problematies. Dit het dikwels 'n OperationTimedOutException gegooi, selfs met hierdie volumes, alhoewel die parameters om op 'n antwoord te wag reeds verskeie kere verhoog is in vergelyking met die verstek.
Ek hoop dat ons deur gesamentlike pogings die knelpunte van CS sal vind en as ons dit kan bespoedig, dan sal ek aan die einde van die pos beslis inligting oor die finale resultate byvoeg.
UPD: Danksy die raad van kamerade het ek daarin geslaag om die lees te bespoedig. Was:
159 644 ops (4 tafels, 5 strome, bondel 100).
bygevoeg:
.withLoadBalancingPolicy(nuwe TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
En ek het rondgespeel met die aantal drade. Die resultaat is die volgende:
4 tafels, 100 drade, bondel = 1 (stuk vir stuk): 301 969 ops
4 tafels, 100 drade, bondel = 10: 447 608 ops
4 tafels, 100 drade, bondel = 100: 625 655 ops
Later sal ek ander instelwenke toepas, 'n volledige toetssiklus uitvoer en die resultate aan die einde van die pos byvoeg.
Bron: will.com