Tämä ei ole edes vitsi, näyttää siltä, että tämä kuva heijastaa tarkimmin näiden tietokantojen olemusta, ja lopulta on selvää, miksi:
DB-Engines Rankingin mukaan kaksi suosituinta NoSQL-saraketietokantaa ovat Cassandra (jäljempänä CS) ja HBase (HB).
Kohtalon tahdosta Sberbankin tiedonlatauksen hallintatiimimme on jo tehnyt ja tekee tiivistä yhteistyötä HB:n kanssa. Tänä aikana opimme sen vahvuudet ja heikkoudet melko hyvin ja opimme valmistamaan sitä. Kuitenkin vaihtoehdon läsnäolo CS:n muodossa pakotti meidät aina piinaamaan itseämme hieman epäilyksillä: teimmekö oikean valinnan? Lisäksi tulokset DataStaxin suorittamana, he sanoivat, että CS päihittää HB:n helposti melkein murskauspisteillä. Toisaalta DataStax on kiinnostunut osapuoli, eikä sinun pidä uskoa heidän sanaansa. Meitä hämmensi myös melko vähäinen tietomäärä testausolosuhteista, joten päätimme selvittää itse, kuka on BigData NoSql:n kuningas, ja saadut tulokset osoittautuivat erittäin mielenkiintoisiksi.
Ennen kuin siirrytään suoritettujen testien tuloksiin, on kuitenkin tarpeen kuvata ympäristökonfiguraatioiden merkittävät näkökohdat. Tosiasia on, että CS:tä voidaan käyttää tilassa, joka sallii tietojen menetyksen. Nuo. Tällöin vain yksi palvelin (solmu) vastaa tietyn avaimen tiedoista, ja jos se jostain syystä epäonnistuu, tämän avaimen arvo menetetään. Monille tehtäville tämä ei ole kriittistä, mutta pankkisektorille tämä on pikemminkin poikkeus kuin sääntö. Meidän tapauksessamme on tärkeää, että tiedoista on useita kopioita luotettavaa tallennusta varten.
Siksi huomioitiin vain CS-toimintatila kolmoistoistotilassa, ts. Tapaustilan luominen suoritettiin seuraavilla parametreilla:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Seuraavaksi on kaksi tapaa varmistaa vaadittu johdonmukaisuus. Yleissääntö:
NW + NR > RF
Tämä tarkoittaa, että solmujen vahvistusten lukumäärän kirjoittamisen aikana (NW) plus solmujen vahvistusten lukumäärän lukemisen aikana (NR) on oltava suurempi kuin replikointikerroin. Meidän tapauksessamme RF = 3, mikä tarkoittaa, että seuraavat vaihtoehdot ovat sopivia:
2 + 2 > 3
3 + 1 > 3
Koska meille on olennaisen tärkeää tallentaa tiedot mahdollisimman luotettavasti, valittiin 3+1-malli. Lisäksi HB toimii samalla periaatteella, ts. tällainen vertailu on oikeudenmukaisempi.
On huomattava, että DataStax teki tutkimuksessaan päinvastoin, he asettivat RF = 1 sekä CS:lle että HB:lle (jälkimmäiselle muuttamalla HDFS-asetuksia). Tämä on todella tärkeä näkökohta, koska vaikutus CS:n suorituskykyyn on tässä tapauksessa valtava. Esimerkiksi alla oleva kuva näyttää pidentyneen ajan, joka tarvitaan tietojen lataamiseen CS:ään:
Tässä näemme seuraavan: mitä enemmän kilpailevia säikeitä kirjoittaa dataa, sitä kauemmin se kestää. Tämä on luonnollista, mutta on tärkeää, että RF=3:n suorituskyvyn heikkeneminen on huomattavasti suurempi. Toisin sanoen, jos kirjoitamme 4 säiettä 5 taulukkoon kuhunkin (yhteensä 20), niin RF=3 häviää noin 2 kertaa (150 sekuntia RF=3:lle vs. 75 RF=1:lle). Mutta jos lisäämme kuormitusta lataamalla tietoja 8 taulukkoon, joissa kussakin on 5 säiettä (yhteensä 40), RF=3:n menetys on jo 2,7-kertainen (375 sekuntia vs. 138).
Ehkä tämä on osittain DataStaxin CS:lle suorittaman kuormitustestauksen salaisuus, koska HB:lle osastollamme replikointikertoimen vaihtaminen 2:sta 3:een ei vaikuttanut mitenkään. Nuo. levyt eivät ole HB:n pullonkaula kokoonpanollemme. Tässä on kuitenkin monia muita sudenkuoppia, koska on huomioitava, että HB-versiotamme on hieman korjattu ja muokattu, ympäristöt ovat täysin erilaisia jne. On myös syytä huomata, että ehkä en vain osaa valmistaa CS:ää oikein ja on olemassa joitain tehokkaampia tapoja työskennellä sen kanssa, ja toivon, että saamme sen selville kommenteissa. Mutta ensin asiat ensin.
Kaikki testit suoritettiin laitteistoklusterilla, joka koostui 4 palvelimesta, joista jokaisella oli seuraava kokoonpano:
CPU: Xeon E5-2680 v4 @ 2.40 GHz 64 säiettä.
Levyt: 12 kpl SATA HDD
java-versio: 1.8.0_111
CS-versio: 3.11.5
cassandra.yml-parametrejamerkkien_määrä: 256
hinted_handoff_enabled: tosi
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
vihjeet_hakemisto: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
autentikaattori: AllowAllAuthenticator
Authorizer: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
osioija: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # jokainen dataN-hakemisto on erillinen levy
- /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: false
disk_failure_policy: stop
commit_failure_policy: stop
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
rivi_välimuistin_tallennusjakso: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: jaksollinen
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- luokan_nimi: org.apache.cassandra.locator.SimpleSeedProvider
parametrit:
- siemenet: "*,*"
concurrent_reads: 256 # yrittänyt 64 - eroa ei havaittu
concurrent_writes: 256 # yrittänyt 64 - eroa ei havaittu
concurrent_counter_writes: 256 # yrittänyt 64 - eroa ei havaittu
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # yritti 16 Gt - se oli hitaampi
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: false
trickle_fsync_interval_in_kb: 10240
tallennusportti: 7000
ssl_storage_port: 7001
kuuntele_osoite: *
lähetysosoite: *
listen_on_broadcast_address: true
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: tosi
native_transport_port: 9042
start_rpc: totta
rpc_address: *
rpc_port: 9160
rpc_keepalive: totta
rpc_server_type: synkronointi
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: totta
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: false
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynaaminen_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: ei mitään
client_encryption_options:
käytössä: false
internode_compression: dc
inter_dc_tcp_nodelay: false
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
transparent_data_encryption_options:
käytössä: false
tombstone_warn_threshold: 1000
hautakivi_vikakynnys: 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: false
enable_materialized_views: tosi
enable_sasi_indexes: tosi
GC-asetukset:
### CMS-asetukset-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+KäytäCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
jvm.options-muistille varattiin 16 Gt (yritimme myös 32 Gt, eroa ei havaittu).
Taulukot luotiin komennolla:
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 (luokassa org.apache.hadoop.hbase.regionserver.HRegion poistimme MetricsRegionin, joka johti GC:hen, kun alueiden lukumäärä oli yli 1000 RegionServerissä)
Muut kuin oletusarvoiset HBase-parametritzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minuuttia
hbase.client.scanner.timeout.period: 2 minuutti(a)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minuutti(a)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionsserver.logroll.period: 4 tunti(a)
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 päivä(ä)
HBase Service Advanced Configuration Snippet (turvaventtiili) hbase-site.xml:lle:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionsserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionsserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Java-määritysasetukset HBase RegionServerille:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minuutti(a)
hbase.snapshot.region.timeout: 2 minuuttia
hbase.snapshot.master.timeout.millis: 2 minuutti(a)
HBase REST -palvelimen enimmäiskoko: 100 MiB
HBase REST -palvelimen lokitiedostojen varmuuskopioiden enimmäismäärä: 5
HBase Thrift -palvelimen enimmäislokikoko: 100 MiB
HBase Thrift Server Lokitiedostojen varmuuskopioiden enimmäismäärä: 5
Master Max lokin koko: 100 MiB
Lokitiedostojen enimmäisvarmuuskopiot: 5
Aluepalvelimen maksimilokikoko: 100 MiB
RegionServer Lokitiedostojen varmuuskopioiden enimmäismäärä: 5
HBase Active Master -tunnistusikkuna: 4 minuuttia
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 millisekuntia
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Prosessitiedostojen enimmäiskuvaajat: 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.size: 20
Region Mover -ketjut: 6
Asiakkaan Java-keon koko tavuina: 1 GiB
HBase REST -palvelimen oletusryhmä: 3 GiB
HBase Thrift Server -oletusryhmä: 3 GiB
Java-keon HBase Masterin koko tavuina: 16 GiB
HBase RegionServerin Java-keon koko tavuina: 32 GiB
+ ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Taulukoiden luominen:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Tässä on yksi tärkeä seikka - DataStax-kuvaus ei kerro kuinka monta aluetta käytettiin HB-taulukoiden luomiseen, vaikka tämä on kriittinen suurille volyymeille. Siksi testeihin valittiin määrä = 64, joka mahdollistaa jopa 640 Gt:n tallennuksen, ts. keskikokoinen pöytä.
Testin aikaan HBasella oli 22 tuhatta taulukkoa ja 67 tuhatta aluetta (tämä olisi ollut tappava versiolle 1.2.0, ellei yllä mainittu korjaustiedosto).
Nyt koodiin. Koska ei ollut selvää, mitkä konfiguraatiot olivat edullisempia tietylle tietokannalle, testejä suoritettiin eri yhdistelmillä. Nuo. joissakin testeissä 4 taulukkoa ladattiin samanaikaisesti (kaikkia 4 solmua käytettiin yhdistämiseen). Muissa testeissä työskentelimme 8 eri pöydän kanssa. Joissakin tapauksissa eräkoko oli 100, toisissa 200 (eräparametri - katso koodi alla). Arvon datakoko on 10 tavua tai 100 tavua (dataSize). Jokaiseen taulukkoon kirjoitettiin ja luettiin yhteensä 5 miljoonaa tietuetta joka kerta. Samanaikaisesti kuhunkin taulukkoon kirjoitettiin/luettiin 5 säiettä (säikeen numero - thNum), joista jokainen käytti omaa avainaluettaan (luku = 1 miljoonaa):
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);
}
}
Vastaavasti HB:lle tarjottiin vastaavat toiminnot:
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);
}
}
Koska HB:ssä asiakkaan on huolehdittava tietojen tasaisesta jakautumisesta, avaimen suolaustoiminto näytti tältä:
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);
}
Nyt mielenkiintoisin osa - tulokset:
Sama asia graafisessa muodossa:
HB:n etu on niin yllättävä, että CS-asetuksissa epäillään olevan jonkinlainen pullonkaula. Googlaaminen ja ilmeisimpien parametrien (kuten concurrent_writes tai memtable_heap_space_in_mb) etsiminen ei kuitenkaan nopeuttanut asioita. Samaan aikaan puut ovat puhtaita eivätkä kiroile mitään.
Tiedot jakautuivat tasaisesti solmujen kesken, tilastot kaikista solmuista olivat suunnilleen samat.
Tältä taulukon tilastot näyttävät yhdestä solmustaNäppäinavaruus: ks
Lukumäärä: 9383707
Lukuviive: 0.04287025042448576 ms
Kirjoitusmäärä: 15462012
Kirjoitusviive: 0.1350068438699957 ms
Odottavat värit: 0
Taulukko: t1
SST-taulukkojen määrä: 16
Käytetty tila (live): 148.59 MiB
Käytetty tila (yhteensä): 148.59 MiB
Tilannekuvien käyttämä tila (yhteensä): 0 tavua
Käytetty off-keon muisti (yhteensä): 5.17 MiB
SSTable-pakkaussuhde: 0.5720989576459437
Osioiden lukumäärä (arvio): 3970323
Muistettavissa olevien solujen määrä: 0
Muistettavan tiedon koko: 0 tavua
Käytetty muistiin jäävä keon muisti: 0 tavua
Muistettava kytkinten määrä: 5
Paikallinen lukumäärä: 2346045
Paikallinen lukuviive: NaN ms
Paikallinen kirjoitusmäärä: 3865503
Paikallinen kirjoitusviive: NaN ms
Odottavat värit: 0
Korjausprosentti: 0.0
Bloom-suodattimen vääriä positiivisia tuloksia: 25
Bloom-suodattimen väärä suhde: 0.00000
Käytetty Bloom-suodatintila: 4.57 MiB
Käytetty Bloom-suodatin kasamuisti: 4.57 MiB
Indeksin yhteenveto käytetystä kasamuistista: 590.02 KiB
Pakkauksen metatiedot käytetystä kasamuistista: 19.45 KiB
Pakatun osion vähimmäistavu: 36
Tiivistetyn osion enimmäistavuja: 42
Pakatun osion keskimääräiset tavut: 42
Keskimääräinen elävien solujen määrä siivua kohti (viimeiset viisi minuuttia): NaN
Elävien solujen enimmäismäärä siivua kohden (viimeiset viisi minuuttia): 0
Keskimääräiset hautakivet per viipale (viimeiset viisi minuuttia): NaN
Hautakivien enimmäismäärä siivua kohden (viimeiset viisi minuuttia): 0
Poistetut mutaatiot: 0 tavua
Yrityksellä pienentää erän kokoa (edes lähettäminen yksittäin) ei ollut vaikutusta, se vain paheni. On mahdollista, että itse asiassa tämä on todellakin CS:n suurin suorituskyky, koska CS:llä saadut tulokset ovat samanlaisia kuin DataStaxilla - noin satoja tuhansia operaatioita sekunnissa. Lisäksi, jos tarkastelemme resurssien käyttöä, huomaamme, että CS käyttää paljon enemmän suoritinta ja levyjä:
Kuvassa näkyy käyttöaste kaikkien peräkkäisten testien ajon aikana molemmille tietokannoille.
Mitä tulee HB:n tehokkaaseen lukuetuun. Tästä näet, että molemmissa tietokannoista levyn käyttöaste lukemisen aikana on erittäin alhainen (lukutestit ovat kunkin tietokannan testaussyklin viimeinen osa, esimerkiksi CS:ssä tämä on 15:20 - 15:40). HB:n tapauksessa syy on selvä - suurin osa tiedoista roikkuu muistissa, memstoressa ja osa on välimuistissa lohkovälimuistissa. CS:n osalta ei ole kovin selvää, miten se toimii, mutta levyn kierrätystä ei myöskään näy, mutta varmuuden vuoksi yritettiin ottaa käyttöön välimuisti row_cache_size_in_mb = 2048 ja asettaa välimuisti = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, mutta se pahensi tilannetta vielä hieman.
On myös syytä mainita jälleen kerran tärkeä seikka HB:n alueiden lukumäärästä. Meidän tapauksessamme arvoksi määritettiin 64. Jos pienennät sitä ja teet sen esimerkiksi 4:ksi, niin nopeus laskee 2 kertaa luettaessa. Syynä on se, että memstore täyttyy nopeammin ja tiedostoja huuhdellaan useammin ja luettaessa tiedostoja tulee käsitellä enemmän, mikä on HB:lle melko monimutkainen toimenpide. Todellisissa olosuhteissa tämä voidaan hoitaa ajattelemalla esijakamis- ja tiivistysstrategiaa; käytämme erityisesti itse kirjoitettua apuohjelmaa, joka kerää roskat ja pakkaa HF-tiedostoja jatkuvasti taustalla. On täysin mahdollista, että DataStax-testeihin he varasivat vain yhden alueen taulukkoa kohden (mikä ei ole oikein), ja tämä selventää jonkin verran, miksi HB oli niin huonompi heidän lukutesteissään.
Tästä tehdään seuraavat alustavat johtopäätökset. Olettaen, että testauksen aikana ei tehty suuria virheitä, Cassandra näyttää kolossilta, jolla on savijalat. Tarkemmin sanottuna, vaikka hän tasapainoilee yhdellä jalalla, kuten artikkelin alussa olevassa kuvassa, hän näyttää suhteellisen hyviä tuloksia, mutta taistelussa samoissa olosuhteissa hän häviää suoraan. Samaan aikaan, kun otetaan huomioon laitteistomme alhainen suorittimen käyttöaste, opimme asentamaan kaksi RegionServer HB:tä isäntä kohden ja siten kaksinkertaistimme suorituskyvyn. Nuo. Resurssien käyttö huomioon ottaen CS:n tilanne on vieläkin valitettavampi.
Tietenkin nämä testit ovat melko synteettisiä ja tässä käytetty datamäärä on suhteellisen vaatimaton. On mahdollista, että jos vaihtaisimme teratavuihin, tilanne olisi toinen, mutta kun HB:lle voimme ladata teratavuja, niin CS: lle tämä osoittautui ongelmalliseksi. Usein se heitti OperationTimedOutExceptionin näilläkin volyymeilla, vaikka vastauksen odotusparametreja nostettiin jo useita kertoja oletusarvoihin verrattuna.
Toivon, että yhteisin ponnistuksin löydämme CS:n pullonkaulat ja jos voimme nopeuttaa sitä, niin postauksen loppuun lisään ehdottomasti tietoa lopputuloksista.
UPD: Tovereiden neuvojen ansiosta onnistuin nopeuttamaan lukemista. Oli:
159 644 oppeja (4 pöytää, 5 striimiä, erä 100).
Lisätty:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Ja leikittelin lankojen lukumäärällä. Tulos on seuraava:
4 pöytää, 100 lankaa, erä = 1 (pala palalta): 301 969 ops
4 pöytää, 100 säiettä, erä = 10: 447 608 toimintoa
4 pöytää, 100 säiettä, erä = 100: 625 655 toimintoa
Myöhemmin käytän muita viritysvinkkejä, suoritan täyden testisyklin ja lisään tulokset postauksen loppuun.
Lähde: will.com