Ĉi tio eĉ ne estas ŝerco, ŝajnas, ke ĉi tiu aparta bildo plej precize reflektas la esencon de ĉi tiuj datumbazoj, kaj finfine estos klare kial:
Laŭ DB-Engines Ranking, la du plej popularaj NoSQL-kolumnaj datumbazoj estas Cassandra (ĉi-poste CS) kaj HBase (HB).
Laŭ la volo de la sorto, nia administra teamo pri ŝarĝo de datumoj ĉe Sberbank jam havas kaj laboras proksime kun HB. Dum ĉi tiu tempo, ni sufiĉe bone studis ĝiajn fortojn kaj malfortojn kaj lernis kiel kuiri ĝin. Tamen la ĉeesto de alternativo en la formo de CS ĉiam devigis nin turmenti nin iom per duboj: ĉu ni faris la ĝustan elekton? Krome, la rezultoj , farita de DataStax, ili diris ke CS facile batas HB kun preskaŭ disbatanta poentaro. Aliflanke, DataStax estas interesita partio, kaj vi ne devus preni ilian vorton por ĝi. Ni ankaŭ estis konfuzitaj de la sufiĉe malgranda kvanto da informoj pri la testaj kondiĉoj, do ni decidis mem ekscii, kiu estas la reĝo de BigData NoSql, kaj la rezultoj akiritaj montriĝis tre interesaj.
Tamen, antaŭ ol pluiri al la rezultoj de la testoj faritaj, estas necese priskribi la signifajn aspektojn de la medio-agordoj. La fakto estas, ke CS povas esti uzata en reĝimo, kiu permesas perdon de datumoj. Tiuj. ĉi tio estas kiam nur unu servilo (nodo) respondecas pri la datumoj de certa ŝlosilo, kaj se ial ĝi malsukcesas, tiam la valoro de ĉi tiu ŝlosilo estos perdita. Por multaj taskoj tio ne estas kritika, sed por la banka sektoro ĉi tio estas la escepto prefere ol la regulo. En nia kazo, estas grave havi plurajn kopiojn de datumoj por fidinda stokado.
Tial, nur la CS-funkciiga reĝimo en triobla replika reĝimo estis konsiderita, t.e. La kreado de la kazspaco estis farita kun la sekvaj parametroj:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Poste, estas du manieroj certigi la bezonatan nivelon de konsistenco. Ĝenerala regulo:
NW + NR > RF
Kio signifas ke la nombro da konfirmoj de nodoj dum skribado (NW) kaj plie la nombro da konfirmoj de nodoj dum legado (NR) devas esti pli granda ol la reproduktadfaktoro. En nia kazo, RF = 3, kio signifas, ke la sekvaj opcioj taŭgas:
2 + 2 > 3
3 + 1 > 3
Ĉar estas esence grave por ni konservi la datumojn kiel eble plej fidinde, oni elektis la skemon 3+1. Krome, HB funkcias laŭ simila principo, t.e. tia komparo estos pli justa.
Oni devas rimarki, ke DataStax faris la malon en sia studo, ili starigis RF = 1 por kaj CS kaj HB (por ĉi-lasta ŝanĝante la HDFS-agordojn). Ĉi tio estas vere grava aspekto ĉar la efiko al CS-agado en ĉi tiu kazo estas grandega. Ekzemple, la suba bildo montras la pliiĝon de la tempo necesa por ŝargi datumojn en CS:
Ĉi tie ni vidas la jenon: ju pli konkurantaj fadenoj skribas datumojn, des pli longe ĝi bezonas. Ĉi tio estas natura, sed gravas, ke la rendimento-degenero por RF=3 estas signife pli alta. Alivorte, se ni skribas 4 fadenojn en po 5 tabeloj (20 entute), tiam RF=3 perdas je ĉirkaŭ 2 fojojn (150 sekundoj por RF=3 kontraŭ 75 por RF=1). Sed se ni pliigas la ŝarĝon ŝarĝante datumojn en 8 tabelojn kun 5 fadenoj ĉiu (40 entute), tiam la perdo de RF=3 estas jam 2,7 fojojn (375 sekundoj kontraŭ 138).
Eble ĉi tio estas parte la sekreto de la sukcesa ŝarĝtestado farita de DataStax por CS, ĉar por HB ĉe nia stando ŝanĝi la reproduktan faktoron de 2 al 3 ne efikis. Tiuj. diskoj ne estas la HB-protokolo por nia agordo. Tamen, estas multaj aliaj malfacilaĵoj ĉi tie, ĉar oni devas rimarki, ke nia versio de HB estis iomete flikita kaj tajlita, la medioj estas tute malsamaj, ktp. Ankaŭ indas noti, ke eble mi simple ne scias kiel ĝuste prepari CS kaj ekzistas kelkaj pli efikaj manieroj labori kun ĝi, kaj mi esperas, ke ni ekscios en la komentoj. Sed unue aferojn.
Ĉiuj testoj estis faritaj sur aparataro konsistanta el 4 serviloj, ĉiu kun la sekva agordo:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 fadenoj.
Diskoj: 12 pecoj SATA HDD
java versio: 1.8.0_111
CS-Versio: 3.11.5
cassandra.yml parametrojnombro_tokens: 256
hinted_handoff_enabled: vera
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
aŭthenticator: AllowAllAuthenticator
rajtiganto: AllowAllAuthorizer
role_manager: CassandraRoleManager
roloj_valideco_en_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
diskpartigilo: org.apache.cassandra.dht.Murmur3Partitioner
dosierujoj_datumoj:
- /data1/cassandra/data # ĉiu dataN dosierujo estas aparta disko
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_dosierujo: /data9/cassandra/commitlog
cdc_enabled: malvera
disk_failure_policy: halti
commit_failure_policy: halti
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
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: perioda
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- klas_nomo: org.apache.cassandra.locator.SimpleSeedProvider
parametroj:
— semoj: "*,*"
concurrent_reads: 256 # provita 64 - neniu diferenco rimarkita
concurrent_writes: 256 # provita 64 - neniu diferenco rimarkita
concurrent_counter_writes: 256 # provita 64 - neniu diferenco rimarkita
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # provis 16 GB - ĝi estis pli malrapida
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: malvera
trickle_fsync_interval_in_kb: 10240
stokado_porto: 7000
ssl_storage_port: 7001
aŭskulti_adreson: *
elsendo_adreso: *
listen_on_broadcast_address: vera
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: vera
denaska_transporto: 9042
start_rpc: vera
rpc_adreso: *
rpc_port: 9160
rpc_keepalive: vera
rpc_server_type: sinkronigi
thrift_framed_transport_size_in_mb: 15
incremental_backups: malvera
snapshot_before_compaction: malvera
aŭtomata_foto: vera
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
samtempaj_kompatiloj: 4
compactation_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: malvera
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: neniu
client_encryption_options:
enabled: falsa
internode_compression: dc
inter_dc_tcp_nodelay: malvera
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: malvera
enable_scripted_user_defined_functions: malvera
windows_timer_interval: 1
transparent_data_encryption_options:
enabled: falsa
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_pressure_enabled: malvera
enable_materialized_views: vera
enable_sasi_indexes: vera
GC-agordoj:
### CMS-Agordoj-XX:+UzuParNewGC
-XX:+UzuConcMarkSweepGC
-XX:+CMSParallelRemarkEbligita
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+Uzu CMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
La memoro jvm.options estis asignita 16Gb (ni ankaŭ provis 32 Gb, neniu diferenco estis rimarkita).
La tabeloj estis kreitaj per la komando:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB-versio: 1.2.0-cdh5.14.2 (en la klaso org.apache.hadoop.hbase.regionserver.HRegion ni ekskludis MetricsRegion kiu kondukis al GC kiam la nombro da regionoj estis pli ol 1000 en RegionServer)
Ne-defaŭltaj HBase-parametrojzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minuto(j)
hbase.client.scanner.timeout.period: 2 minuto(j)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minuto(j)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 horo(j)
hbase.regionserver.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 tago(j)
HBase Service Altnivela Agorda Fragmento (Sekureca Valvo) por 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-Agordaj Opcioj por HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minuto(j)
hbase.snapshot.region.timeout: 2 minuto(j)
hbase.snapshot.master.timeout.millis: 2 minuto(j)
HBase REST Servilo Maksimuma Protokolo Grandeco: 100 MiB
HBase REST-Servilo Maksimumaj Logdosiero-Sekurkopioj: 5
HBase Thrift Server Max Log Size: 100 MiB
HBase Thrift Server Maksimumaj Logdosiero-Sekurkopioj: 5
Majstra Maksimuma Protokolo Grandeco: 100 MiB
Majstraj Maksimumaj Protokolo-Sekurkopioj: 5
RegionServer Maksimuma Protokolo Grandeco: 100 MiB
RegionServer Maksimumaj Logdosiero-Sekurkopioj: 5
Fenestro de HBase Active Master Detection: 4 minuto(j)
dfs.client.hedged.read.threadpool.grandeco: 40
dfs.client.hedged.read.threshold.miliis: 10 milisekundoj
hbase.ripozaj.fadenoj.min: 8
hbase.rest.fadenoj.max: 150
Maksimumaj Procezaj Dosieraj Priskriboj: 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.fadenoj: 30
hbase.master.executor.closeregion.fadenoj: 30
hbase.master.executor.serverops.fadenoj: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.grandeco: 20
Fadenoj de Regionaj Moviloj: 6
Kliento Java Heap Grandeco en bajtoj: 1 GiB
HBase REST Server Defaŭlta Grupo: 3 GiB
HBase Thrift Server Defaŭlta Grupo: 3 GiB
Java Heap Size of HBase Master en Bajtoj: 16 GiB
Java Heap Grandeco de HBase RegionServer en Bajtoj: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Krei tabelojn:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
ŝanĝi 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Estas unu grava punkto ĉi tie - la priskribo de DataStax ne diras kiom da regionoj estis uzataj por krei la HB-tabelojn, kvankam ĉi tio estas kritika por grandaj volumoj. Tial por la testoj oni elektis kvanton = 64, kio ebligas stoki ĝis 640 GB, t.e. mezgranda tablo.
En la momento de la testo, HBase havis 22 mil tabelojn kaj 67 mil regionojn (ĉi tio estus mortiga por versio 1.2.0 se ne por la diakilo menciita supre).
Nun por la kodo. Ĉar ne estis klare kiuj agordoj estis pli avantaĝaj por aparta datumbazo, testoj estis faritaj en diversaj kombinaĵoj. Tiuj. en kelkaj testoj, 4 tabloj estis ŝarĝitaj samtempe (ĉiuj 4 nodoj estis uzitaj por konekto). En aliaj provoj ni laboris kun 8 malsamaj tabeloj. En kelkaj kazoj, la arograndeco estis 100, en aliaj 200 (aroj-parametro - vidu kodon malsupre). La datumgrandeco por valoro estas 10 bajtoj aŭ 100 bajtoj (dataSize). Entute, 5 milionoj da rekordoj estis skribitaj kaj legitaj en ĉiu tabelo ĉiufoje. Samtempe, 5 fadenoj estis skribitaj/legitaj al ĉiu tabelo (fadena nombro - thNum), ĉiu el kiuj uzis sian propran gamon da ŝlosiloj (kalkulo = 1 miliono):
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);
}
}
Sekve, simila funkcieco estis disponigita por 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 en HB la kliento devas prizorgi la unuforman distribuadon de datumoj, la ŝlosila sala funkcio aspektis jene:
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);
}
Nun la plej interesa parto - la rezultoj:
La sama afero en grafika formo:
La avantaĝo de HB estas tiel surpriza, ke ekzistas suspekto, ke ekzistas ia botelkolo en la aranĝo de CS. Tamen, Guglado kaj serĉado de la plej evidentaj parametroj (kiel concurrent_writes aŭ memtable_heap_space_in_mb) ne rapidigis aferojn. Samtempe, la ŝtipoj estas puraj kaj nenion ĵuras.
La datumoj estis distribuitaj egale tra la nodoj, la statistikoj de ĉiuj nodoj estis proksimume samaj.
Jen kiel aspektas la tabelaj statistikoj de unu el la nodojKeyspace: ks
Legkalkulo: 9383707
Lega Latenteco: 0.04287025042448576 ms
Skribkalkulo: 15462012
Skriba Latenteco: 0.1350068438699957 ms
Atendantaj Fluĝoj: 0
Tablo: t1
SSTtable nombro: 16
Spaco uzata (viva): 148.59 MiB
Spaco uzata (tute): 148.59 MiB
Spaco uzata de momentfotoj (totalo): 0 bajtoj
Uzita senhepa memoro (totalo): 5.17 MiB
SSTable Kunprema Proporcio: 0.5720989576459437
Nombro da sekcioj (taksado): 3970323
Memebla ĉelkalkulo: 0
Memebla datuma grandeco: 0 bajtoj
Memorebla ekstera amaso uzata: 0 bajtoj
Memorebla ŝaltilo-nombro: 5
Loka legado: 2346045
Loka legado latenteco: NaN ms
Loka skribnombro: 3865503
Loka skriba latenco: NaN ms
Atendantaj ruĝoj: 0
Procento riparita: 0.0
Florfiltrilo de falsaj pozitivoj: 25
Florfiltrilo falsa proporcio: 0.00000
Bloom-filtrila spaco uzata: 4.57 MiB
Bloom-filtrilo de amasmemoro uzata: 4.57 MiB
Indeksa resumo de amasmemoro uzata: 590.02 KiB
Kunpremaj metadatenoj el amasmemoro uzata: 19.45 KiB
Kompaktigitaj subdiskoj minimumaj bajtoj: 36
Kompaktigita subdisko maksimumaj bajtoj: 42
Kompaktigitaj subdiskoj averaĝaj bajtoj: 42
Mezumaj vivaj ĉeloj per tranĉaĵo (lastaj kvin minutoj): NaN
Maksimumaj vivaj ĉeloj per tranĉaĵo (lastaj kvin minutoj): 0
Mezumaj tomboŝtonoj per tranĉaĵo (lastaj kvin minutoj): NaN
Maksimumaj tomboŝtonoj per tranĉaĵo (lastaj kvin minutoj): 0
Forigitaj Mutacioj: 0 bajtoj
Provo redukti la grandecon de la aro (eĉ sendi ĝin individue) havis neniun efikon, ĝi nur plimalboniĝis. Eblas, ke fakte ĉi tio estas vere la maksimuma rendimento por CS, ĉar la rezultoj akiritaj por CS estas similaj al tiuj akiritaj por DataStax - ĉirkaŭ centoj da miloj da operacioj sekundo. Krome, se ni rigardas rimedan utiligon, ni vidos, ke CS uzas multe pli da CPU kaj diskoj:
La figuro montras la utiligon dum la kuro de ĉiuj testoj en vico por ambaŭ datumbazoj.
Koncerne la potencan legan avantaĝon de HB. Ĉi tie vi povas vidi, ke por ambaŭ datumbazoj, diskuzado dum legado estas ekstreme malalta (legaj testoj estas la fina parto de la testada ciklo por ĉiu datumbazo, ekzemple por CS tio estas de 15:20 ĝis 15:40). En la kazo de HB, la kialo estas klara - la plej multaj el la datumoj pendas en memoro, en la memstore, kaj iuj estas konservitaj en blokkaŝmemoro. Koncerne CS, estas ne tre klare kiel ĝi funkcias, sed disko reciklado ankaŭ ne videblas, sed ĉiaokaze, oni provis ebligi la kaŝmemoron row_cache_size_in_mb = 2048 kaj agordi kaŝmemoron = {'keys': 'ALL', 'rows_per_partition': '2000000'}, sed tio eĉ iomete plimalbonigis.
Menciindas ankaŭ refoje gravan punkton pri la nombro de regionoj en HB. En nia kazo, la valoro estis specifita kiel 64. Se vi reduktas ĝin kaj faras ĝin egala al, ekzemple, 4, tiam dum legado, la rapido malpliiĝas je 2 fojojn. La kialo estas, ke memstore pleniĝos pli rapide kaj dosieroj estos fluitaj pli ofte kaj dum legado, pli da dosieroj devos esti prilaboritaj, kio estas sufiĉe komplika operacio por HB. En realaj kondiĉoj, ĉi tio povas esti traktita pensante per antaŭdisigo kaj kompaktiga strategio; precipe, ni uzas memskribitan ilon, kiu kolektas rubon kaj kunpremas HFilojn konstante en la fono. Estas tute eble, ke por DataStax-testoj ili asignis nur 1 regionon per tabelo (kio ne estas ĝusta) kaj tio iom klarigus kial HB estis tiel malsupera en siaj legotestoj.
El tio estas eltirita la sekvaj antaŭaj konkludoj. Supozante ke neniuj gravaj eraroj estis faritaj dum testado, tiam Kasandra aspektas kiel koloso kun piedoj da argilo. Pli precize, dum ŝi balanciĝas sur unu kruro, kiel en la bildo komence de la artikolo, ŝi montras relative bonajn rezultojn, sed en batalo sub la samaj kondiĉoj ŝi tute perdas. Samtempe, konsiderante la malaltan CPU-uzadon sur nia aparataro, ni lernis planti du RegionServer HB-ojn per gastiganto kaj tiel duobligis la rendimenton. Tiuj. Konsiderante la utiligon de rimedoj, la situacio por CS estas eĉ pli bedaŭrinda.
Kompreneble, ĉi tiuj provoj estas sufiĉe sintezaj kaj la kvanto de datumoj uzataj ĉi tie estas relative modesta. Eblas, ke se ni ŝanĝus al terabajtoj, la situacio estus malsama, sed dum por HB ni povas ŝarĝi terabajtojn, por CS tio montriĝis problema. Ĝi ofte ĵetis OperationTimedOutException eĉ kun ĉi tiuj volumoj, kvankam la parametroj por atendado de respondo jam estis pliigitaj plurfoje kompare kun la defaŭltaj.
Mi esperas, ke per komunaj klopodoj ni trovos la proplempunktojn de CS kaj se ni povos akceli ĝin, tiam ĉe la fino de la afiŝo mi certe aldonos informojn pri la finrezultoj.
UPD: Danke al la konsilo de kamaradoj, mi sukcesis plirapidigi la legadon. Estis:
159 operacioj (644 tabloj, 4 riveretoj, aro 5).
Aldonita:
.withLoadBalancingPolicy(nova TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Kaj mi ludis kun la nombro da fadenoj. La rezulto estas la sekva:
4 tabloj, 100 fadenoj, aro = 1 (peco post peco): 301 opcioj
4 tabloj, 100 fadenoj, aro = 10: 447 operacioj
4 tabloj, 100 fadenoj, aro = 100: 625 operacioj
Poste mi aplikos aliajn agordajn konsiletojn, funkcios plenan testan ciklon kaj aldonos la rezultojn ĉe la fino de la afiŝo.
fonto: www.habr.com