Dit is niet eens een grap, het lijkt erop dat dit specifieke beeld de essentie van deze databases het meest nauwkeurig weergeeft, en uiteindelijk zal het duidelijk worden waarom:
Volgens DB-Engines Ranking zijn de twee populairste kolomvormige NoSQL-databases Cassandra (hierna CS) en HBase (HB).
Door de wil van het lot heeft ons team voor het laden van gegevens bij Sberbank dat al gedaan en werkt nauw samen met HB. Gedurende deze tijd hebben we de sterke en zwakke punten ervan vrij goed bestudeerd en geleerd hoe we het moesten koken. De aanwezigheid van een alternatief in de vorm van CS dwong ons echter altijd een beetje te kwellen met twijfels: hebben we de juiste keuze gemaakt? Bovendien de resultaten , uitgevoerd door DataStax, zeiden ze dat CS HB gemakkelijk verslaat met een bijna verpletterende score. Aan de andere kant is DataStax een geïnteresseerde partij, en je moet ze niet op hun woord geloven. We waren ook in de war door de vrij kleine hoeveelheid informatie over de testomstandigheden, dus besloten we zelf uit te zoeken wie de koning van BigData NoSql is, en de verkregen resultaten bleken erg interessant.
Voordat we echter verder gaan met de resultaten van de uitgevoerde tests, is het noodzakelijk om de significante aspecten van de omgevingsconfiguraties te beschrijven. Feit is dat CS kan worden gebruikt in een modus die gegevensverlies mogelijk maakt. Die. dit is wanneer slechts één server (knooppunt) verantwoordelijk is voor de gegevens van een bepaalde sleutel, en als deze om de een of andere reden faalt, gaat de waarde van deze sleutel verloren. Voor veel taken is dit niet cruciaal, maar voor de banksector is dit eerder uitzondering dan regel. In ons geval is het belangrijk om meerdere kopieën van gegevens te hebben voor betrouwbare opslag.
Daarom werd alleen de CS-bedrijfsmodus in drievoudige replicatiemodus in aanmerking genomen, d.w.z. De creatie van de casespace werd uitgevoerd met de volgende parameters:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Vervolgens zijn er twee manieren om het vereiste niveau van consistentie te garanderen. Algemene regel:
NW + NR > RF
Dat betekent dat het aantal bevestigingen van knooppunten bij het schrijven (NW) plus het aantal bevestigingen van knooppunten bij het lezen (NR) groter moet zijn dan de replicatiefactor. In ons geval is RF = 3, wat betekent dat de volgende opties geschikt zijn:
2 + 2> 3
3 + 1> 3
Omdat het voor ons van fundamenteel belang is om de gegevens zo betrouwbaar mogelijk op te slaan, is gekozen voor het 3+1-schema. Bovendien werkt HB volgens een soortgelijk principe, namelijk een dergelijke vergelijking zal eerlijker zijn.
Opgemerkt moet worden dat DataStax in hun onderzoek het tegenovergestelde deed, ze stelden RF = 1 in voor zowel CS als HB (voor de laatste door de HDFS-instellingen te wijzigen). Dit is een heel belangrijk aspect omdat de impact op de CS-prestaties in dit geval enorm is. De onderstaande afbeelding toont bijvoorbeeld de toename van de tijd die nodig is om gegevens in CS te laden:
Hier zien we het volgende: hoe meer concurrerende threads gegevens schrijven, hoe langer het duurt. Dit is normaal, maar het is belangrijk dat de prestatievermindering voor RF=3 aanzienlijk groter is. Met andere woorden, als we 4 threads in elk 5 tabellen schrijven (20 in totaal), dan verliest RF=3 ongeveer 2 keer (150 seconden voor RF=3 versus 75 voor RF=1). Maar als we de belasting vergroten door gegevens in 8 tabellen met elk 5 threads te laden (40 in totaal), dan is het verlies van RF=3 al 2,7 keer zo groot (375 seconden versus 138).
Wellicht is dit deels het geheim van de succesvolle loadtesten uitgevoerd door DataStax voor CS, want voor HB op onze stand had het veranderen van de replicatiefactor van 2 naar 3 geen enkel effect. Die. schijven zijn niet het HB-knelpunt voor onze configuratie. Er zijn echter nog veel meer valkuilen, omdat opgemerkt moet worden dat onze versie van HB enigszins gepatcht en aangepast is, dat de omgevingen compleet anders zijn, enz. Het is ook de moeite waard om op te merken dat ik misschien gewoon niet weet hoe ik CS correct moet voorbereiden en dat er een aantal effectievere manieren zijn om ermee te werken, en ik hoop dat we dit in de reacties zullen ontdekken. Maar eerst dingen eerst.
Alle tests zijn uitgevoerd op een hardwarecluster bestaande uit 4 servers, elk met de volgende configuratie:
CPU: Xeon E5-2680 v4 @ 2.40 GHz 64 threads.
Schijven: 12 stuks SATA HDD
Java-versie: 1.8.0_111
CS-versie: 3.11.5
cassandra.yml-parametersaantal_tokens: 256
hinted_handoff_enabled: waar
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_map: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_bestandsgrootte_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
authenticator: AllowAllAuthenticator
autorisatie: AllowAllAuthorizer
rol_manager: CassandraRoleManager
rollen_validiteit_in_ms: 2000
permissies_validity_in_ms: 2000
inloggegevens_validiteit_in_ms: 2000
partitie: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # elke dataN-map is een afzonderlijke schijf
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_map: /data9/cassandra/commitlog
cdc_enabled: vals
disk_failure_policy: stop
commit_failure_policy: stop
voorbereide_statements_cache_size_mb:
spaarzaamheid_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
opgeslagen_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: periodiek
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
zaad_provider:
- klassenaam: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
— zaden: "*,*"
concurrent_reads: 256 # geprobeerd 64 - geen verschil opgemerkt
concurrent_writes: 256 # geprobeerd 64 - geen verschil opgemerkt
concurrent_counter_writes: 256 # geprobeerd 64 - geen verschil opgemerkt
gelijktijdige_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # geprobeerd 16 GB - het was langzamer
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: vals
trickle_fsync_interval_in_kb: 10240
opslag_poort: 7000
ssl_opslag_poort: 7001
luisteradres: *
Uitzendadres: *
luister_op_broadcast_adres: waar
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: waar
native_transport_port: 9042
start_rpc: waar
rpc_adres: *
rpc_poort: 9160
rpc_keepalive: waar
rpc_server_type: synchroniseren
spaarzaamheid_framed_transport_size_in_mb: 15
incrementele_backups: false
snapshot_before_compaction: false
auto_snapshot: waar
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
gelijktijdige_compactoren: 4
compactie_doorvoer_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: false
endpoint_snitch: RoddelenPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamische_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryptie_opties:
internode_encryptie: geen
client_encryptie_opties:
ingeschakeld: false
internode_compressie: dc
inter_dc_tcp_nodelay: onwaar
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_gedefinieerde_functies: false
enable_scripted_user_gedefinieerde_functies: false
windows_timer_interval: 1
transparante_data_encryptie_opties:
ingeschakeld: 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
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pression_enabled: false
enable_materialized_views: waar
enable_sasi_indexes: waar
GC-instellingen:
### CMS-instellingen-XX:+GebruikParNewGC
-XX:+GebruikConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:Overlevingsratio=8
-XX:Maximumduurdrempel=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+GebruikCMSInitiatingOccupancyOnly
-XX:CMSWachtduur=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAltijd
-XX:+CMSClassUnloadingEnabled
Het jvm.options-geheugen kreeg 16 Gb toegewezen (we hebben ook 32 Gb geprobeerd, er werd geen verschil opgemerkt).
De tabellen zijn gemaakt met het commando:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB-versie: 1.2.0-cdh5.14.2 (in de klasse org.apache.hadoop.hbase.regionserver.HRegion hebben we MetricsRegion uitgesloten, wat leidde tot GC toen het aantal regio's meer dan 1000 was op RegionServer)
Niet-standaard HBase-parameterszookeeper.session.time-out: 120000
hbase.rpc.time-out: 2 minuut(en)
hbase.client.scanner.timeout.period: 2 minuut(en)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minuut(en)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.periode: 4 uur
hbase.regioserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 dag(en)
HBase Service Geavanceerde configuratiefragment (veiligheidsklep) voor hbase-site.xml:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regioserver.optioneelcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Java-configuratieopties voor HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSPallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minuut/minuten
hbase.snapshot.region.time-out: 2 minuten
hbase.snapshot.master.timeout.millis: 2 minuut(en)
Maximale loggrootte van HBase REST-server: 100 MiB
HBase REST Server Maximale back-ups van logbestanden: 5
HBase Thrift Server Max. loggrootte: 100 MiB
HBase Thrift Server Maximale back-ups van logbestanden: 5
Master maximale loggrootte: 100 MiB
Master Maximaal aantal back-ups van logbestanden: 5
Maximale loggrootte van RegionServer: 100 MiB
RegionServer Maximale back-ups van logbestanden: 5
HBase Active Master-detectievenster: 4 minuut/minuten
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 milliseconde(n)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maximale procesbestandsdescriptors: 180000
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.size: 20
Onderwerpen voor regioverplaatsing: 6
Client Java-heapgrootte in bytes: 1 GiB
HBase REST-server Standaardgroep: 3 GiB
HBase Thrift Server Standaardgroep: 3 GiB
Java-heapgrootte van HBase-master in bytes: 16 GiB
Java-heapgrootte van HBase RegionServer in bytes: 32 GiB
+ Dierentuinier
maxClientCnxns: 601
maxSessionTimeout: 120000
Tabellen maken:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSIE => 'GZ'}
Er is hier één belangrijk punt: de DataStax-beschrijving vermeldt niet hoeveel regio's er zijn gebruikt om de HB-tabellen te maken, hoewel dit van cruciaal belang is voor grote volumes. Daarom werd voor de tests gekozen voor aantal = 64, wat de opslag van maximaal 640 GB mogelijk maakt, d.w.z. middelgrote tafel.
Op het moment van de test had HBase 22 tabellen en 67 regio's (dit zou dodelijk zijn geweest voor versie 1.2.0 als de hierboven genoemde patch er niet was geweest).
Nu voor de code. Omdat niet duidelijk was welke configuraties voor een bepaalde database voordeliger waren, zijn er tests uitgevoerd in verschillende combinaties. Die. bij sommige tests werden vier tabellen tegelijkertijd geladen (alle vier de knooppunten werden gebruikt voor de verbinding). In andere tests werkten we met 4 verschillende tafels. In sommige gevallen was de batchgrootte 4, in andere gevallen 8 (batchparameter - zie onderstaande code). De gegevensgrootte voor waarde is 100 bytes of 200 bytes (dataSize). In totaal werden er elke keer 10 miljoen records geschreven en in elke tabel gelezen. Tegelijkertijd werden er 100 threads naar elke tabel geschreven/gelezen (threadnummer - thNum), die elk hun eigen reeks sleutels gebruikten (aantal = 5 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);
}
}
Dienovereenkomstig werd voor HB een vergelijkbare functionaliteit geboden:
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);
}
}
Omdat bij HB de klant voor de uniforme distributie van gegevens moet zorgen, zag de belangrijkste salting-functie er als volgt uit:
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);
}
Nu het meest interessante deel: de resultaten:
Hetzelfde in grafiekvorm:
Het voordeel van HB is zo verrassend dat het vermoeden bestaat dat er een knelpunt zit in de CS-opstelling. Googlen en zoeken naar de meest voor de hand liggende parameters (zoals concurrent_writes of memtable_heap_space_in_mb) heeft de zaken echter niet versneld. Tegelijkertijd zijn de boomstammen schoon en vloeken ze nergens over.
De gegevens waren gelijkmatig verdeeld over de knooppunten, de statistieken van alle knooppunten waren ongeveer hetzelfde.
Zo zien de tabelstatistieken eruit vanaf een van de knooppuntenSleutelruimte: ks
Leestelling: 9383707
Leeslatentie: 0.04287025042448576 ms
Schrijftelling: 15462012
Schrijflatentie: 0.1350068438699957 ms
Lopende spoelingen: 0
Tabel: t1
SSTabel aantal: 16
Gebruikte ruimte (live): 148.59 MiB
Gebruikte ruimte (totaal): 148.59 MiB
Ruimte gebruikt door snapshots (totaal): 0 bytes
Gebruikt off-heap-geheugen (totaal): 5.17 MiB
SSTable compressieverhouding: 0.5720989576459437
Aantal partities (schatting): 3970323
Geheugencelaantal: 0
Geheugenbare gegevensgrootte: 0 bytes
Memtabel off-heap-geheugen gebruikt: 0 bytes
Aantal geheugenschakelaars: 5
Lokaal leesaantal: 2346045
Lokale leeslatentie: NaN ms
Aantal lokale schrijfbeurten: 3865503
Lokale schrijflatentie: NaN ms
Lopende spoelingen: 0
Percentage gerepareerd: 0.0
Valse positieven van het bloeifilter: 25
Bloomfilter valse verhouding: 0.00000
Gebruikte bloeifilterruimte: 4.57 MiB
Bloomfilter off-heap-geheugen gebruikt: 4.57 MiB
Indexoverzicht van gebruikt heapgeheugen: 590.02 KiB
Compressie-metagegevens uit gebruikt heap-geheugen: 19.45 KiB
Minimale bytes voor gecomprimeerde partitie: 36
Maximaal aantal bytes voor gecomprimeerde partitie: 42
Gecomprimeerde partitie gemiddelde bytes: 42
Gemiddelde levende cellen per plakje (laatste vijf minuten): NaN
Maximaal aantal levende cellen per plakje (laatste vijf minuten): 0
Gemiddelde grafstenen per schijfje (laatste vijf minuten): NaN
Maximaal aantal grafstenen per schijfje (laatste vijf minuten): 0
Weggelaten mutaties: 0 bytes
Een poging om de batchgrootte te verkleinen (zelfs individueel te versturen) had geen effect, het werd alleen maar erger. Het is mogelijk dat dit in feite echt de maximale prestaties zijn voor CS, aangezien de resultaten die voor CS worden verkregen vergelijkbaar zijn met die voor DataStax - ongeveer honderdduizenden bewerkingen per seconde. Als we bovendien kijken naar het gebruik van bronnen, zullen we zien dat CS veel meer CPU en schijven gebruikt:
De figuur toont het gebruik tijdens het uitvoeren van alle tests op rij voor beide databases.
Wat betreft het krachtige leesvoordeel van HB. Hier kunt u zien dat voor beide databases het schijfgebruik tijdens het lezen extreem laag is (leestests vormen het laatste deel van de testcyclus voor elke database, voor CS is dit bijvoorbeeld van 15:20 tot 15:40). In het geval van HB is de reden duidelijk: de meeste gegevens blijven in het geheugen hangen, in de memstore, en sommige worden in de cache opgeslagen. Wat CS betreft, het is niet erg duidelijk hoe het werkt, maar schijfrecycling is ook niet zichtbaar, maar voor het geval dat er een poging is gedaan om de cache row_cache_size_in_mb = 2048 in te schakelen en caching = {'keys': 'ALL' in te stellen, 'rows_per_partition': ' 2000000'}, maar dat maakte het nog een beetje erger.
Het is ook de moeite waard om nogmaals een belangrijk punt te vermelden over het aantal regio's in HB. In ons geval werd de waarde gespecificeerd als 64. Als je deze verkleint en gelijk maakt aan bijvoorbeeld 4, dan daalt de snelheid bij het lezen met 2 keer. De reden is dat de geheugenopslag sneller vol raakt en dat bestanden vaker worden leeggemaakt en dat bij het lezen meer bestanden moeten worden verwerkt, wat voor HB een nogal ingewikkelde handeling is. In reële omstandigheden kan dit worden aangepakt door na te denken over een strategie voor vooraf splitsen en comprimeren; in het bijzonder gebruiken we een zelfgeschreven hulpprogramma dat afval verzamelt en HFiles voortdurend op de achtergrond comprimeert. Het is heel goed mogelijk dat ze voor DataStax-tests slechts 1 regio per tabel hebben toegewezen (wat niet correct is) en dit zou enigszins verduidelijken waarom HB zo inferieur was in hun leestests.
Hieruit worden de volgende voorlopige conclusies getrokken. Ervan uitgaande dat er tijdens het testen geen grote fouten zijn gemaakt, lijkt Cassandra op een gevaarte met lemen voeten. Om precies te zijn, terwijl ze op één been balanceert, zoals op de foto aan het begin van het artikel, laat ze relatief goede resultaten zien, maar in een gevecht onder dezelfde omstandigheden verliest ze ronduit. Tegelijkertijd hebben we, rekening houdend met het lage CPU-gebruik op onze hardware, geleerd om twee RegionServer HB's per host te installeren en daardoor de prestaties te verdubbelen. Die. Als we de benutting van de hulpbronnen in aanmerking nemen, is de situatie voor CS zelfs nog betreurenswaardiger.
Uiteraard zijn deze tests vrij synthetisch en is de hoeveelheid data die hier is gebruikt relatief bescheiden. Het is mogelijk dat als we zouden overstappen op terabytes, de situatie anders zou zijn, maar terwijl we voor HB terabytes kunnen laden, bleek dit voor CS problematisch te zijn. Zelfs bij deze volumes werd vaak een OperationTimedOutException gegenereerd, hoewel de parameters voor het wachten op een antwoord al verschillende keren waren verhoogd in vergelijking met de standaardparameters.
Ik hoop dat we door gezamenlijke inspanningen de knelpunten van CS zullen vinden en als we dit kunnen versnellen, zal ik aan het einde van dit bericht zeker informatie toevoegen over de eindresultaten.
UPD: Dankzij het advies van kameraden ben ik erin geslaagd het lezen te versnellen. Was:
159 bewerkingen (644 tabellen, 4 streams, batch 5).
Toegevoegd:
.withLoadBalancingPolicy(nieuw TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
En ik speelde met het aantal threads. Het resultaat is het volgende:
4 tafels, 100 threads, batch = 1 (stuk voor stuk): 301 operaties
4 tabellen, 100 threads, batch = 10: 447 ops
4 tabellen, 100 threads, batch = 100: 625 ops
Later zal ik andere tuningtips toepassen, een volledige testcyclus uitvoeren en de resultaten aan het einde van het bericht toevoegen.
Bron: www.habr.com