Ini bukan jenaka, nampaknya gambar khusus ini paling tepat mencerminkan intipati pangkalan data ini, dan pada akhirnya akan menjadi jelas mengapa:
Menurut DB-Engines Ranking, dua pangkalan data kolumnar NoSQL yang paling popular ialah Cassandra (selepas ini CS) dan HBase (HB).
Dengan kehendak takdir, pasukan pengurusan pemuatan data kami di Sberbank telah pun dan bekerja rapat dengan HB. Pada masa ini, kami mengkaji kekuatan dan kelemahannya dengan baik dan belajar cara memasaknya. Walau bagaimanapun, kehadiran alternatif dalam bentuk CS sentiasa memaksa kami untuk menyeksa diri kami sedikit dengan keraguan: adakah kami membuat pilihan yang tepat? Lebih-lebih lagi, hasilnya , yang dilakukan oleh DataStax, mereka mengatakan bahawa CS mudah mengalahkan HB dengan skor yang hampir menghancurkan. Sebaliknya, DataStax ialah pihak yang berminat, dan anda tidak sepatutnya mengambil kata-kata mereka untuk itu. Kami juga keliru dengan jumlah maklumat yang agak kecil tentang keadaan ujian, jadi kami memutuskan untuk mengetahui sendiri siapa raja BigData NoSql, dan keputusan yang diperoleh ternyata sangat menarik.
Walau bagaimanapun, sebelum beralih kepada keputusan ujian yang dijalankan, adalah perlu untuk menerangkan aspek penting konfigurasi persekitaran. Hakikatnya ialah CS boleh digunakan dalam mod yang membolehkan kehilangan data. Itu. ini apabila hanya satu pelayan (nod) bertanggungjawab untuk data kunci tertentu, dan jika atas sebab tertentu ia gagal, maka nilai kunci ini akan hilang. Untuk banyak tugas ini tidak kritikal, tetapi untuk sektor perbankan ini adalah pengecualian dan bukannya peraturan. Dalam kes kami, adalah penting untuk mempunyai beberapa salinan data untuk storan yang boleh dipercayai.
Oleh itu, hanya mod pengendalian CS dalam mod replikasi tiga kali ganda dipertimbangkan, i.e. Penciptaan ruang kes telah dijalankan dengan parameter berikut:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Seterusnya, terdapat dua cara untuk memastikan tahap konsistensi yang diperlukan. Peraturan Am:
NW + NR > RF
Ini bermakna bilangan pengesahan daripada nod semasa menulis (NW) ditambah dengan bilangan pengesahan daripada nod semasa membaca (NR) mestilah lebih besar daripada faktor replikasi. Dalam kes kami, RF = 3, yang bermaksud pilihan berikut sesuai:
2 + 2 > 3
3 + 1 > 3
Memandangkan pada asasnya penting bagi kami untuk menyimpan data sebolehpercaya yang mungkin, skema 3+1 telah dipilih. Di samping itu, HB berfungsi pada prinsip yang sama, i.e. perbandingan sedemikian akan lebih adil.
Perlu diingatkan bahawa DataStax melakukan sebaliknya dalam kajian mereka, mereka menetapkan RF = 1 untuk kedua-dua CS dan HB (untuk yang terakhir dengan menukar tetapan HDFS). Ini adalah aspek yang sangat penting kerana kesan ke atas prestasi CS dalam kes ini adalah besar. Sebagai contoh, gambar di bawah menunjukkan peningkatan dalam masa yang diperlukan untuk memuatkan data ke dalam CS:
Di sini kita melihat perkara berikut: lebih banyak benang yang bersaing menulis data, lebih lama masa yang diperlukan. Ini adalah semula jadi, tetapi adalah penting bahawa penurunan prestasi untuk RF=3 adalah lebih tinggi dengan ketara. Dalam erti kata lain, jika kita menulis 4 benang ke dalam 5 jadual setiap satu (20 jumlahnya), maka RF=3 kehilangan kira-kira 2 kali (150 saat untuk RF=3 berbanding 75 untuk RF=1). Tetapi jika kita meningkatkan beban dengan memuatkan data ke dalam 8 jadual dengan 5 utas setiap satu (jumlah 40), maka kehilangan RF=3 sudah 2,7 kali (375 saat berbanding 138).
Mungkin ini adalah sebahagian daripada rahsia ujian beban yang berjaya dilakukan oleh DataStax untuk CS, kerana untuk HB pada pendirian kami menukar faktor replikasi daripada 2 kepada 3 tidak mempunyai sebarang kesan. Itu. cakera bukan halangan HB untuk konfigurasi kami. Walau bagaimanapun, terdapat banyak perangkap lain di sini, kerana perlu diperhatikan bahawa versi HB kami telah ditambal dan diubah suai, persekitarannya berbeza sama sekali, dsb. Perlu diingatkan juga bahawa mungkin saya tidak tahu cara menyediakan CS dengan betul dan terdapat beberapa cara yang lebih berkesan untuk menanganinya, dan saya harap kita akan mengetahuinya dalam ulasan. Tetapi perkara pertama dahulu.
Semua ujian telah dilakukan pada kluster perkakasan yang terdiri daripada 4 pelayan, setiap satu dengan konfigurasi berikut:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 utas.
Cakera: 12 keping SATA HDD
versi java: 1.8.0_111
Versi CS: 3.11.5
parameter cassandra.ymlbilangan_token: 256
hinted_handoff_enabled: benar
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
pengesah: AllowAllAuthenticator
pemberi kuasa: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
kebenaran_kesahan_dalam_ms: 2000
kelayakan_kesahan_dalam_ms: 2000
partitioner: org.apache.cassandra.dht.Murmur3Partitioner
data_file_direktori:
- /data1/cassandra/data # setiap direktori dataN ialah cakera berasingan
- /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: palsu
disk_failure_policy: berhenti
commit_failure_policy: berhenti
prepared_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_tempoh: 14400
row_cache_size_in_mb: 0
row_cache_save_tempoh: 0
counter_cache_size_in_mb:
kaunter_cache_save_tempoh: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: berkala
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
pembekal_benih:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameter:
β biji: "*,*"
concurrent_reads: 256 # cuba 64 - tiada perbezaan yang diperhatikan
concurrent_writes: 256 # cuba 64 - tiada perbezaan yang diperhatikan
concurrent_counter_writes: 256 # cuba 64 - tiada perbezaan yang diperhatikan
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # cuba 16 GB - ia lebih perlahan
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: palsu
trickle_fsync_interval_in_kb: 10240
storan_port: 7000
ssl_storage_port: 7001
mendengar_alamat: *
alamat_siaran: *
listen_on_broadcast_alamat: benar
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: benar
native_transport_port: 9042
start_rpc: benar
alamat_rpc: *
rpc_port: 9160
rpc_keepalive: benar
rpc_server_type: segerak
thrift_framed_transport_size_in_mb: 15
incremental_backups: palsu
snapshot_before_compaction: palsu
auto_snapshot: benar
lajur_indeks_saiz_dalam_kb: 64
lajur_index_cache_size_in_kb: 2
concurrent_compactors: 4
pemadatan_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: palsu
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: tiada
pilihan_penyulitan_pelanggan:
didayakan: palsu
internode_compression: dc
inter_dc_tcp_nodelay: palsu
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: palsu
enable_scripted_user_defined_functions: palsu
windows_timer_interval: 1
transparent_data_encryption_options:
didayakan: palsu
batu nisan_amaran_ambang: 1000
tombstone_failure_threshold: 100000
saiz_kelompok_amaran_ambang_dalam_kb: 200
batch_size_fail_threshold_in_kb: 250
unlog_batch_across_partitions_warn_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: palsu
enable_materialized_views: benar
enable_sasi_indexes: benar
Tetapan GC:
### Tetapan CMS-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorNisbah=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+GunakanCMSIInitiatingOccupancySahaja
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordSentiasa
-XX:+CMSClassUnloadingEnabled
Memori jvm.options diperuntukkan 16Gb (kami juga mencuba 32 Gb, tiada perbezaan yang diperhatikan).
Jadual dibuat dengan arahan:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Versi HB: 1.2.0-cdh5.14.2 (dalam kelas org.apache.hadoop.hbase.regionserver.HRegion kami mengecualikan MetricsRegion yang membawa kepada GC apabila bilangan wilayah adalah lebih daripada 1000 pada RegionServer)
Parameter HBase bukan lalaizookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minit
hbase.client.scanner.timeout.tempoh: 2 minit
hbase.master.handler.count: 10
hbase.regionserver.lease.tempoh, hbase.client.scanner.timeout.tempoh: 2 minit
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.tempoh: 4 jam
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.saiz: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 hari
Coretan Konfigurasi Lanjutan Perkhidmatan HBase (Injap Keselamatan) untuk 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
Pilihan Konfigurasi Java untuk HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIinitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minit
hbase.snapshot.region.timeout: 2 minit
hbase.snapshot.master.timeout.millis: 2 minit
Saiz Log Maks Pelayan HBase REST: 100 MiB
Sandaran Fail Log Maksimum Pelayan HBase REST: 5
Saiz Log Maks Pelayan Jimat HBase: 100 MiB
Sandaran Fail Log Maksimum HBase Thrift Server: 5
Saiz Log Maks Induk: 100 MiB
Kuasai Sandaran Fail Log Maksimum: 5
Saiz Log Maks Pelayan Rantau: 100 MiB
Sandaran Fail Log Maksimum RegionServer: 5
Tetingkap Pengesanan Induk Aktif HBase: 4 minit
dfs.client.hedged.read.threadpool.saiz: 40
dfs.client.hedged.read.threshold.millis: 10 milisaat
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Deskriptor Fail Proses Maksimum: 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.small: 6
hbase.ipc.server.read.threadpool.saiz: 20
Benang Penggerak Wilayah: 6
Saiz Timbunan Java Pelanggan dalam Bait: 1 GiB
Kumpulan Lalai Pelayan HBase REST: 3 GiB
Kumpulan Lalai Pelayan Jimat HBase: 3 GiB
Saiz Timbunan Java Master HBase dalam Bait: 16 GiB
Saiz Timbunan Java HBase RegionServer dalam Bait: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Mencipta jadual:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
ubah 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Terdapat satu perkara penting di sini - penerangan DataStax tidak menyatakan bilangan wilayah yang digunakan untuk mencipta jadual HB, walaupun ini penting untuk volum yang besar. Oleh itu, untuk ujian, kuantiti = 64 telah dipilih, yang membolehkan penyimpanan sehingga 640 GB, i.e. meja saiz sederhana.
Pada masa ujian, HBase mempunyai 22 ribu jadual dan 67 ribu wilayah (ini akan membawa maut untuk versi 1.2.0 jika bukan untuk tampung yang disebutkan di atas).
Sekarang untuk kod. Oleh kerana tidak jelas konfigurasi mana yang lebih berfaedah untuk pangkalan data tertentu, ujian telah dijalankan dalam pelbagai kombinasi. Itu. dalam beberapa ujian, 4 jadual dimuatkan secara serentak (semua 4 nod digunakan untuk sambungan). Dalam ujian lain kami bekerja dengan 8 jadual berbeza. Dalam sesetengah kes, saiz kelompok ialah 100, dalam yang lain 200 (parameter kelompok - lihat kod di bawah). Saiz data untuk nilai ialah 10 bait atau 100 bait (saiz data). Secara keseluruhan, 5 juta rekod telah ditulis dan dibaca ke dalam setiap jadual setiap kali. Pada masa yang sama, 5 utas ditulis/dibaca pada setiap jadual (nombor utas - thNum), setiap satunya menggunakan julat kekuncinya sendiri (kiraan = 1 juta):
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);
}
}
Sehubungan itu, fungsi yang sama telah disediakan untuk 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);
}
}
Oleh kerana dalam HB pelanggan mesti menjaga pengedaran seragam data, fungsi pengasinan utama kelihatan seperti ini:
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);
}
Sekarang bahagian yang paling menarik - hasilnya:
Perkara yang sama dalam bentuk graf:
Kelebihan HB sangat mengejutkan sehinggakan terdapat kecurigaan bahawa terdapat beberapa jenis kesesakan dalam persediaan CS. Walau bagaimanapun, Googling dan mencari parameter yang paling jelas (seperti concurrent_writes atau memtable_heap_space_in_mb) tidak mempercepatkan perkara. Pada masa yang sama, kayu balak adalah bersih dan tidak menyumpah apa-apa.
Data diedarkan sama rata merentasi nod, statistik dari semua nod adalah lebih kurang sama.
Beginilah rupa statistik jadual daripada salah satu nodRuang kekunci: ks
Kiraan Bacaan: 9383707
Latensi Baca: 0.04287025042448576 ms
Tulis Kiraan: 15462012
Tulis Latensi: 0.1350068438699957 ms
Siram menunggu: 0
Jadual: t1
Kiraan boleh SST: 16
Ruang yang digunakan (hidup): 148.59 MiB
Ruang yang digunakan (jumlah): 148.59 MiB
Ruang yang digunakan oleh syot kilat (jumlah): 0 bait
Memori luar timbunan digunakan (jumlah): 5.17 MiB
Nisbah Mampatan SSTable: 0.5720989576459437
Bilangan partition (anggaran): 3970323
Bilangan sel boleh ubah: 0
Saiz data boleh ubah: 0 bait
Memori timbunan tidak boleh dipisahkan yang digunakan: 0 bait
Kiraan suis boleh ubah: 5
Kiraan bacaan tempatan: 2346045
Kependaman bacaan setempat: NaN ms
Kiraan tulis tempatan: 3865503
Kependaman tulis setempat: NaN ms
Siram belum selesai: 0
Peratusan dibaiki: 0.0
Penapis Bloom positif palsu: 25
Nisbah palsu penapis Bloom: 0.00000
Ruang penapis Bloom digunakan: 4.57 MiB
Bloom filter off timbunan memori digunakan: 4.57 MiB
Ringkasan indeks dari memori timbunan yang digunakan: 590.02 KiB
Metadata mampatan dari memori timbunan yang digunakan: 19.45 KiB
Bait minimum partition padat: 36
Bait maksimum partition padat: 42
Pembahagian padat min bait: 42
Purata sel hidup setiap keping (lima minit terakhir): NaN
Maksimum sel hidup setiap keping (lima minit terakhir): 0
Purata batu nisan setiap keping (lima minit terakhir): NaN
Batu nisan maksimum setiap keping (lima minit terakhir): 0
Mutasi Digugurkan: 0 bait
Percubaan untuk mengurangkan saiz kumpulan (walaupun menghantarnya secara individu) tidak memberi kesan, ia hanya menjadi lebih teruk. Ada kemungkinan bahawa sebenarnya ini adalah prestasi maksimum untuk CS, kerana hasil yang diperoleh untuk CS adalah serupa dengan yang diperoleh untuk DataStax - kira-kira ratusan ribu operasi sesaat. Di samping itu, jika kita melihat penggunaan sumber, kita akan melihat bahawa CS menggunakan lebih banyak CPU dan cakera:
Angka tersebut menunjukkan penggunaan semasa menjalankan semua ujian berturut-turut untuk kedua-dua pangkalan data.
Mengenai kelebihan bacaan HB yang berkuasa. Di sini anda boleh melihat bahawa untuk kedua-dua pangkalan data, penggunaan cakera semasa membaca adalah sangat rendah (ujian baca adalah bahagian akhir kitaran ujian untuk setiap pangkalan data, contohnya untuk CS ini adalah dari 15:20 hingga 15:40). Dalam kes HB, sebabnya adalah jelas - kebanyakan data tergantung dalam ingatan, dalam memstore, dan beberapa dicache dalam cache blok. Bagi CS, ia tidak begitu jelas cara ia berfungsi, tetapi kitar semula cakera juga tidak kelihatan, tetapi untuk berjaga-jaga, percubaan telah dibuat untuk membolehkan cache row_cache_size_in_mb = 2048 dan set caching = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, tetapi itu memburukkan lagi keadaan.
Ia juga patut disebut sekali lagi satu perkara penting tentang bilangan wilayah dalam HB. Dalam kes kami, nilai itu ditentukan sebagai 64. Jika anda mengurangkannya dan menjadikannya sama dengan, sebagai contoh, 4, maka apabila membaca, kelajuan menurun sebanyak 2 kali. Sebabnya memstore akan penuh dengan lebih cepat dan fail akan dibuang lebih kerap dan apabila membaca, lebih banyak fail perlu diproses, yang merupakan operasi yang agak rumit untuk HB. Dalam keadaan sebenar, ini boleh dirawat dengan memikirkan strategi prasplit dan pemadatan; khususnya, kami menggunakan utiliti bertulis sendiri yang mengumpul sampah dan memampatkan HFiles sentiasa di latar belakang. Ada kemungkinan bahawa untuk ujian DataStax mereka memperuntukkan hanya 1 rantau bagi setiap jadual (yang tidak betul) dan ini sedikit sebanyak akan menjelaskan mengapa HB sangat rendah dalam ujian bacaan mereka.
Kesimpulan awal berikut diambil daripada ini. Dengan mengandaikan bahawa tiada kesilapan besar dilakukan semasa ujian, maka Cassandra kelihatan seperti raksasa dengan kaki tanah liat. Lebih tepat lagi, semasa dia mengimbangi satu kaki, seperti dalam gambar pada permulaan artikel, dia menunjukkan hasil yang agak baik, tetapi dalam pertarungan di bawah keadaan yang sama dia kalah secara langsung. Pada masa yang sama, dengan mengambil kira penggunaan CPU yang rendah pada perkakasan kami, kami belajar untuk menanam dua HB RegionServer setiap hos dan dengan itu menggandakan prestasi. Itu. Dengan mengambil kira penggunaan sumber, keadaan untuk CS adalah lebih menyedihkan.
Sudah tentu, ujian ini agak sintetik dan jumlah data yang digunakan di sini agak sederhana. Ada kemungkinan jika kita bertukar kepada terabait, keadaan akan berbeza, tetapi untuk HB kita boleh memuatkan terabait, untuk CS ini ternyata bermasalah. Ia sering melemparkan OperationTimedOutException walaupun dengan volum ini, walaupun parameter untuk menunggu respons telah meningkat beberapa kali berbanding dengan yang lalai.
Saya berharap melalui usaha bersama kita akan menemui kesesakan CS dan jika kita dapat mempercepatkannya, maka pada akhir posting saya pasti akan menambah maklumat tentang keputusan akhir.
UPD: Atas nasihat rakan-rakan seperjuangan, saya berjaya mempercepatkan bacaan. Adakah:
159 ops (644 jadual, 4 aliran, kumpulan 5).
Ditambah:
.withLoadBalancingPolicy(TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Dan saya bermain-main dengan bilangan benang. Hasilnya adalah seperti berikut:
4 meja, 100 utas, kelompok = 1 (sekeping demi sekeping): 301 ops
4 jadual, 100 utas, kelompok = 10: 447 ops
4 jadual, 100 utas, kelompok = 100: 625 ops
Kemudian saya akan menggunakan petua penalaan lain, menjalankan kitaran ujian penuh dan menambah keputusan pada akhir siaran.
Sumber: www.habr.com