Huu sio utani hata, inaonekana kwamba picha hii inaonyesha kwa usahihi kiini cha hifadhidata hizi, na mwishowe itakuwa wazi kwa nini:
Kulingana na Nafasi ya DB-Injini, hifadhidata mbili maarufu za safu wima za NoSQL ni Cassandra (hapa CS) na HBase (HB).
Kwa mapenzi ya hatima, timu yetu ya usimamizi wa upakiaji data katika Sberbank tayari ina na inafanya kazi kwa karibu na HB. Wakati huu, tulijifunza nguvu na udhaifu wake vizuri na kujifunza jinsi ya kupika. Walakini, uwepo wa njia mbadala katika mfumo wa CS kila wakati ulitulazimisha kujitesa kidogo na mashaka: tulifanya chaguo sahihi? Aidha, matokeo , iliyofanywa na DataStax, walisema kuwa CS hupiga HB kwa urahisi na karibu alama ya kusagwa. Kwa upande mwingine, DataStax ni mtu anayevutiwa, na hupaswi kuchukua neno lao kwa hilo. Pia tulichanganyikiwa na kiasi kidogo cha habari kuhusu hali ya majaribio, kwa hivyo tuliamua kujua sisi wenyewe ni nani mfalme wa BigData NoSql, na matokeo yaliyopatikana yalipendeza sana.
Hata hivyo, kabla ya kuendelea na matokeo ya vipimo vilivyofanywa, ni muhimu kuelezea vipengele muhimu vya usanidi wa mazingira. Ukweli ni kwamba CS inaweza kutumika katika hali ambayo inaruhusu kupoteza data. Wale. hii ni wakati seva moja tu (node) inawajibika kwa data ya ufunguo fulani, na ikiwa kwa sababu fulani inashindwa, basi thamani ya ufunguo huu itapotea. Kwa kazi nyingi hii sio muhimu, lakini kwa sekta ya benki hii ni ubaguzi badala ya sheria. Kwa upande wetu, ni muhimu kuwa na nakala kadhaa za data kwa hifadhi ya kuaminika.
Kwa hiyo, tu hali ya uendeshaji ya CS katika hali ya kuiga mara tatu ilizingatiwa, i.e. Uundaji wa nafasi ya kesi ulifanywa na vigezo vifuatavyo:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Ifuatayo, kuna njia mbili za kuhakikisha kiwango kinachohitajika cha uthabiti. Kanuni ya jumla:
NW + NR > RF
Ambayo ina maana kwamba idadi ya uthibitisho kutoka kwa nodi wakati wa kuandika (NW) pamoja na idadi ya uthibitisho kutoka kwa nodi wakati wa kusoma (NR) lazima iwe kubwa kuliko sababu ya kurudia. Kwa upande wetu, RF = 3, ambayo ina maana chaguzi zifuatazo zinafaa:
2 + 2 > 3
3 + 1 > 3
Kwa kuwa ni muhimu sana kwetu kuhifadhi data kwa uhakika iwezekanavyo, mpango wa 3+1 ulichaguliwa. Kwa kuongeza, HB inafanya kazi kwa kanuni sawa, i.e. Ulinganisho kama huo utakuwa wa haki zaidi.
Ikumbukwe kwamba DataStax ilifanya kinyume katika utafiti wao, waliweka RF = 1 kwa CS na HB (kwa mwisho kwa kubadilisha mipangilio ya HDFS). Hiki ni kipengele muhimu sana kwa sababu athari kwa utendaji wa CS katika kesi hii ni kubwa. Kwa mfano, picha iliyo hapa chini inaonyesha ongezeko la muda unaohitajika kupakia data kwenye CS:
Hapa tunaona yafuatayo: nyuzi zinazoshindana zaidi zinaandika data, inachukua muda mrefu. Hii ni ya asili, lakini ni muhimu kwamba uharibifu wa utendaji kwa RF=3 ni wa juu zaidi. Kwa maneno mengine, ikiwa tutaandika nyuzi 4 kwenye jedwali 5 kila moja (20 kwa jumla), basi RF=3 inapoteza kwa karibu mara 2 (sekunde 150 kwa RF=3 dhidi ya 75 kwa RF=1). Lakini ikiwa tunaongeza mzigo kwa kupakia data kwenye meza 8 na nyuzi 5 kila moja (40 kwa jumla), basi kupoteza kwa RF = 3 tayari ni mara 2,7 (sekunde 375 dhidi ya 138).
Labda hii ni sehemu ya siri ya upimaji wa mzigo uliofanikiwa uliofanywa na DataStax kwa CS, kwa sababu kwa HB kwenye msimamo wetu kubadilisha kipengele cha replication kutoka 2 hadi 3 hakuwa na athari yoyote. Wale. diski sio kizuizi cha HB kwa usanidi wetu. Hata hivyo, kuna vikwazo vingine vingi hapa, kwa sababu ni lazima ieleweke kwamba toleo letu la HB lilipigwa kidogo na kuunganishwa, mazingira ni tofauti kabisa, nk. Pia ni muhimu kuzingatia kwamba labda sijui jinsi ya kuandaa CS kwa usahihi na kuna baadhi ya njia za ufanisi zaidi za kufanya kazi nayo, na natumaini tutajua katika maoni. Lakini mambo ya kwanza kwanza.
Majaribio yote yalifanywa kwenye nguzo ya maunzi yenye seva 4, kila moja ikiwa na usanidi ufuatao:
CPU: Xeon E5-2680 v4 @ nyuzi 2.40GHz 64.
Disks: vipande 12 vya SATA HDD
toleo la java: 1.8.0_111
Toleo la CS: 3.11.5
vigezo vya cassandra.ymlnambari_ishara: 256
hinted_handoff_enabled: kweli
alidokeza_handoff_throttle_in_kb: 1024
nyuzi_za_madokezo_max: 2
hints_directory: /data10/cassandra/hints
Vidokezo_vya_muda_katika_ms: 10000
max_hints_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
kithibitishaji: AllowAllAuthenticator
idhini: RuhusuAllAuthorizer
role_manager: CassandraRoleManager
majukumu_uhalali_katika_ms: 2000
ruhusa_uhalali_katika_ms: 2000
sifa_uhalali_katika_ms: 2000
kigawa: org.apache.cassandra.dht.Murmur3Partitioner
saraka_faili_za_data:
- /data1/cassandra/data # kila saraka ya dataN ni diski tofauti
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
dhamira_ya_ya_data: /data9/cassandra/commitlog
cdc_enabled: uongo
diski_failure_sera: acha
sera_ya_kutofaulu: acha
tayari_taarifa_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
saizi_ya_kache_mlalo_katika_mb: 0
kipindi_cha_hifadhi_kache_mlalo: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: mara kwa mara
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
mtoa_mbegu:
- jina_la_darasa: org.apache.cassandra.locator.SimpleSeedProvider
vigezo:
- mbegu: "*,*"
concurrent_reads: 256 # ilijaribu 64 - hakuna tofauti iliyoonekana
concurrent_writes: 256 # walijaribu 64 - hakuna tofauti iliyoonekana
concurrent_counter_writes: 256 # walijaribu 64 - hakuna tofauti iliyoonekana
mwonekano_wa_vifaa_pamoja_huandika: 32
memtable_heap_space_in_mb: 2048 # ilijaribu GB 16 - ilikuwa polepole
memtable_allocation_aina: lundo_bafa
index_summary_capacity_katika_mb:
index_summary_resize_interval_in_dakika: 60
trickle_fsync: uongo
trickle_fsync_interval_in_kb: 10240
Hifadhi_bandari: 7000
ssl_storage_bandari: 7001
sikiliza_anwani: *
tangaza_anwani: *
sikiliza_kwenye_matangazo_anuani: kweli
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: kweli
Usafiri_wa_wa_wa_bandari: 9042
start_rpc: kweli
rpc_anwani: *
bandari_ya_rpc: 9160
rpc_keepalive: kweli
rpc_server_aina: kusawazisha
thrift_framed_transport size_in_mb: 15
incremental_backups: uongo
snapshot_before_compaction: uongo
auto_snapshot: kweli
saizi_ya_safu_ya_katika_kb: 64
saizi_ya_kielezo_cha_kache_katika_kb: 2
kompakt_pamoja: 4
compaction_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
soma_request_timeout_ms: 100000
range_request_timeout_ms: 200000
write_request_timeout_ms: 40000
counter_write_request_timeout_ins: 100000
ca_contention_timeout_in_ms: 20000
punguza_request_timeout_ins: 60000
request_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: sivyo
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_ins_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
chaguzi_za_simbuaji_za_seva:
internode_encryption: hakuna
Chaguo_za_simbuaji_za_mteja:
kuwezeshwa: uongo
internode_compression: dc
inter_dc_tcp_nodelay: uongo
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: uongo
enable_scripted_user_defined_functions: uongo
windows_timer_interval: 1
chaguzi_za_usimbuaji_wa_data_wazi:
kuwezeshwa: uongo
tombstone_onya_kizingiti: 1000
kaburi_la_kutofaulu_kizingiti: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
bechi_iliyofunguliwa_katika_vitengo_onya_kizingiti: 10
compaction_partition_large_onyo_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: uongo
enable_materialized_views: kweli
enable_sasi_indexes: kweli
Mipangilio ya GC:
### Mipangilio ya CMS-XX:+TumiaParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkImewashwa
-XX:Uwiano wa Aliyenusurika=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+TumiaCMSIInitiatingOccupancyPekee
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkImewashwa
-XX:+CMSEdenChunksRecordDaima
-XX:+CMSClassUnloadingImewashwa
Kumbukumbu ya jvm.options ilitengwa 16Gb (pia tulijaribu 32 Gb, hakuna tofauti iliyoonekana).
Jedwali ziliundwa kwa amri:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Toleo la HB: 1.2.0-cdh5.14.2 (katika darasa org.apache.hadoop.hbase.regionserver.HRegion hatukujumuisha MetricsRegion ambayo ilisababisha GC wakati idadi ya maeneo ilikuwa zaidi ya 1000 kwenye RegionServer)
Vigezo vya HBase visivyo chaguomsingizookeeper.session.timeout: 120000
hbase.rpc.timeout: dakika 2
hbase.client.scanner.timeout.period: dakika 2(s)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: dakika 2(s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: Saa 4(saa)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: GiB 1
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionKizingiti: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: siku 1(siku)
Kijisehemu cha Usanidi wa Kina wa Huduma ya HBase (Valve ya Usalama) ya 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
Chaguzi za Usanidi wa Java kwa HBase RegionServer:
-XX:+TumiaParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkImewezeshwa -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: dakika 2(s)
hbase.snapshot.region.timeout: dakika 2(s)
hbase.snapshot.master.timeout.millis: dakika 2(s)
HBase REST Server Max Ukubwa wa logi: 100 MiB
Hifadhi Nakala za Hifadhidata za Seva ya HBase REST: 5
Ukubwa wa logi wa Seva ya HBase Thrift Max: 100 MiB
Hifadhi Nakala za Hifadhidata za Seva ya HBase Thrift: 5
Ukubwa wa logi wa Max Max: 100 MiB
Upeo wa Hifadhi Nakala za Faili za Kumbukumbu: 5
Ukubwa wa Regi ya Seva ya Mkoa: MiB 100
Upeo wa Hifadhi Nakala za Faili za Kumbukumbu za Seva ya Mkoa: 5
Dirisha la Utambuzi la HBase Active Master: dakika 4
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: milisekunde 10
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Upeo wa Maelezo ya Faili ya Mchakato: 180000
hbase.thrift.minWorkerThreads: 200
nyuzi.hbase.master.mtekelezaji.openregion: 30
nyuzi.za.master.mtekelezaji.za.karibu: 30
nyuzi.hbase.master.executor.serverops: 60
hbase.regionserver.thread.compaction.ndogo: 6
hbase.ipc.server.read.threadpool.size: 20
Nyuzi za Kusogeza Mkoa: 6
Ukubwa wa Lundo la Java ya Mteja katika Baiti: 1 GiB
Kundi Chaguomsingi la Seva ya HBase REST: 3 GiB
Kundi Chaguomsingi la Seva ya HBase Thrift: 3 GiB
Ukubwa wa Lundo la Java la Mwalimu wa HBase katika Baiti: 16 GiB
Java Lundo Ukubwa wa HBase RegionServer katika Bytes: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Kutengeneza meza:
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'}
Kuna jambo moja muhimu hapa - maelezo ya DataStax hayasemi ni maeneo ngapi yaliyotumika kuunda jedwali za HB, ingawa hii ni muhimu kwa idadi kubwa. Kwa hiyo, kwa ajili ya vipimo, wingi = 64 ilichaguliwa, ambayo inaruhusu kuhifadhi hadi 640 GB, i.e. meza ya ukubwa wa kati.
Wakati wa jaribio, HBase ilikuwa na meza elfu 22 na mikoa elfu 67 (hii ingekuwa mbaya kwa toleo la 1.2.0 ikiwa sivyo kwa kiraka kilichotajwa hapo juu).
Sasa kwa kanuni. Kwa kuwa haikuwa wazi ni usanidi gani ulikuwa na faida zaidi kwa hifadhidata fulani, majaribio yalifanywa kwa mchanganyiko tofauti. Wale. katika vipimo vingine, meza 4 zilipakiwa wakati huo huo (nodes zote 4 zilitumiwa kwa uunganisho). Katika majaribio mengine tulifanya kazi na meza 8 tofauti. Katika baadhi ya matukio, ukubwa wa kundi ulikuwa 100, kwa wengine 200 (parameter ya kundi - tazama kanuni hapa chini). Saizi ya data kwa thamani ni baiti 10 au baiti 100 (Ukubwa wa data). Kwa jumla, rekodi milioni 5 ziliandikwa na kusomwa katika kila jedwali kila wakati. Wakati huo huo, nyuzi 5 ziliandikwa/kusomwa kwa kila jedwali (nambari ya nyuzi - thNum), ambayo kila moja ilitumia safu yake ya funguo (hesabu = milioni 1):
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);
}
}
Ipasavyo, utendakazi sawa ulitolewa kwa 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);
}
}
Kwa kuwa katika HB mteja lazima atunze usambazaji sawa wa data, kazi kuu ya kuweka chumvi ilionekana kama hii:
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);
}
Sasa sehemu ya kuvutia zaidi - matokeo:
Kitu kimoja katika fomu ya grafu:
Faida ya HB inashangaza sana kwamba kuna shaka kwamba kuna aina fulani ya kizuizi katika usanidi wa CS. Hata hivyo, Googling na kutafuta vigezo dhahiri zaidi (kama vile concurrent_writes au memtable_heap_space_in_mb) hakujaharakisha mambo. Wakati huo huo, magogo ni safi na usiapa chochote.
Data ilisambazwa sawasawa katika nodi, takwimu kutoka nodi zote zilikuwa takriban sawa.
Hivi ndivyo takwimu za jedwali zinavyoonekana kutoka kwa nodi mojaNafasi muhimu: ks
Kusoma Hesabu: 9383707
Muda wa Kuchelewa Kusoma: 0.04287025042448576 ms
Andika Hesabu: 15462012
Muda wa Kuandika: 0.1350068438699957 ms
Majimaji yanayosubiri: 0
Jedwali: t1
Idadi thabiti: 16
Nafasi iliyotumika (moja kwa moja): 148.59 MiB
Nafasi iliyotumika (jumla): 148.59 MiB
Nafasi inayotumiwa na vijipicha (jumla): baiti 0
Kumbukumbu ya nje ya lundo iliyotumika (jumla): 5.17 MiB
Uwiano wa Mfinyazo wa SSTable: 0.5720989576459437
Idadi ya partitions (makadirio): 3970323
Idadi ya seli inayoweza kukumbukwa: 0
Saizi ya data inayoweza kukumbukwa: baiti 0
Kumbukumbu ya lundo inayoweza kukumbukwa iliyotumika: baiti 0
Idadi ya swichi inayoweza kukumbukwa: 5
Idadi ya waliosoma ndani: 2346045
Muda wa kusubiri wa kusoma ndani: NaN ms
Idadi ya maandishi ya ndani: 3865503
Muda wa kusubiri uandishi wa ndani: NaN ms
Majimaji yanayosubiri: 0
Asilimia iliyorekebishwa: 0.0
Kichujio cha Bloom chanya chanya cha uongo: 25
Uwiano wa uwongo wa kichujio cha Bloom: 0.00000
Nafasi ya kichujio cha Bloom iliyotumika: 4.57 MiB
Bloom chujio mbali na kumbukumbu lundo kutumika: 4.57 MiB
Muhtasari wa faharasa wa kumbukumbu ya lundo iliyotumika: 590.02 KiB
Metadata ya mfinyizo kutoka kwa kumbukumbu ya lundo iliyotumika: 19.45 KiB
Sehemu ya chini ya baiti iliyounganishwa: 36
Sehemu ya juu ya baiti iliyounganishwa: 42
Sehemu iliyounganishwa ya wastani ya baiti: 42
Wastani wa seli hai kwa kila kipande (dakika tano zilizopita): NaN
Idadi ya juu ya seli hai kwa kila kipande (dakika tano zilizopita): 0
Wastani wa mawe ya kaburi kwa kila kipande (dakika tano za mwisho): NaN
Upeo wa mawe ya kaburi kwa kila kipande (dakika tano zilizopita): 0
Mabadiliko yaliyopungua: baiti 0
Jaribio la kupunguza saizi ya kundi (hata kuituma kibinafsi) haikuwa na athari, ilizidi kuwa mbaya zaidi. Inawezekana kwamba kwa kweli huu ndio utendaji wa juu zaidi wa CS, kwani matokeo yaliyopatikana kwa CS ni sawa na yale yaliyopatikana kwa DataStax - karibu mamia ya maelfu ya shughuli kwa sekunde. Kwa kuongezea, ikiwa tutaangalia utumiaji wa rasilimali, tutaona kuwa CS hutumia CPU na diski zaidi:
Takwimu inaonyesha matumizi wakati wa kufanya majaribio yote mfululizo kwa hifadhidata zote mbili.
Kuhusu faida kubwa ya kusoma ya HB. Hapa unaweza kuona kwamba kwa hifadhidata zote mbili, utumiaji wa diski wakati wa kusoma ni mdogo sana (vipimo vya kusoma ni sehemu ya mwisho ya mzunguko wa majaribio kwa kila hifadhidata, kwa mfano kwa CS hii ni kutoka 15:20 hadi 15:40). Katika kesi ya HB, sababu ni wazi - data nyingi hutegemea kumbukumbu, katika memstore, na baadhi ni cached katika blockcache. Kuhusu CS, haijulikani sana jinsi inavyofanya kazi, lakini kuchakata diski pia haionekani, lakini ikiwa tu, jaribio lilifanywa kuwezesha kache row_cache_size_in_mb = 2048 na kuweka caching = {'keys': 'ALL', 'rows_per_partition': '2000000'}, lakini hiyo ilifanya kuwa mbaya zaidi.
Pia inafaa kutaja kwa mara nyingine tena jambo muhimu kuhusu idadi ya mikoa katika HB. Kwa upande wetu, thamani ilielezwa kuwa 64. Ikiwa unapunguza na kuifanya sawa, kwa mfano, 4, basi wakati wa kusoma, kasi hupungua kwa mara 2. Sababu ni kwamba memstore itajaza haraka na faili zitasafishwa mara nyingi zaidi na wakati wa kusoma, faili nyingi zitahitaji kusindika, ambayo ni operesheni ngumu zaidi ya HB. Katika hali halisi, hii inaweza kushughulikiwa kwa kufikiria kupitia mkakati wa kugawanya na kujumuisha; haswa, tunatumia matumizi ya kujiandikia ambayo hukusanya takataka na kubana HFiles nyuma kila wakati. Inawezekana kwamba kwa majaribio ya DataStax walitenga mkoa 1 tu kwa kila jedwali (ambayo sio sahihi) na hii inaweza kufafanua kwa nini HB ilikuwa duni katika majaribio yao ya usomaji.
Hitimisho zifuatazo za awali hutolewa kutoka kwa hili. Kwa kudhani kwamba hakuna makosa makubwa yaliyofanywa wakati wa kupima, basi Cassandra anaonekana kama colossus na miguu ya udongo. Kwa usahihi, wakati anasawazisha mguu mmoja, kama kwenye picha mwanzoni mwa kifungu, anaonyesha matokeo mazuri, lakini katika mapigano chini ya hali hiyo hiyo anapoteza moja kwa moja. Wakati huo huo, kwa kuzingatia matumizi ya chini ya CPU kwenye maunzi yetu, tulijifunza kupanda HB mbili za RegionServer kwa kila mwenyeji na hivyo kuongeza utendaji mara mbili. Wale. Kwa kuzingatia matumizi ya rasilimali, hali ya CS ni mbaya zaidi.
Bila shaka, vipimo hivi ni vya syntetisk kabisa na kiasi cha data kilichotumiwa hapa ni cha kawaida. Inawezekana kwamba ikiwa tutabadilisha terabytes, hali itakuwa tofauti, lakini wakati kwa HB tunaweza kupakia terabytes, kwa CS hii iligeuka kuwa shida. Mara nyingi ilirusha OperationTimedOutException hata kwa juzuu hizi, ingawa vigezo vya kusubiri jibu tayari viliongezwa mara kadhaa ikilinganishwa na zile chaguo-msingi.
Natumai kuwa kupitia juhudi za pamoja tutapata vikwazo vya CS na ikiwa tunaweza kuharakisha, basi mwisho wa chapisho hakika nitaongeza habari juu ya matokeo ya mwisho.
UPD: Shukrani kwa ushauri wa wandugu, nilifanikiwa kuharakisha usomaji. Ilikuwa:
Ops 159 (meza 644, mito 4, kundi 5).
Imeongezwa:
.withLoadBancingPolicy(New TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Na nilicheza karibu na idadi ya nyuzi. Matokeo yake ni yafuatayo:
Jedwali 4, nyuzi 100, bechi = 1 (kipande kwa kipande): ops 301
Jedwali 4, nyuzi 100, bechi = 10: op 447
Jedwali 4, nyuzi 100, bechi = 100: op 625
Baadaye nitatumia vidokezo vingine vya kurekebisha, endesha mzunguko kamili wa majaribio na kuongeza matokeo mwishoni mwa chapisho.
Chanzo: mapenzi.com