Bu, hətta zarafat deyil, belə görünür ki, bu xüsusi şəkil bu verilənlər bazalarının mahiyyətini ən dəqiq şəkildə əks etdirir və sonda niyə aydın olacaq:
DB-Engines Ranking-ə görə, ən populyar NoSQL sütunlu verilənlər bazası Cassandra (bundan sonra CS) və HBasedir (HB).
Taleyin iradəsi ilə, Sberbank-da məlumat yükləmə idarəetmə komandamız artıq var və HB ilə sıx əməkdaşlıq edir. Bu müddət ərzində biz onun güclü və zəif tərəflərini kifayət qədər yaxşı öyrəndik və bişirməyi öyrəndik. Bununla belə, CS şəklində alternativin olması bizi həmişə şübhələrlə özümüzə bir az əzab verməyə məcbur edirdi: düzgün seçim etdikmi? Üstəlik, nəticələr , DataStax tərəfindən ifa olunduqda, CS-nin HB-ni demək olar ki, sarsıdıcı hesabla asanlıqla məğlub etdiyini söylədilər. Digər tərəfdən, DataStax maraqlı tərəfdir və siz bunun üçün onların sözünü qəbul etməməlisiniz. Test şərtləri ilə bağlı kifayət qədər az miqdarda məlumat bizi də çaşdırdı, ona görə də BigData NoSql kralının kim olduğunu özümüz öyrənməyə qərar verdik və əldə edilən nəticələr çox maraqlı oldu.
Bununla belə, həyata keçirilən sınaqların nəticələrinə keçməzdən əvvəl ətraf mühitin konfiqurasiyasının əhəmiyyətli aspektlərini təsvir etmək lazımdır. Fakt budur ki, CS məlumatların itirilməsinə imkan verən rejimdə istifadə edilə bilər. Bunlar. bu, yalnız bir server (qovşaq) müəyyən bir açarın məlumatlarına cavabdeh olduqda və nədənsə uğursuz olarsa, bu açarın dəyəri itiriləcəkdir. Bir çox vəzifələr üçün bu kritik deyil, lakin bank sektoru üçün bu qaydadan daha çox istisnadır. Bizim vəziyyətimizdə etibarlı saxlama üçün məlumatların bir neçə nüsxəsinin olması vacibdir.
Buna görə də, üçlü təkrarlama rejimində yalnız CS iş rejimi nəzərə alındı, yəni. Kassa sahəsinin yaradılması aşağıdakı parametrlərlə həyata keçirildi:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Sonra, lazımi ardıcıllıq səviyyəsini təmin etməyin iki yolu var. Ümumi qayda:
NW + NR > RF
Bu o deməkdir ki, yazarkən qovşaqlardan gələn təsdiqlərin sayı (NW) üstəgəl oxuyarkən qovşaqlardan gələn təsdiqlərin sayı (NR) təkrarlama faktorundan çox olmalıdır. Bizim vəziyyətimizdə RF = 3, yəni aşağıdakı seçimlər uyğundur:
2 + 2 > 3
3 + 1 > 3
Məlumatları mümkün qədər etibarlı şəkildə saxlamaq bizim üçün prinsipial vacib olduğundan, 3+1 sxemi seçildi. Bundan əlavə, HB oxşar prinsiplə işləyir, yəni. belə bir müqayisə daha ədalətli olar.
Qeyd etmək lazımdır ki, DataStax öz tədqiqatlarında bunun əksini etdi, həm CS, həm də HB üçün RF = 1 təyin etdilər (sonuncu üçün HDFS parametrlərini dəyişdirərək). Bu, həqiqətən vacib bir cəhətdir, çünki bu halda CS performansına təsir böyükdür. Məsələn, aşağıdakı şəkil məlumatların CS-yə yüklənməsi üçün tələb olunan vaxtın artımını göstərir:
Burada biz aşağıdakıları görürük: daha çox rəqabət aparan mövzular məlumatları yazır, bir o qədər uzun çəkir. Bu təbiidir, lakin RF=3 üçün performansın azalmasının əhəmiyyətli dərəcədə yüksək olması vacibdir. Başqa sözlə desək, hərəsinə 4 cədvələ 5 mövzu yazsaq (cəmi 20), onda RF=3 təxminən 2 dəfə itirir (RF=150 üçün 3 saniyə, RF=75 üçün 1). Ancaq məlumatları hər biri 8 ipdən ibarət 5 cədvələ yükləməklə yükü artırsaq (cəmi 40), onda RF=3 itkisi artıq 2,7 dəfədir (375-ə qarşı 138 saniyə).
Bəlkə də bu qismən DataStax for CS tərəfindən həyata keçirilən uğurlu yük testinin sirridir, çünki bizim stendimizdə HB üçün replikasiya əmsalının 2-dən 3-ə dəyişdirilməsi heç bir effekt vermədi. Bunlar. disklər bizim konfiqurasiyamız üçün HB darboğazı deyil. Bununla belə, burada bir çox başqa tələlər var, çünki qeyd etmək lazımdır ki, HB versiyamız bir az yamaqlanmış və düzəldilmişdir, mühitlər tamamilə fərqlidir və s. Onu da qeyd etmək lazımdır ki, bəlkə mən CS-ni necə düzgün hazırlayacağımı bilmirəm və onunla işləməyin daha təsirli yolları var və ümid edirəm ki, şərhlərdə bunu öyrənəcəyik. Ancaq ilk şeylər.
Bütün testlər hər biri aşağıdakı konfiqurasiyaya malik 4 serverdən ibarət olan aparat klasterində aparılmışdır:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ip.
Disklər: 12 ədəd SATA HDD
java versiyası: 1.8.0_111
CS Versiyası: 3.11.5
cassandra.yml parametrləriişarələrin_sayı: 256
hinted_handoff_enabled: doğrudur
hinted_handoff_throttle_in_kb: 1024
maksimum_göstərişlərin_çatdırılması_mövzuları: 2
hints_directory: /data10/cassandra/hints
göstərişlər_təmizləmə_dövrü ms-də: 10000
maksimum_göstəricilər_fayl_ölçüsü_mb: 128
batchlog_replay_throttle_in_kb: 1024
autentifikator: AllowAllAuthenticator
avtorizasiya: AllowAllAuthorizer
role_manager: CassandraRoleManager
ms-də rolların etibarlılığı: 2000
permissions_validity_ms-də: 2000
etimadnamələr_validity_ms-də: 2000
bölmə: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # hər dataN kataloqu ayrıca 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: false
disk_failure_policy: dayandırın
commit_failure_policy: dayandırmaq
hazırlanmış_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
sətir_keş_ölçüsü_mb: 0
sətir_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: dövri
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
toxum_provayderi:
- sinif_adı: org.apache.cassandra.locator.SimpleSeedProvider
parametrləri:
- toxum: "*,*"
concurrent_reads: 256 # cəhd 64 - fərq hiss olunmadı
concurrent_writes: 256 # cəhd 64 - fərq hiss olunmadı
concurrent_counter_writes: 256 # cəhd 64 - fərq hiss olunmadı
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 GB cəhd etdi - daha yavaş oldu
memtable_allocation_type: heap_buferlər
index_summary_tutum_in_mb:
indeks_xülasə_ölçüsünü_dəqiqədə_interval: 60
trickle_fsync: yanlış
trickle_fsync_interval_in_kb: 10240
saxlama_portu: 7000
ssl_storage_port: 7001
dinləmək_ünvanı: *
yayım_ünvanı: *
yayımda_dinləmək_ünvanı: doğrudur
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
başlanğıc_doğma_nəqliyyat: doğrudur
yerli_nəqliyyat_portu: 9042
start_rpc: doğrudur
rpc_ünvanı: *
rpc_port: 9160
rpc_keepalive: doğrudur
rpc_server_type: sinxronizasiya
qənaətli_çərçivəli_nəqliyyat_ölçüsü_mb: 15
artan_yedekler: false
sıxılmadan_əvvəlki snapshot: false
auto_snapshot: doğrudur
sütun_index_ölçüsü_kb: 64
sütun_index_cache_size_kb: 2
concurrent_compactors: 4
sıxılma_məhsuldarlığı_mb_saniyədə: 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_conttention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
sorğu_zaman aşımı_dəyə: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: false
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dinamik_snitch_pislik həddini: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: heç biri
müştəri_şifrələmə_seçimləri:
aktiv: yalan
internode_sıxılma: dc
inter_dc_tcp_nodelay: yanlış
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_funksiyalar: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
şəffaf_məlumat_şifrləmə_seçimləri:
aktiv: yalan
məzar daşı_xəbərdarlığı_ərəfəsi: 1000
məzardaşı_uğursuzluğu_ərəfəsi: 100000
toplu_ölçüsü_xəbərdarlıq_ərəfəsində_kb: 200
toplu_ölçüsü_uğursuz_ərəfəsində_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
sıxılma_böyük_bölmə_xəbərdarlığı_ərəfəsi_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: yanlış
enable_materialized_views: doğrudur
enable_sasi_indexes: doğrudur
GC Parametrləri:
### CMS Parametrləri-XX:+UseParNewGC
-XX:+ConcMarkSweepGC istifadə edin
-XX:+CMSParallelRemarkEnabled
-XX: Survivor Ratio = 8
-XX:MaxTenuring Threshold=1
-XX:CMSinitiatingOccupancyFraction=75
-XX:+YalnızCMSİnitiatingOccupancyUse
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
16Gb jvm.options yaddaş ayrıldı (32 Gb da cəhd etdik, heç bir fərq hiss olunmadı).
Cədvəllər aşağıdakı əmrlə yaradılmışdır:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB versiyası: 1.2.0-cdh5.14.2 (org.apache.hadoop.hbase.regionserver.HRegion sinfində RegionServer-də regionların sayı 1000-dən çox olduqda GC-yə səbəb olan MetricsRegion-u istisna etdik)
Qeyri-standart HBase parametrlərizookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 dəqiqə
hbase.client.scanner.timeout.period: 2 dəqiqə(s)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 dəqiqə(s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.müddət: 4 saat
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplikator: 6
hbase.hstore.compaction Həddi: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 gün
hbase-site.xml üçün HBase Service Qabaqcıl Konfiqurasiya Parçası (Təhlükəsizlik Valfi):
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.lage12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase RegionServer üçün Java Konfiqurasiya Seçimləri:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIinitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 dəqiqə
hbase.snapshot.region.timeout: 2 dəqiqə
hbase.snapshot.master.timeout.millis: 2 dəqiqə
HBase REST Server Max Log Ölçüsü: 100 MiB
HBase REST Server Maksimum Giriş Faylı Yedəkləmələri: 5
HBase Thrift Server Max Log Ölçüsü: 100 MiB
HBase Thrift Server Maksimum Giriş Faylı Yedəkləmələri: 5
Master Max Log Ölçüsü: 100 MiB
Master Maksimum Giriş Faylı Yedəkləmələri: 5
RegionServer Max Log Ölçüsü: 100 MiB
RegionServer Maksimum Giriş Faylı Yedəkləmələri: 5
HBase Active Master aşkarlama pəncərəsi: 4 dəqiqə
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 millisaniyə(lər)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maksimum Proses Fayl Deskriptorları: 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.kiçik: 6
hbase.ipc.server.read.threadpool.size: 20
Region Mover Threads: 6
Baytlarda Müştəri Java Yığın Ölçüsü: 1 GiB
HBase REST Server Defolt Qrupu: 3 GiB
HBase Thrift Server Defolt Qrupu: 3 GiB
HBase Master-ın Java Heap Ölçüsü Baytlarda: 16 GiB
HBase RegionServer-in Java Heap Ölçüsü Baytlarda: 32 GiB
+ ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Cədvəllərin yaradılması:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
dəyişdirin 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRSION => 'GZ'}
Burada bir vacib məqam var - DataStax təsvirində HB cədvəllərini yaratmaq üçün neçə bölgədən istifadə edildiyi göstərilmir, baxmayaraq ki, bu, böyük həcmlər üçün vacibdir. Buna görə də, testlər üçün 64 GB-a qədər saxlamağa imkan verən miqdar = 640 seçildi, yəni. orta ölçülü masa.
Test zamanı HBase-də 22 min cədvəl və 67 min bölgə var idi (yuxarıda qeyd olunan yamaq olmasaydı, bu, 1.2.0 versiyası üçün ölümcül olardı).
İndi kod üçün. Müəyyən bir verilənlər bazası üçün hansı konfiqurasiyaların daha sərfəli olduğu aydın olmadığı üçün müxtəlif kombinasiyalarda sınaqlar aparılmışdır. Bunlar. bəzi testlərdə eyni vaxtda 4 cədvəl yüklənmişdir (bütün 4 qovşaq qoşulma üçün istifadə edilmişdir). Digər testlərdə 8 fərqli cədvəllə işlədik. Bəzi hallarda partiyanın ölçüsü 100, digərlərində 200 idi (paket parametri - aşağıdakı koda baxın). Dəyər üçün məlumat ölçüsü 10 bayt və ya 100 baytdır (dataSize). Ümumilikdə, hər cədvələ hər dəfə 5 milyon qeyd yazılmış və oxunmuşdur. Eyni zamanda, hər bir cədvələ 5 mövzu yazıldı/oxundu (mövzunun nömrəsi - thNum), hər biri öz açar diapazonundan istifadə etdi (say = 1 milyon):
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);
}
}
Müvafiq olaraq, HB üçün oxşar funksionallıq təmin edilmişdir:
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-də müştəri məlumatların vahid paylanmasına diqqət yetirməli olduğundan, əsas duzlama funksiyası belə görünürdü:
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);
}
İndi ən maraqlı hissə - nəticələr:
Qrafik şəklində eyni şey:
HB-nin üstünlüyü o qədər təəccüblüdür ki, CS quraşdırmasında bir növ darboğaz olduğuna dair bir şübhə var. Bununla belə, Googling və ən bariz parametrləri axtarmaq (məsələn, concurrent_writes və ya memtable_heap_space_in_mb) işləri sürətləndirmədi. Eyni zamanda, loglar təmizdir və heç bir şeyə and içmir.
Məlumatlar qovşaqlar arasında bərabər paylandı, bütün qovşaqların statistikası təxminən eyni idi.
Cədvəl statistikası qovşaqlardan birindən belə görünürAçar boşluğu: ks
Oxunma sayı: 9383707
Oxuma gecikməsi: 0.04287025042448576 ms
Yazı sayı: 15462012
Yazma gecikməsi: 0.1350068438699957 ms
Gözləyən Flushlar: 0
Cədvəl: t1
SSTable sayı: 16
İstifadə olunan məkan (canlı): 148.59 MiB
İstifadə olunan yer (ümumi): 148.59 MiB
Snapshotların istifadə etdiyi boşluq (cəmi): 0 bayt
İstifadə olunmuş yaddaşdan kənar yaddaş (ümumi): 5.17 MB
SSTable sıxılma nisbəti: 0.5720989576459437
Bölmələrin sayı (təxmini): 3970323
Memtable hüceyrə sayı: 0
Memtable məlumat ölçüsü: 0 bayt
İstifadə olunan yaddaşdan kənar yığın yaddaşı: 0 bayt
Memtable açarlarının sayı: 5
Yerli oxunma sayı: 2346045
Yerli oxuma gecikməsi: NaN ms
Yerli yazıların sayı: 3865503
Yerli yazma gecikməsi: NaN ms
Gözləyən silmələr: 0
Təmir faizi: 0.0
Bloom filtri yanlış pozitivlər: 25
Bloom filtrinin yanlış nisbəti: 0.00000
İstifadə olunan Bloom filtr sahəsi: 4.57 MiB
İstifadə olunan yığın yaddaşdan Bloom filtri: 4.57 MiB
İstifadə olunan yığın yaddaş indeksinin xülasəsi: 590.02 KiB
İstifadə olunan yığın yaddaşdan sıxılma metadatası: 19.45 KiB
Sıxlaşdırılmış bölmənin minimum baytı: 36
Sıxılmış bölmənin maksimum baytı: 42
Sıxılmış bölmənin orta baytı: 42
Dilim başına orta canlı hüceyrələr (son beş dəqiqə): NaN
Dilim başına maksimum canlı hüceyrələr (son beş dəqiqə): 0
Dilim başına orta qəbir daşları (son beş dəqiqə): NaN
Dilim başına maksimum məzar daşları (son beş dəqiqə): 0
Düşmüş mutasiyalar: 0 bayt
Dəstənin ölçüsünü azaltmaq cəhdi (hətta fərdi olaraq göndərilsə də) heç bir təsir göstərmədi, daha da pisləşdi. Mümkündür ki, bu, həqiqətən də CS üçün maksimum performansdır, çünki CS üçün əldə edilən nəticələr DataStax üçün alınan nəticələrə bənzəyir - saniyədə yüz minlərlə əməliyyat. Bundan əlavə, resurs istifadəsinə baxsaq, görərik ki, CS daha çox CPU və diskdən istifadə edir:
Şəkil hər iki verilənlər bazası üçün ardıcıl olaraq bütün testlərin icrası zamanı istifadəni göstərir.
HB-nin güclü oxu üstünlüyü ilə bağlı. Burada hər iki verilənlər bazası üçün oxu zamanı diskdən istifadənin son dərəcə aşağı olduğunu görə bilərsiniz (oxu testləri hər bir verilənlər bazası üçün sınaq dövrünün son hissəsidir, məsələn, CS üçün bu 15:20-dən 15:40-a qədərdir). HB vəziyyətində səbəb aydındır - məlumatların əksəriyyəti yaddaşda, yaddaş mağazasında, bəziləri isə blokkeşdə saxlanılır. CS-ə gəldikdə, bunun necə işlədiyi çox aydın deyil, lakin diskin təkrar emalı da görünmür, lakin hər halda, keş row_cache_size_in_mb = 2048-i işə salmağa cəhd edildi və keşləmə = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, lakin bu, vəziyyəti bir az da pisləşdirdi.
HB-də regionların sayı ilə bağlı vacib bir məqamı da bir daha qeyd etmək yerinə düşər. Bizim vəziyyətimizdə dəyər 64 olaraq göstərildi. Əgər onu azaldıb, məsələn, 4-ə bərabər etsəniz, oxuyarkən sürət 2 dəfə azalır. Səbəb odur ki, memstore daha tez doldurulacaq və fayllar daha tez-tez yuyulacaq və oxuyarkən daha çox fayl işlənməli olacaq ki, bu da HB üçün kifayət qədər mürəkkəb əməliyyatdır. Real şəraitdə bunu əvvəlcədən bölmə və yığcamlaşdırma strategiyası vasitəsilə düşünməklə həll etmək olar; xüsusən, biz zibil toplayan və HFiles-ı daim arxa planda sıxan öz-özünə yazılmış yardım proqramından istifadə edirik. Tamamilə mümkündür ki, DataStax testləri üçün hər cədvələ yalnız 1 bölgə ayırdılar (bu düzgün deyil) və bu, HB-nin oxu testlərində niyə bu qədər aşağı olduğunu bir qədər aydınlaşdıracaq.
Bundan aşağıdakı ilkin nəticələr çıxarılır. Sınaq zamanı heç bir böyük səhvə yol verilmədiyini fərz etsək, Kassandra ayaqları gildən olan bir kolossa bənzəyir. Daha doğrusu, məqalənin əvvəlindəki şəkildə olduğu kimi, bir ayağı üzərində tarazlıq saxlayarkən, nisbətən yaxşı nəticələr göstərir, lakin eyni şəraitdə döyüşdə açıq şəkildə uduzur. Eyni zamanda, aparatımızda CPU istifadəsinin aşağı olduğunu nəzərə alaraq, hər bir hosta iki RegionServer HB əkməyi öyrəndik və bununla da performansı ikiqat artırdıq. Bunlar. Resurslardan istifadəni nəzərə alsaq, CS üçün vəziyyət daha acınacaqlıdır.
Əlbəttə ki, bu testlər olduqca sintetikdir və burada istifadə olunan məlumatların miqdarı nisbətən təvazökardır. Mümkündür ki, biz terabaytlara keçsək, vəziyyət fərqli olardı, lakin HB üçün terabaytları yükləyə bildiyimiz halda, CS üçün bu problemli oldu. Tez-tez bu həcmlərlə belə bir OperationTimedOutException atdı, baxmayaraq ki, cavab gözləmə parametrləri standart olanlarla müqayisədə artıq bir neçə dəfə artırıldı.
Ümid edirəm ki, birgə səylərlə biz CS-nin darboğazlarını tapacağıq və onu sürətləndirə bilsək, yazının sonunda mütləq yekun nəticələr haqqında məlumat əlavə edəcəyəm.
UPD: Yoldaşların məsləhəti sayəsində oxumağı sürətləndirə bildim. idi:
159 əməliyyat (644 cədvəl, 4 axın, toplu 5).
Əlavə:
.withLoadBalancingPolicy(yeni TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Və iplərin sayı ilə oynadım. Nəticə belədir:
4 masa, 100 ip, partiya = 1 (parça-parça): 301 əməliyyat
4 cədvəl, 100 mövzu, toplu = 10: 447 əməliyyat
4 cədvəl, 100 mövzu, toplu = 100: 625 əməliyyat
Daha sonra digər tənzimləmə məsləhətlərini tətbiq edəcəyəm, tam sınaq dövrü keçirəcəyəm və nəticələri yazının sonunda əlavə edəcəyəm.
Mənbə: www.habr.com