Bu hatto hazil ham emas, bu aniq rasm ushbu ma'lumotlar bazalarining mohiyatini eng aniq aks ettirganga o'xshaydi va oxirida nima uchun aniq bo'ladi:
DB-Engines Ranking ma'lumotlariga ko'ra, ikkita eng mashhur NoSQL ustunli ma'lumotlar bazasi Cassandra (keyingi o'rinlarda CS) va HBase (HB).
Taqdirning irodasiga ko'ra, bizning Sberbankdagi ma'lumotlarni yuklashni boshqarish guruhi allaqachon mavjud va HB bilan yaqindan hamkorlik qiladi. Bu vaqt ichida biz uning kuchli va zaif tomonlarini juda yaxshi o'rganib chiqdik va uni qanday pishirishni o'rgandik. Biroq, CS ko'rinishidagi muqobilning mavjudligi bizni har doim shubhalar bilan o'zimizni biroz qiynashga majbur qildi: biz to'g'ri tanlov qildikmi? Bundan tashqari, natijalar , DataStax tomonidan amalga oshirilgan, ular CS deyarli ezilgan ball bilan HBni osongina mag'lub etishini aytishdi. Boshqa tomondan, DataStax manfaatdor tomondir va siz buning uchun ularning so'zlarini qabul qilmasligingiz kerak. Sinov shartlari haqidagi juda oz miqdordagi ma'lumotlar bizni chalkashtirib yubordi, shuning uchun biz BigData NoSql qiroli kimligini o'zimiz aniqlashga qaror qildik va olingan natijalar juda qiziqarli bo'ldi.
Biroq, o'tkazilgan testlar natijalariga o'tishdan oldin, atrof-muhit konfiguratsiyasining muhim jihatlarini tavsiflash kerak. Gap shundaki, CS ma'lumotlarni yo'qotish imkonini beruvchi rejimda ishlatilishi mumkin. Bular. bu ma'lum bir kalitning ma'lumotlari uchun faqat bitta server (tugun) mas'ul bo'lganda va agar biron sababga ko'ra u muvaffaqiyatsiz bo'lsa, bu kalitning qiymati yo'qoladi. Ko'pgina vazifalar uchun bu muhim emas, lekin bank sektori uchun bu qoida emas, balki istisno. Bizning holatda, ishonchli saqlash uchun ma'lumotlarning bir nechta nusxasiga ega bo'lish muhimdir.
Shuning uchun, faqat uch marta takrorlash rejimida CS ish rejimi ko'rib chiqildi, ya'ni. Ishlar maydonini yaratish quyidagi parametrlar bilan amalga oshirildi:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Keyinchalik, kerakli darajadagi mustahkamlikni ta'minlashning ikki yo'li mavjud. Umumiy qoida:
NW + NR > RF
Bu shuni anglatadiki, yozish paytida tugunlardan olingan tasdiqlashlar soni (NW) va o'qish paytida tugunlardan olingan tasdiqlar soni (NR) replikatsiya koeffitsientidan kattaroq bo'lishi kerak. Bizning holatda, RF = 3, ya'ni quyidagi variantlar mos keladi:
2 + 2 > 3
3 + 1 > 3
Biz uchun ma'lumotlarni iloji boricha ishonchli saqlash muhim bo'lganligi sababli, 3+1 sxemasi tanlandi. Bundan tashqari, HB shunga o'xshash printsip asosida ishlaydi, ya'ni. bunday taqqoslash yanada adolatli bo'ladi.
Shuni ta'kidlash kerakki, DataStax o'z tadqiqotida buning aksini qildi, ular CS va HB uchun RF = 1 ni o'rnatdilar (ikkinchisi uchun HDFS sozlamalarini o'zgartirish orqali). Bu haqiqatan ham muhim jihat, chunki bu holda CS ishlashiga ta'siri juda katta. Misol uchun, quyidagi rasmda CS ga ma'lumotlarni yuklash uchun zarur bo'lgan vaqtning ko'payishi ko'rsatilgan:
Bu erda biz quyidagilarni ko'ramiz: ko'proq raqobatdosh mavzular ma'lumotlarni yozsa, shuncha ko'p vaqt talab etadi. Bu tabiiy, lekin RF=3 uchun ishlashning pasayishi sezilarli darajada yuqori bo'lishi muhimdir. Boshqacha qilib aytganda, har biriga 4 ta jadvalga 5 ta ip yozsak (jami 20 ta), u holda RF=3 taxminan 2 marta yo'qotadi (RF=150 uchun 3 soniya, RF=75 uchun 1). Ammo har birida 8 tadan (jami 5 ta) ma'lumotlarni 40 ta jadvalga yuklash orqali yukni oshirsak, RF = 3 ning yo'qolishi allaqachon 2,7 marta (375 ga nisbatan 138 soniya).
Ehtimol, bu qisman CS uchun DataStax tomonidan o'tkazilgan muvaffaqiyatli yuk sinovining siri, chunki bizning stendimizda HB uchun replikatsiya koeffitsientini 2 dan 3 gacha o'zgartirish hech qanday ta'sir ko'rsatmadi. Bular. disklar bizning konfiguratsiyamiz uchun HB muammosi emas. Biroq, bu erda boshqa ko'plab tuzoqlar mavjud, chunki shuni ta'kidlash kerakki, bizning HB versiyamiz biroz yamalgan va o'zgartirilgan, muhitlar butunlay boshqacha va hokazo. Shuni ham ta'kidlash kerakki, men CSni qanday qilib to'g'ri tayyorlashni bilmayman va u bilan ishlashning yanada samarali usullari bor va biz buni sharhlarda bilib olamiz deb umid qilaman. Lekin birinchi narsa birinchi.
Barcha testlar har biri quyidagi konfiguratsiyaga ega bo'lgan 4 ta serverdan iborat apparat klasterida o'tkazildi:
Protsessor: Xeon E5-2680 v4 @ 2.40 gigagertsli 64 ta ip.
Disklar: 12 dona SATA HDD
java versiyasi: 1.8.0_111
CS versiyasi: 3.11.5
cassandra.yml parametrlariBelgilar soni: 256
hinted_handoff_enabled: rost
hinted_handoff_throttle_in_kb: 1024
maksimal_maslahatlar_etkazib berish_mavzulari: 2
hints_directory: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
maksimal_maslahatlar_fayl_hajmi_mb: 128
batchlog_replay_throttle_in_kb: 1024
autentifikator: AllowAllAuthenticator
avtorlovchi: AllowAllAuthorizer
role_manager: CassandraRoleManager
rollarning_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
bo'lim: org.apache.cassandra.dht.Murmur3Partitioner
ma'lumotlar_fayl_kataloglari:
- /data1/cassandra/data # har bir dataN katalogi alohida diskdir
- /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: noto'g'ri
disk_failure_policy: to'xtatish
commit_failure_policy: to'xtating
tayyorlangan_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
qator_kesh_saqlash_muddati: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: davriy
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
urug 'provayderi:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parametrlar:
- urug'lar: "*,*"
concurrent_reads: 256 # urindi 64 - farq sezilmadi
concurrent_writes: 256 # urindi 64 - farq sezilmadi
concurrent_counter_writes: 256 # urindi 64 - farq sezilmadi
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 GB urindi - bu sekinroq edi
memtable_allocation_type: heap_buffers
indeks_summary_capacity_in_mb:
indeks_summary_o'lchamini_daqiqada_interval: 60
trickle_fsync: noto'g'ri
trickle_fsync_interval_in_kb: 10240
saqlash_porti: 7000
ssl_storage_port: 7001
tinglash_manzil: *
efir_manzili: *
eshittirish_on_manzil: rost
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: rost
mahalliy_transport_porti: 9042
start_rpc: rost
rpc_manzil: *
rpc_port: 9160
rpc_keepalive: rost
rpc_server_type: sinxronlash
thrift_framed_transport_size_in_mb: 15
incremental_zaxira: noto'g'ri
siqilishdan_oldin snapshot: false
auto_snapshot: rost
ustun_index_size_kb: 64
ustun_index_kesh_sizi_kb: 2
concurrent_compactors: 4
siqishni_o'tkazish_sekundiga_mb_: 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_contential_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: noto'g'ri
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_yomonlik chegarasi: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: yo'q
client_encryption_options:
yoqilgan: noto'g'ri
internode_siqish: DC
inter_dc_tcp_nodelay: noto'g'ri
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: noto'g'ri
enable_scripted_user_defined_functions: false
windows_taymer_interval: 1
transparent_data_encryption_options:
yoqilgan: noto'g'ri
qabr toshini_ogohlantirish ostonasi: 1000
qabr toshining_muvaffaqiyatsizlik_ostonasi: 100000
paket_hajmi_ogohlantirish_bo'sag'asi_kb: 200
paket_hajmi_muvaffaqiyatsiz_eshigi_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
zichlash_katta_bo'lim_ogohlantirish_eshigi_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: noto'g'ri
enable_materialized_views: rost
enable_sasi_indexes: rost
GC sozlamalari:
### CMS sozlamalari-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX: Omon qolish nisbati = 8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+FaqatCMSInitiatingOccupancyUse
-XX: CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
Jvm.options xotirasi 16 Gb ajratildi (biz 32 Gb ni ham sinab ko'rdim, hech qanday farq sezilmadi).
Jadvallar quyidagi buyruq bilan yaratilgan:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB versiyasi: 1.2.0-cdh5.14.2 (org.apache.hadoop.hbase.regionserver.HRegion sinfida biz RegionServerda hududlar soni 1000 dan ortiq bo'lganida GCga olib keladigan MetricsRegionni chiqarib tashladik)
Standart bo'lmagan HBase parametrlarizookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 daqiqa
hbase.client.scanner.timeout.period: 2 daqiqa(lar)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 daqiqa(lar)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 soat(lar)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplikator: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 kun(lar)
hbase-site.xml uchun HBase Service Advanced Configuration Snippet (Xavfsizlik valfi):
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
HBase RegionServer uchun Java konfiguratsiya parametrlari:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 daqiqa
hbase.snapshot.region.timeout: 2 daqiqa(lar)
hbase.snapshot.master.timeout.millis: 2 daqiqa(lar)
HBase REST Server jurnalining maksimal hajmi: 100 Mb
HBase REST Server jurnalining maksimal zaxira nusxalari: 5
HBase Thrift Server maksimal jurnal hajmi: 100 MiB
HBase Thrift Server jurnalining maksimal zaxira nusxalari: 5
Asosiy jurnalning maksimal hajmi: 100 Mb
Jurnal faylining maksimal zaxira nusxalari: 5
RegionServer jurnalining maksimal hajmi: 100 Mb
RegionServer jurnalining maksimal zaxira nusxalari: 5
HBase Active Master aniqlash oynasi: 4 daqiqa
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 millisekund(lar)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Jarayon faylining maksimal identifikatorlari: 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.kichik: 6
hbase.ipc.server.read.threadpool.size: 20
Mintaqaviy ko'chiruvchi mavzular: 6
Mijoz Java uyasi hajmi baytlarda: 1 GiB
HBase REST Server standart guruhi: 3 GiB
HBase Thrift Server standart guruhi: 3 GiB
HBase Master-ning baytdagi Java toΚ»plami hajmi: 16 GiB
HBase RegionServer ning baytdagi Java toΚ»plami hajmi: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Jadvallarni yaratish:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
o'zgartirish 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Bu erda bitta muhim nuqta bor - DataStax tavsifida HB jadvallarini yaratish uchun qancha mintaqa ishlatilganligi aytilmagan, ammo bu katta hajmlar uchun juda muhimdir. Shuning uchun, testlar uchun miqdor = 64 tanlandi, bu 640 Gb gacha saqlash imkonini beradi, ya'ni. o'rta o'lchamdagi stol.
Sinov paytida HBase 22 ming jadval va 67 ming mintaqaga ega edi (yuqorida aytib o'tilgan yamoq bo'lmasa, bu 1.2.0 versiyasi uchun halokatli bo'lar edi).
Endi kod uchun. Muayyan ma'lumotlar bazasi uchun qaysi konfiguratsiyalar foydaliroq ekanligi aniq bo'lmaganligi sababli, testlar turli kombinatsiyalarda o'tkazildi. Bular. ba'zi testlarda bir vaqtning o'zida 4 ta jadval yuklangan (barcha 4 ta tugun ulanish uchun ishlatilgan). Boshqa testlarda biz 8 xil jadval bilan ishladik. Ba'zi hollarda partiya hajmi 100, boshqalarda 200 (paket parametri - quyidagi kodga qarang). Qiymat uchun ma'lumotlar hajmi 10 bayt yoki 100 bayt (dataSize). Hammasi bo'lib, har bir jadvalga 5 million yozuv yozilgan va o'qilgan. Shu bilan birga, har bir jadvalga 5 ta mavzu yozildi/o'qildi (mavzu raqami - thNum), ularning har biri o'z kalitlari diapazonidan foydalangan (hisob = 1 million):
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);
}
}
Shunga ko'ra, HB uchun shunga o'xshash funksiya taqdim etilgan:
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);
}
}
HB-da mijoz ma'lumotlarning bir xil taqsimlanishiga g'amxo'rlik qilishi kerakligi sababli, asosiy tuzlash funktsiyasi quyidagicha ko'rinishga ega edi:
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);
}
Endi eng qiziqarli qism - natijalar:
Grafik shaklida bir xil narsa:
HB ning afzalligi shunchalik hayratlanarliki, CS o'rnatishda qandaydir to'siq bor degan shubha bor. Biroq, Googling va eng aniq parametrlarni qidirish (masalan, concurrent_writes yoki memtable_heap_space_in_mb) ishlarni tezlashtirmadi. Shu bilan birga, jurnallar toza va hech narsaga qasam ichmaydi.
Ma'lumotlar tugunlar bo'ylab teng ravishda taqsimlandi, barcha tugunlarning statistikasi taxminan bir xil edi.
Jadval statistikasi tugunlardan birida shunday ko'rinadiKlaviatura maydoni: ks
O'qishlar soni: 9383707
O'qish kechikishi: 0.04287025042448576 ms
Yozish soni: 15462012
Yozish kechikishi: 0.1350068438699957 ms
Kutilayotgan yuvishlar: 0
Jadval: t1
SSTable soni: 16
Ishlatilgan maydon (jonli): 148.59 MiB
Ishlatilgan maydon (jami): 148.59 Mb
Snapshotlar tomonidan ishlatiladigan boΚ»sh joy (jami): 0 bayt
Ishlatilgan yig'ma xotira (jami): 5.17 Mb
SSTable siqish nisbati: 0.5720989576459437
Bo'limlar soni (taxminan): 3970323
Memtable hujayralar soni: 0
Memtable ma'lumotlar hajmi: 0 bayt
Ishlatilgan xotira o'chirilgan yig'ma xotira: 0 bayt
Memtable kalitlari soni: 5
Mahalliy o'qishlar soni: 2346045
Mahalliy o'qish kechikishi: NaN milodiy
Mahalliy yozishlar soni: 3865503
Mahalliy yozish kechikishi: NaN milodiy
Kutilayotgan yuvishlar: 0
Ta'mirlangan foiz: 0.0
Bloom filtri noto'g'ri ijobiy: 25
Bloom filtrining noto'g'ri nisbati: 0.00000
Bloom filtri maydoni: 4.57 MiB
Bloom filtridan foydalanilgan yig'ma xotira: 4.57 Mb
Ishlatilgan yig'ma xotira indeksi sarhisobi: 590.02 KiB
Ishlatilgan yig'ma xotiradan siqish metama'lumotlari: 19.45 KiB
Siqilgan qismning minimal baytlari: 36
Siqilgan bo'limning maksimal baytlari: 42
Siqilgan bo'limning o'rtacha baytlari: 42
Dilimdagi o'rtacha jonli hujayralar (oxirgi besh daqiqa): NaN
Dilim uchun maksimal tirik hujayralar (oxirgi besh daqiqa): 0
Bir tilim uchun o'rtacha qabr toshlari (oxirgi besh daqiqa): NaN
Bir tilim uchun maksimal qabr toshlari (oxirgi besh daqiqa): 0
Tushilgan mutatsiyalar: 0 bayt
Partiya hajmini kamaytirishga urinish (hatto uni alohida-alohida yuborish) hech qanday ta'sir ko'rsatmadi, u faqat yomonlashdi. Ehtimol, bu haqiqatan ham CS uchun maksimal ko'rsatkichdir, chunki CS uchun olingan natijalar DataStax uchun olingan natijalarga o'xshash - soniyada yuz minglab operatsiyalar. Bundan tashqari, agar resurslardan foydalanishni ko'rib chiqsak, CS ko'proq CPU va disklardan foydalanishini ko'ramiz:
Rasmda ikkala ma'lumotlar bazasi uchun ketma-ket barcha testlarni bajarish paytida foydalanish ko'rsatilgan.
HB ning kuchli o'qish afzalligi haqida. Bu erda siz ikkala ma'lumotlar bazasi uchun o'qish paytida diskdan foydalanish juda past ekanligini ko'rishingiz mumkin (o'qish testlari har bir ma'lumotlar bazasi uchun sinov davrining yakuniy qismidir, masalan, CS uchun bu 15:20 dan 15:40 gacha). HB holatida sabab aniq - ma'lumotlarning aksariyati xotirada, memstoreda, ba'zilari esa blokkeshda keshlangan. CS ga kelsak, uning qanday ishlashi unchalik aniq emas, lekin diskni qayta ishlash ham ko'rinmaydi, lekin har holda, kesh row_cache_size_in_mb = 2048ni yoqish va keshlash = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, lekin bu vaziyatni biroz yomonlashtirdi.
Shuningdek, HBdagi hududlar soni haqida yana bir muhim narsani eslatib o'tish kerak. Bizning holatda, qiymat 64 sifatida ko'rsatilgan edi. Agar siz uni kamaytirsangiz va uni, masalan, 4 ga tenglashtirsangiz, o'qish paytida tezlik 2 barobar kamayadi. Sababi, memstore tezroq to'ldiriladi va fayllar tez-tez tozalanadi va o'qish paytida ko'proq fayllarni qayta ishlash kerak bo'ladi, bu HB uchun ancha murakkab operatsiya. Haqiqiy sharoitda buni oldindan ajratish va ixchamlashtirish strategiyasi orqali o'ylash orqali hal qilish mumkin; xususan, biz axlatni to'playdigan va HFile'larni doimo fonda siqib chiqaradigan o'z-o'zidan yozilgan yordamchi dasturdan foydalanamiz. DataStax testlari uchun ular har bir jadval uchun atigi 1 mintaqani ajratgan bo'lishi mumkin (bu to'g'ri emas) va bu HB o'qish testlarida nima uchun shunchalik past ekanligini aniqlab beradi.
Bundan quyidagi dastlabki xulosalar chiqariladi. Sinov paytida hech qanday katta xatolarga yo'l qo'yilmagan deb hisoblasak, Kassandra loydan oyoqlari bo'lgan kolossusga o'xshaydi. Aniqrog'i, maqola boshidagi rasmda bo'lgani kabi bir oyog'ida muvozanatni ushlab turganda, u nisbatan yaxshi natijalarni ko'rsatmoqda, lekin bir xil sharoitdagi jangda u to'g'ridan-to'g'ri mag'lub bo'ladi. Shu bilan birga, uskunamizda protsessordan past foydalanishni hisobga olgan holda, biz har bir xost uchun ikkita RegionServer HB-ni o'rnatishni o'rgandik va shu bilan ishlashni ikki baravar oshirdik. Bular. Resurslardan foydalanishni hisobga oladigan bo'lsak, CS uchun vaziyat yanada achinarli.
Albatta, bu testlar juda sintetik va bu erda ishlatilgan ma'lumotlar miqdori nisbatan kam. Agar biz terabaytlarga o'tsak, vaziyat boshqacha bo'lishi mumkin, ammo HB uchun biz terabaytlarni yuklashimiz mumkin bo'lsa, CS uchun bu muammoli bo'lib chiqdi. U tez-tez OperationTimedOutException-ni hatto ushbu hajmlarda ham tashladi, garchi javobni kutish parametrlari standart bo'lganlarga nisbatan bir necha baravar oshirilgan.
Umid qilamanki, birgalikdagi sa'y-harakatlar orqali biz CS ning qiyinchiliklarini topamiz va agar biz uni tezlashtira olsak, post oxirida men yakuniy natijalar haqida ma'lumot qo'shaman.
UPD: O'rtoqlar maslahati tufayli men o'qishni tezlashtirishga muvaffaq bo'ldim. edi:
159 644 ta operatsiya (4 ta jadval, 5 ta oqim, 100 ta partiya).
Qo'shilgan:
.withLoadBalancingPolicy(yangi TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Va men iplar soni bilan o'ynadim. Natija quyidagicha:
4 ta jadval, 100 ta ip, partiya = 1 (qismiga): 301 ta
4 ta jadval, 100 ta mavzu, to'plam = 10: 447 608 operatsiya
4 ta jadval, 100 ta mavzu, to'plam = 100: 625 655 operatsiya
Keyinchalik men sozlash bo'yicha boshqa maslahatlarni qo'llayman, to'liq sinov tsiklini o'tkazaman va natijalarni post oxirida qo'shaman.
Manba: www.habr.com