Þetta er ekki einu sinni grín, það virðist sem þessi tiltekna mynd endurspegli kjarna þessara gagnagrunna best og á endanum verður ljóst hvers vegna:
Samkvæmt DB-Engines Ranking eru tveir vinsælustu NoSQL dálkagagnagrunnarnir Cassandra (hér á eftir CS) og HBase (HB).
Með vilja örlaganna hefur gagnahleðslustjórnunarteymið okkar hjá Sberbank þegar og vinnur náið með HB. Á þessum tíma rannsökuðum við styrkleika og veikleika þess nokkuð vel og lærðum hvernig á að elda það. Hins vegar neyddi tilvist vals í formi CS okkur alltaf til að kvelja okkur svolítið með efasemdir: tókum við rétt val? Þar að auki, niðurstöður , framkvæmt af DataStax, sögðu þeir að CS sigri HB auðveldlega með næstum algjöru marki. Aftur á móti er DataStax hagsmunaaðili og þú ættir ekki að taka orð þeirra fyrir það. Við vorum líka ruglaðir yfir frekar litlu magni af upplýsingum um prófunaraðstæður, svo við ákváðum að finna út á eigin spýtur hver er konungur BigData NoSql, og niðurstöðurnar sem fengust reyndust mjög áhugaverðar.
Hins vegar, áður en haldið er áfram að niðurstöðum prófana sem gerðar eru, er nauðsynlegt að lýsa mikilvægum þáttum umhverfisstillinganna. Staðreyndin er sú að hægt er að nota CS í ham sem leyfir gagnatap. Þeir. þetta er þegar aðeins einn þjónn (hnútur) er ábyrgur fyrir gögnum ákveðins lykils, og ef hann mistekst af einhverjum ástæðum, þá tapast gildi þessa lykils. Fyrir mörg verkefni er þetta ekki mikilvægt, en fyrir bankakerfið er þetta undantekning frekar en regla. Í okkar tilviki er mikilvægt að hafa nokkur afrit af gögnum fyrir áreiðanlega geymslu.
Því var aðeins litið til CS rekstrarhamsins í þrefaldri afritunarham, þ.e. Stofnun málarýmisins fór fram með eftirfarandi breytum:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Næst eru tvær leiðir til að tryggja tilskilið samræmi. Almenn regla:
NW + NR > RF
Sem þýðir að fjöldi staðfestinga frá hnútum við ritun (NW) auk fjölda staðfestinga frá hnútum við lestur (NR) verður að vera meiri en afritunarstuðullinn. Í okkar tilviki er RF = 3, sem þýðir að eftirfarandi valkostir henta:
2 + 2 > 3
3 + 1 > 3
Þar sem það er grundvallaratriði fyrir okkur að geyma gögnin eins áreiðanlega og mögulegt er, var 3+1 kerfið valið. Auk þess starfar HB á svipuðum slóðum, þ.e. slíkur samanburður verður sanngjarnari.
Það skal tekið fram að DataStax gerði hið gagnstæða í rannsókn sinni, þeir stilltu RF = 1 fyrir bæði CS og HB (fyrir hið síðarnefnda með því að breyta HDFS stillingunum). Þetta er mjög mikilvægur þáttur vegna þess að áhrifin á frammistöðu CS í þessu tilfelli eru mikil. Til dæmis sýnir myndin hér að neðan þann tíma sem þarf til að hlaða gögnum inn í CS:
Hér sjáum við eftirfarandi: því fleiri samkeppnisþræðir skrifa gögn, því lengri tíma tekur það. Þetta er eðlilegt, en það er mikilvægt að frammistöðurýrnun fyrir RF=3 sé marktækt meiri. Með öðrum orðum, ef við skrifum 4 þræði í 5 töflur hver (20 alls), þá tapar RF=3 um það bil 2 sinnum (150 sekúndur fyrir RF=3 á móti 75 fyrir RF=1). En ef við aukum álagið með því að hlaða gögnum inn í 8 töflur með 5 þræði hver (40 alls), þá er tapið á RF=3 þegar 2,7 sinnum (375 sekúndur á móti 138).
Kannski er þetta að hluta til leyndarmál árangursríkrar álagsprófunar sem DataStax framkvæmdi fyrir CS, vegna þess að fyrir HB á okkar standi hafði það engin áhrif að breyta afritunarstuðlinum úr 2 í 3. Þeir. diskar eru ekki flöskuháls HB fyrir uppsetningu okkar. Hins vegar eru margir aðrir gildrur hér, því það skal tekið fram að útgáfan okkar af HB var smá plástrað og lagfærð, umhverfin eru allt önnur o.s.frv. Það er líka athyglisvert að kannski veit ég bara ekki hvernig á að undirbúa CS rétt og það eru nokkrar árangursríkari leiðir til að vinna með það, og ég vona að við munum komast að því í athugasemdunum. En fyrst og fremst.
Allar prófanir voru gerðar á vélbúnaðarklasa sem samanstendur af 4 netþjónum, hver með eftirfarandi uppsetningu:
Örgjörvi: Xeon E5-2680 v4 @ 2.40GHz 64 þræðir.
Diskar: 12 stykki SATA HDD
Java útgáfa: 1.8.0_111
CS útgáfa: 3.11.5
cassandra.yml breyturfjöldi_tákn: 256
hinted_handoff_enabled: satt
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_directory: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
Authenticator: AllowAllAuthenticator
heimildarmaður: AllowAllAuthorizer
hlutverkastjóri: CassandraRoleManager
hlutverk_gildi_í_ms: 2000
leyfi_gildi_í_ms: 2000
skilríkisgildi_í_ms: 2000
skipting: org.apache.cassandra.dht.Murmur3Partitioner
gagnaskrárskrár:
- /data1/cassandra/data # hver dataN mappa er sérstakur diskur
- /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: ósatt
disk_failure_policy: hætta
commit_failure_policy: hætta
ready_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
saved_caches_map: /data10/cassandra/saved_caches
commitlog_sync: reglubundið
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
fræ_veita:
- flokksnafn: org.apache.cassandra.locator.SimpleSeedProvider
breytur:
— fræ: "*,*"
concurrent_reads: 256 # reynt 64 - enginn munur sást
concurrent_writes: 256 # reynt 64 - enginn munur sást
concurrent_counter_writes: 256 # reynt 64 - enginn munur sást
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # reynt 16 GB - það var hægara
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: ósatt
trickle_fsync_interval_in_kb: 10240
geymslugátt: 7000
ssl_geymslugátt: 7001
hlusta_vistfang: *
útsendingarfang: *
hlusta_á_útsendingarheimilisfangi: satt
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: satt
innfæddur_flutningshöfn: 9042
start_rpc: satt
rpc_address: *
rpc_port: 9160
rpc_keepalive: satt
rpc_server_type: samstilling
thrift_framed_transport_size_in_mb: 15
stigvaxandi_afrit: ósatt
snapshot_before_compaction: ósatt
auto_snapshot: satt
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
concurrent_compactors: 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: ósatt
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: engin
dulkóðunarvalkostir viðskiptavinar:
virkt: ósatt
internode_compression: dc
inter_dc_tcp_nodelay: ósatt
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: ósatt
enable_scripted_user_defined_functions: ósatt
Windows_timer_interval: 1
transparent_data_encryption_options:
virkt: ósatt
grafsteinsviðvörunarþröskuldur: 1000
grafsteinsbilunarþröskuldur: 100000
lotustærð_viðvörunarþröskuldur_í_kb: 200
lotu_stærð_bilunarþröskuldur_í_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: ósatt
enable_materialized_views: satt
enable_sasi_indexes: satt
GC stillingar:
### CMS stillingar-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+NotaðuCMSInitiatingOccupancyAðeins
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
Jvm.options minni var úthlutað 16Gb (við reyndum líka 32 Gb, enginn munur sást).
Töflurnar voru búnar til með skipuninni:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB útgáfa: 1.2.0-cdh5.14.2 (í flokknum org.apache.hadoop.hbase.regionserver.HRegion útilokuðum við MetricsRegion sem leiddi til GC þegar fjöldi svæða var meira en 1000 á RegionServer)
HBase færibreytur sem ekki eru sjálfgefnarzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 mínútur
hbase.client.scanner.timeout.period: 2 mínútur
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 mínútur
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 klst.
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.stærð: 1 GiB
hbase.hregion.memstore.block.margfaldari: 6
hbase.hstore.compactionÞröskuldur: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 dag(ar)
HBase Service Advanced Configuration Snippet (Safety Valve) fyrir 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 stillingarvalkostir fyrir HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 mínútur
hbase.snapshot.region.timeout: 2 mínútur
hbase.snapshot.master.timeout.millis: 2 mínútur
HBase REST Server Max Log Stærð: 100 MiB
HBase REST Server Hámarksafrit af skráarskrá: 5
HBase Thrift Server Max Log Stærð: 100 MiB
HBase Thrift Server Hámarksafrit af skráarskrá: 5
Master Max Log Stærð: 100 MiB
Master hámarksafrit af skráarskrá: 5
RegionServer Max Log Stærð: 100 MiB
RegionServer Hámarksafrit af skráarskrá: 5
HBase Active Master Detection Gluggi: 4 mínútur
dfs.client.hedged.read.threadpool.stærð: 40
dfs.client.hedged.readthreshold.millis: 10 millisekúndur
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Hámarkslýsingarferlaskrár: 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.stærð: 20
Svæðisflutningsþræðir: 6
Java hrúgustærð viðskiptavinar í bætum: 1 GiB
HBase REST Server Sjálfgefinn hópur: 3 GiB
HBase Thrift Server Sjálfgefinn hópur: 3 GiB
Java hrúgustærð HBase Master í bætum: 16 GiB
Java hrúgustærð HBase RegionServer í bætum: 32 GiB
+Dýragarðsvörður
maxClientCnxns: 601
maxSessionTimeout: 120000
Að búa til töflur:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
breyta 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Það er einn mikilvægur punktur hér - DataStax lýsingin segir ekki til um hversu mörg svæði voru notuð til að búa til HB töflurnar, þó það sé mikilvægt fyrir mikið magn. Því fyrir prófin var magn = 64 valið, sem gerir kleift að geyma allt að 640 GB, þ.e. meðalstærð borð.
Þegar prófunin var gerð var HBase með 22 þúsund töflur og 67 þúsund svæði (þetta hefði verið banvænt fyrir útgáfu 1.2.0 ef ekki væri fyrir plásturinn sem nefndur er hér að ofan).
Nú fyrir kóðann. Þar sem ekki var ljóst hvaða stillingar voru hagstæðari fyrir tiltekinn gagnagrunn voru prófanir gerðar í ýmsum samsetningum. Þeir. í sumum prófunum voru 4 töflur hlaðnar samtímis (allir 4 hnútarnir voru notaðir til tengingar). Í öðrum prófum unnum við með 8 mismunandi töflur. Í sumum tilfellum var lotustærðin 100, í öðrum 200 (lotubreytu - sjá kóðann hér að neðan). Gagnastærðin fyrir gildi er 10 bæti eða 100 bæti (dataSize). Alls voru 5 milljónir gagna skrifaðar og lesnar inn í hverja töflu í hvert sinn. Á sama tíma voru 5 þræðir skrifaðir/lesnir í hverja töflu (þráðanúmer - thNum), sem hver um sig notaði sitt lyklasvið (tala = 1 milljón):
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);
}
}
Í samræmi við það var sambærileg virkni veitt fyrir HB:
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);
}
}
Þar sem í HB þarf viðskiptavinurinn að sjá um samræmda dreifingu gagna, leit lykilsöltunaraðgerðin svona út:
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);
}
Nú er áhugaverðasti hlutinn - niðurstöðurnar:
Sama hluturinn á línuritsformi:
Kosturinn við HB kemur svo á óvart að grunur leikur á að það sé einhvers konar flöskuháls í CS uppsetningunni. Hins vegar, að googla og leita að augljósustu breytunum (eins og concurrent_writes eða memtable_heap_space_in_mb) flýtti ekki fyrir. Á sama tíma eru stokkarnir hreinir og blóta ekki neitt.
Gögnin dreifðust jafnt yfir hnútana, tölfræðin frá öllum hnútum var nokkurn veginn sú sama.
Svona lítur tölfræði töflunnar út frá einum af hnútunumLyklarými: ks
Lesafjöldi: 9383707
Lestrartími: 0.04287025042448576 ms
Skrifafjöldi: 15462012
Skrifatími: 0.1350068438699957 ms
Skolar í bið: 0
Tafla: t1
Fjöldi SSTALL: 16
Notað pláss (í beinni): 148.59 MiB
Notað pláss (samtals): 148.59 MiB
Rými notað af skyndimyndum (samtals): 0 bæti
Off heap minni notað (samtals): 5.17 MiB
SSTable þjöppunarhlutfall: 0.5720989576459437
Fjöldi skiptinga (áætlun): 3970323
Fjöldi minnishluta: 0
Minnistærð gagna: 0 bæti
Minnistærð af hrúgaminni notað: 0 bæti
Fjöldi rofa sem hægt er að nota: 5
Fjöldi lesenda á staðnum: 2346045
Staðbundin lestrartími: NaN ms
Fjöldi skrifa á staðnum: 3865503
Staðbundin rittöf: NaN ms
Skolar í bið: 0
Prósenta viðgerðar: 0.0
Blómsía rangar jákvæðar: 25
Falskt hlutfall blómasíu: 0.00000
Blómsíurými notað: 4.57 MiB
Blómsía af hrúguminni notað: 4.57 MiB
Vísitala samantekt af hrúguminni notað: 590.02 KiB
Þjöppun lýsigögn af hrúga minni notað: 19.45 KiB
Þjöppuð skipting lágmarks bæti: 36
Þjöppuð skipting hámarks bæti: 42
Þjöppuð skipting þýðir bæti: 42
Meðaltal lifandi frumna í hverri sneið (síðustu fimm mínútur): NaN
Hámark lifandi frumna í hverri sneið (síðustu fimm mínútur): 0
Meðaltal legsteina á sneið (síðustu fimm mínútur): NaN
Hámark legsteina á sneið (síðustu fimm mínútur): 0
Fallnar stökkbreytingar: 0 bæti
Tilraun til að minnka stærð lotunnar (jafnvel að senda hana staka) hafði engin áhrif, hún ágerðist bara. Það er mögulegt að í raun sé þetta í raun hámarksafköst fyrir CS, þar sem niðurstöðurnar sem fást fyrir CS eru svipaðar þeim sem fengust fyrir DataStax - um hundruð þúsunda aðgerða á sekúndu. Að auki, ef við skoðum auðlindanýtingu, munum við sjá að CS notar mun meiri CPU og diska:
Myndin sýnir nýtingu við keyrslu allra prófana í röð fyrir báða gagnagrunna.
Varðandi öflugt lestrarforskot HB. Hér má sjá að fyrir báða gagnagrunna er diskanýting við lestur mjög lítil (lespróf eru lokahluti prófunarlotunnar fyrir hvern gagnagrunn, td fyrir CS er þetta frá 15:20 til 15:40). Í tilviki HB er ástæðan skýr - flest gögnin hanga í minni, í memstore og sum eru í skyndiminni í blockcache. Hvað varðar CS, þá er ekki mjög ljóst hvernig það virkar, en endurvinnsla diska er heldur ekki sýnileg, en til öryggis var reynt að virkja skyndiminni row_cache_size_in_mb = 2048 og stilla skyndiminni = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, en það gerði þetta enn verra.
Einnig er rétt að nefna enn og aftur mikilvægan punkt um fjölda landshluta í HB. Í okkar tilviki var gildið tilgreint sem 64. Ef þú minnkar það og gerir það jafnt og til dæmis 4, þá lækkar hraðinn um 2 sinnum við lestur. Ástæðan er sú að memstore mun fyllast hraðar og skrár skolast oftar og við lestur þarf að vinna úr fleiri skrám, sem er frekar flókin aðgerð fyrir HB. Við raunverulegar aðstæður er hægt að meðhöndla þetta með því að hugsa í gegnum fyrirframskiptingu og þjöppunarstefnu; sérstaklega notum við sjálfskrifað tól sem safnar rusli og þjappar HF-skrám saman stöðugt í bakgrunni. Það er alveg mögulegt að fyrir DataStax próf hafi þeir aðeins úthlutað 1 svæði í töflu (sem er ekki rétt) og það myndi skýra nokkuð hvers vegna HB var svona síðri í lestrarprófunum sínum.
Af þessu eru dregnar eftirfarandi bráðabirgðaályktanir. Að því gefnu að engin stór mistök hafi verið gerð við prófun, þá lítur Cassandra út eins og risastór með fætur úr leir. Nánar tiltekið, á meðan hún heldur jafnvægi á öðrum fæti, eins og á myndinni í upphafi greinarinnar, sýnir hún tiltölulega góðan árangur, en í bardaga við sömu aðstæður tapar hún hreint út. Á sama tíma, að teknu tilliti til lítillar CPU nýtingar á vélbúnaði okkar, lærðum við að planta tveimur RegionServer HB á hvern gestgjafa og tvöfölduðum þar með afköst. Þeir. Að teknu tilliti til nýtingar auðlinda er staðan fyrir CS enn ömurlegri.
Auðvitað eru þessar prófanir nokkuð tilbúnar og gagnamagnið sem var notað hér er tiltölulega hóflegt. Það er hugsanlegt að ef við skiptum yfir í terabæt væri staðan önnur, en á meðan við getum hlaðið terabætum fyrir HB, þá reyndist þetta vandamál fyrir CS. Það kastaði oft OperationTimedOutException jafnvel með þessum bindum, þó að færibreytur fyrir að bíða eftir svari hafi þegar verið auknar nokkrum sinnum samanborið við sjálfgefnar.
Ég vona að með sameiginlegu átaki munum við finna flöskuhálsa CS og ef við getum flýtt fyrir því, þá mun ég í lok færslunnar örugglega bæta við upplýsingum um lokaniðurstöðurnar.
UPD: Þökk sé ráðleggingum félaga tókst mér að flýta lestrinum. Var:
159 ops (644 borð, 4 streymir, lotur 5).
Bætt við:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Og ég lék mér að fjölda þráða. Niðurstaðan er eftirfarandi:
4 borð, 100 þræðir, lota = 1 (stykki fyrir stykki): 301 ops
4 töflur, 100 þræðir, lota = 10: 447 ops
4 töflur, 100 þræðir, lota = 100: 625 ops
Síðar mun ég beita öðrum ráðleggingum um stillingar, keyra heila prófunarlotu og bæta við niðurstöðunum í lok færslunnar.
Heimild: www.habr.com