Ini bahkan bukan lelucon, tampaknya gambaran khusus ini paling akurat mencerminkan esensi dari database ini, dan pada akhirnya akan menjadi jelas alasannya:
Menurut DB-Engines Ranking, dua database kolom NoSQL yang paling populer adalah Cassandra (selanjutnya disebut CS) dan HBase (HB).
Atas kehendak takdir, tim manajemen pemuatan data kami di Bank Tabungan sudah melakukannya dan bekerja sama dengan HB. Selama ini kami mempelajari kelebihan dan kekurangannya dengan cukup baik serta belajar cara memasaknya. Namun hadirnya alternatif berupa CS selalu memaksa kami sedikit menyiksa diri dengan keraguan: apakah pilihan yang kami ambil sudah tepat? Apalagi hasilnya , yang dilakukan oleh DataStax, mereka mengatakan bahwa CS dengan mudah mengalahkan HB dengan skor yang hampir menghancurkan. Di sisi lain, DataStax adalah pihak yang berkepentingan, dan Anda tidak boleh mempercayai kata-kata mereka begitu saja. Kami juga dibuat bingung dengan sedikitnya informasi mengenai kondisi pengujian, sehingga kami memutuskan untuk mencari tahu sendiri siapa raja BigData NoSql, dan hasil yang didapat ternyata sangat menarik.
Namun, sebelum beralih ke hasil pengujian yang dilakukan, perlu dijelaskan aspek penting dari konfigurasi lingkungan. Faktanya CS bisa digunakan dalam mode yang memungkinkan hilangnya data. Itu. ini adalah ketika hanya satu server (node) yang bertanggung jawab atas data kunci tertentu, dan jika karena alasan tertentu gagal, maka nilai kunci ini akan hilang. Bagi sebagian besar tugas, hal ini tidak terlalu penting, namun bagi sektor perbankan, hal ini merupakan pengecualian dan bukan aturan. Dalam kasus kami, penting untuk memiliki beberapa salinan data untuk penyimpanan yang andal.
Oleh karena itu, hanya mode operasi CS dalam mode replikasi rangkap tiga yang dipertimbangkan, yaitu. Pembuatan casespace dilakukan dengan parameter berikut:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Selanjutnya, ada dua cara untuk memastikan tingkat konsistensi yang dibutuhkan. Peraturan umum:
Barat Laut + NR > RF
Artinya jumlah konfirmasi dari node saat menulis (NW) ditambah jumlah konfirmasi dari node saat membaca (NR) harus lebih besar dari faktor replikasinya. Dalam kasus kami, RF = 3, yang berarti opsi berikut ini cocok:
2 + 2 > 3
3 + 1 > 3
Karena pada dasarnya penting bagi kami untuk menyimpan data seandal mungkin, skema 3+1 dipilih. Selain itu, HB bekerja dengan prinsip serupa, yaitu. perbandingan seperti itu akan lebih adil.
Perlu dicatat bahwa DataStax melakukan hal sebaliknya dalam penelitiannya, mereka menetapkan RF = 1 untuk CS dan HB (untuk yang terakhir dengan mengubah pengaturan HDFS). Ini merupakan aspek yang sangat penting karena dampaknya terhadap kinerja CS dalam hal ini sangat besar. Misalnya gambar di bawah ini menunjukkan peningkatan waktu yang dibutuhkan untuk memuat data ke CS:
Di sini kita melihat hal berikut: semakin banyak thread yang bersaing menulis data, semakin lama waktu yang dibutuhkan. Hal ini wajar, namun penting agar penurunan kinerja untuk RF=3 jauh lebih tinggi. Dengan kata lain, jika kita menulis 4 thread ke dalam 5 tabel masing-masing (total 20), maka RF=3 kalah sekitar 2 kali (150 detik untuk RF=3 versus 75 untuk RF=1). Namun jika kita menambah beban dengan memuat data ke dalam 8 tabel dengan masing-masing 5 thread (total 40), maka kerugian RF=3 sudah 2,7 kali (375 detik berbanding 138).
Mungkin ini sebagian rahasia keberhasilan pengujian beban yang dilakukan oleh DataStax untuk CS, karena untuk HB di stand kami, mengubah faktor replikasi dari 2 menjadi 3 tidak berpengaruh apa pun. Itu. disk bukanlah hambatan HB untuk konfigurasi kami. Namun, ada banyak kendala lain di sini, karena perlu dicatat bahwa versi HB kami sedikit ditambal dan diubah, lingkungannya sangat berbeda, dll. Perlu juga dicatat bahwa mungkin saya tidak tahu cara mempersiapkan CS dengan benar dan ada beberapa cara yang lebih efektif untuk mengatasinya, dan saya harap kita akan mengetahuinya di komentar. Tapi hal pertama yang pertama.
Semua pengujian dilakukan pada cluster perangkat keras yang terdiri dari 4 server, masing-masing dengan konfigurasi berikut:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 utas.
Disk: 12 buah HDD SATA
versi java: 1.8.0_111
Versi CS: 3.11.5
parameter cassandra.ymljumlah_tokens: 256
petunjuk_handoff_enabled: benar
petunjuk_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
petunjuk_direktori: /data10/cassandra/hints
petunjuk_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
pengautentikasi: IzinkanSemuaAuthenticator
pemberi otorisasi: AllowAllAuthorizer
role_manager: CassandraRoleManager
role_validity_in_ms: 2000
izin_validitas_in_ms: 2000
kredensial_validitas_in_ms: 2000
partisi: org.apache.cassandra.dht.Murmur3Partitioner
direktori_file_data:
- /data1/cassandra/data # setiap direktori dataN adalah disk terpisah
- /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: salah
disk_failure_policy: berhenti
commit_failure_policy: berhenti
pernyataan_siap_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
kunci_cache_size_in_mb:
key_cache_save_period: 14400
baris_cache_size_in_mb: 0
baris_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
direktori_caches_tersimpan: /data10/cassandra/saved_caches
commitlog_sync: berkala
commitlog_sync_period_in_ms: 10000
komitlog_segment_size_in_mb: 32
penyedia_benih:
- nama_kelas: org.apache.cassandra.locator.SimpleSeedProvider
parameter:
- biji: "*,*"
concurrent_reads: 256 # mencoba 64 - tidak ada perbedaan yang terlihat
concurrent_writes: 256 # mencoba 64 - tidak ada perbedaan yang terlihat
concurrent_counter_writes: 256 # mencoba 64 - tidak ada perbedaan yang terlihat
bersamaan_terwujud_view_writes: 32
memtable_heap_space_in_mb: 2048 # mencoba 16 GB - lebih lambat
memtable_allocation_type: heap_buffers
indeks_summary_capacity_in_mb:
indeks_summary_resize_interval_in_menit: 60
trickle_fsync: salah
trickle_fsync_interval_in_kb: 10240
penyimpanan_port: 7000
ssl_storage_port: 7001
alamat_dengarkan: *
alamat_siaran: *
mendengarkan_on_broadcast_address: benar
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: benar
port_transportasi asli: 9042
start_rpc: benar
alamat_rpc: *
rpc_port: 9160
rpc_keepalive: benar
rpc_server_type: sinkronisasi
barang bekas_bingkai_transportasi_ukuran_dalam_mb: 15
cadangan_tambahan: salah
snapshot_before_compaction: salah
auto_snapshot: benar
kolom_index_size_in_kb: 64
kolom_index_cache_size_in_kb: 2
pemadat_bersamaan: 4
pemadatan_throughput_mb_per_detik: 1600
sstable_preemptive_open_interval_in_mb: 50
baca_permintaan_timeout_in_ms: 100000
rentang_request_timeout_in_ms: 200000
tulis_permintaan_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
lambat_query_log_timeout_in_ms: 500
cross_node_timeout: salah
endpoint_snitch: GossipingPropertyFileSnitch
dinamis_snitch_update_interval_in_ms: 100
dinamis_snitch_reset_interval_in_ms: 600000
ambang batas_keburukan_dinamis_snitch: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
opsi_enkripsi_server:
internode_encryption: tidak ada
opsi_enkripsi_klien:
diaktifkan: salah
ruas_kompresi: dc
inter_dc_tcp_nodelay: salah
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
aktifkan_pengguna_definisi_fungsi: salah
aktifkan_scripted_user_definisi_fungsi: salah
interval_timer_jendela: 1
opsi_enkripsi_data_transparan:
diaktifkan: salah
batu nisan_peringatkan_ambang batas: 1000
ambang_kegagalan_batu nisan: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unloged_batch_across_partitions_warn_threshold: 10
pemadatan_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: salah
aktifkan_terwujud_tampilan: benar
aktifkan_sasi_indexes: benar
Pengaturan GC:
### Pengaturan CMS-XX:+GunakanParNewGC
-XX:+GunakanConcMarkSweepGC
-XX:+CMSParallelRemarkDiaktifkan
-XX: Rasio Penyintas = 8
-XX:Ambang Batas Maksimum=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+Hanya GunakanCMSInitiatingOccupancy
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkDiaktifkan
-XX:+CMSEdenChunksRecordSelalu
-XX:+CMSClassUnloadingDiaktifkan
Memori jvm.options 16 Gb dialokasikan (kami juga mencoba 32 Gb, tidak ada perbedaan yang terlihat).
Tabel dibuat dengan perintah:
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 (di kelas org.apache.hadoop.hbase.regionserver.HRegion kami mengecualikan MetricsRegion yang menghasilkan GC ketika jumlah wilayah lebih dari 1000 di RegionServer)
Parameter HBase non-defaultzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 menit
hbase.client.scanner.timeout.periode: 2 menit
hbase.master.handler.hitungan: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 menit
hbase.regionserver.handler.hitungan: 160
hbase.regionserver.metahandler.hitungan: 30
hbase.regionserver.logroll.periode: 4 jam
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.ukuran: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 hari
Cuplikan Konfigurasi Lanjutan Layanan HBase (Katup Pengaman) untuk hbase-site.xml:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflusinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Opsi Konfigurasi Java untuk HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 menit
hbase.snapshot.region.timeout: 2 menit
hbase.snapshot.master.timeout.millis: 2 menit
Ukuran Log Maks Server HBase REST: 100 MiB
Cadangan File Log Maksimum HBase REST Server: 5
Ukuran Log Maks Server Hemat HBase: 100 MiB
Cadangan File Log Maksimum HBase Thrift Server: 5
Ukuran Log Maks Utama: 100 MiB
Cadangan File Log Maksimum Master: 5
Ukuran Log Maks RegionServer: 100 MiB
Pencadangan File Log Maksimum RegionServer: 5
Jendela Deteksi Master Aktif HBase: 4 menit
dfs.client.hedged.read.threadpool.ukuran: 40
dfs.client.hedged.read.threshold.millis: 10 milidetik
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Deskriptor File Proses Maksimum: 180000
hbase.thrift.minWorkerThread: 200
hbase.master.executor.openregion.thread: 30
hbase.master.executor.closeregion.thread: 30
hbase.master.executor.serverops.thread: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.ukuran: 20
Utas Penggerak Wilayah: 6
Ukuran Heap Java Klien dalam Byte: 1 GiB
Grup Default Server REST HBase: 3 GiB
Grup Default Server Hemat HBase: 3 GiB
Ukuran Java Heap HBase Master dalam Byte: 16 GiB
Ukuran Java Heap dari HBase RegionServer dalam Byte: 32 GiB
+Penjaga Kebun Binatang
maxClientCnxns: 601
maxSessionTimeout: 120000
Membuat tabel:
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'}
Ada satu poin penting di sini - deskripsi DataStax tidak menyebutkan berapa banyak wilayah yang digunakan untuk membuat tabel HB, meskipun ini penting untuk volume besar. Oleh karena itu, untuk pengujian, kuantitas = 64 dipilih, yang memungkinkan penyimpanan hingga 640 GB, mis. meja berukuran sedang.
Pada saat pengujian, HBase memiliki 22 ribu tabel dan 67 ribu wilayah (ini akan berakibat fatal untuk versi 1.2.0 jika bukan karena patch yang disebutkan di atas).
Sekarang untuk kodenya. Karena tidak jelas konfigurasi mana yang lebih menguntungkan untuk database tertentu, pengujian dilakukan dalam berbagai kombinasi. Itu. dalam beberapa pengujian, 4 tabel dimuat secara bersamaan (semua 4 node digunakan untuk koneksi). Dalam pengujian lain kami bekerja dengan 8 tabel berbeda. Dalam beberapa kasus, ukuran batch adalah 100, di kasus lain 200 (parameter batch - lihat kode di bawah). Ukuran data untuk nilai adalah 10 byte atau 100 byte (dataSize). Secara total, 5 juta catatan ditulis dan dibaca ke dalam setiap tabel setiap saat. Pada saat yang sama, 5 utas ditulis/dibaca ke setiap tabel (nomor utas - thNum), yang masing-masing menggunakan rentang kuncinya sendiri (hitungan = 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);
}
}
Oleh karena itu, fungsi serupa 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);
}
}
Karena di HB klien harus menjaga keseragaman distribusi data, fungsi pengasinan kunci terlihat 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 bagian yang paling menarik adalah hasilnya:
Hal yang sama dalam bentuk grafik:
Keunggulan HB sangat mengejutkan sehingga ada kecurigaan adanya semacam hambatan dalam pengaturan CS. Namun, Googling dan mencari parameter yang paling jelas (seperti concurrent_writes atau memtable_heap_space_in_mb) tidak mempercepat. Pada saat yang sama, lognya bersih dan tidak ada sumpah serapah.
Data didistribusikan secara merata ke seluruh node, statistik dari semua node kurang lebih sama.
Ini adalah tampilan tabel statistik dari salah satu nodeRuang kunci: ks
Jumlah Baca: 9383707
Latensi Baca: 0.04287025042448576 ms
Jumlah Tulis: 15462012
Latensi Tulis: 0.1350068438699957 ms
Pembilasan Tertunda: 0
Tabel: t1
Jumlah SSTable: 16
Ruang yang digunakan (langsung): 148.59 MiB
Ruang yang digunakan (total): 148.59 MiB
Ruang yang digunakan oleh snapshot (total): 0 byte
Memori off heap yang digunakan (total): 5.17 MiB
Rasio Kompresi SSTable: 0.5720989576459437
Jumlah partisi (perkiraan): 3970323
Jumlah sel yang dapat diingat: 0
Ukuran data yang dapat diingat: 0 byte
Memori heap memtable yang digunakan: 0 byte
Jumlah saklar yang dapat dibaca: 5
Jumlah baca lokal: 2346045
Latensi baca lokal: NaN ms
Jumlah penulisan lokal: 3865503
Latensi tulis lokal: NaN ms
Pembilasan tertunda: 0
Persen diperbaiki: 0.0
Filter Bloom positif palsu: 25
Rasio salah filter mekar: 0.00000
Ruang filter Bloom yang digunakan: 4.57 MiB
Filter Bloom dari memori heap yang digunakan: 4.57 MiB
Ringkasan indeks dari memori heap yang digunakan: 590.02 KiB
Metadata kompresi dari memori heap yang digunakan: 19.45 KiB
Byte minimum partisi yang dipadatkan: 36
Byte maksimum partisi yang dipadatkan: 42
Partisi yang dipadatkan berarti byte: 42
Rata-rata sel hidup per irisan (lima menit terakhir): NaN
Sel hidup maksimum per irisan (lima menit terakhir): 0
Rata-rata batu nisan per irisan (lima menit terakhir): NaN
Batu nisan maksimum per irisan (lima menit terakhir): 0
Mutasi yang Dijatuhkan: 0 byte
Upaya untuk mengurangi ukuran batch (bahkan mengirimkannya satu per satu) tidak membuahkan hasil, malah bertambah buruk. Bisa jadi sebenarnya ini adalah performa maksimal untuk CS, karena hasil yang diperoleh CS serupa dengan yang diperoleh DataStax - sekitar ratusan ribu operasi per detik. Selain itu, jika kita melihat pemanfaatan sumber daya, kita akan melihat bahwa CS menggunakan lebih banyak CPU dan disk:
Gambar tersebut menunjukkan pemanfaatan selama menjalankan semua pengujian berturut-turut untuk kedua database.
Mengenai keunggulan membaca HB yang kuat. Di sini Anda dapat melihat bahwa untuk kedua database, pemanfaatan disk selama membaca sangat rendah (tes baca adalah bagian terakhir dari siklus pengujian untuk setiap database, misalnya untuk CS dari pukul 15:20 hingga 15:40). Dalam kasus HB, alasannya jelas - sebagian besar data hang di memori, di memstore, dan beberapa di-cache di blockcache. Sedangkan untuk CS, cara kerjanya tidak begitu jelas, tetapi daur ulang disk juga tidak terlihat, tetapi untuk berjaga-jaga, upaya dilakukan untuk mengaktifkan cache row_cache_size_in_mb = 2048 dan mengatur caching = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, tapi itu membuatnya lebih buruk lagi.
Perlu juga disebutkan sekali lagi poin penting tentang jumlah daerah di HB. Dalam kasus kami, nilainya ditetapkan sebagai 64. Jika Anda menguranginya dan membuatnya sama dengan, misalnya, 4, maka saat membaca, kecepatannya turun 2 kali lipat. Alasannya adalah memstore akan terisi lebih cepat dan file akan lebih sering di-flush dan saat membaca, lebih banyak file yang perlu diproses, yang merupakan operasi yang agak rumit untuk HB. Dalam kondisi nyata, hal ini dapat diatasi dengan memikirkan strategi pra-pemisahan dan pemadatan; khususnya, kami menggunakan utilitas yang ditulis sendiri yang mengumpulkan sampah dan mengompresi HFiles secara konstan di latar belakang. Sangat mungkin bahwa untuk tes DataStax mereka hanya mengalokasikan 1 wilayah per tabel (yang tidak benar) dan ini akan menjelaskan mengapa HB sangat rendah dalam tes membaca mereka.
Kesimpulan awal berikut diambil dari sini. Dengan asumsi tidak ada kesalahan besar yang dilakukan selama pengujian, maka Cassandra terlihat seperti raksasa dengan kaki dari tanah liat. Lebih tepatnya, saat dia menyeimbangkan dengan satu kaki, seperti pada gambar di awal artikel, dia menunjukkan hasil yang relatif baik, tetapi dalam pertarungan dalam kondisi yang sama dia langsung kalah. Pada saat yang sama, dengan mempertimbangkan penggunaan CPU yang rendah pada perangkat keras kami, kami belajar untuk menanam dua HB RegionServer per host dan dengan demikian menggandakan kinerja. Itu. Dengan mempertimbangkan pemanfaatan sumber daya, situasi CS bahkan lebih memprihatinkan.
Tentu saja, pengujian ini cukup sintetik dan jumlah data yang digunakan di sini relatif sedikit. Bisa jadi kalau kita pindah ke terabyte, situasinya akan berbeda, tapi kalau untuk HB kita bisa memuat terabyte, untuk CS ternyata bermasalah. Seringkali ia mengeluarkan OperationTimedOutException bahkan dengan volume ini, meskipun parameter untuk menunggu respons telah ditingkatkan beberapa kali dibandingkan dengan yang default.
Saya berharap melalui upaya bersama kita dapat menemukan kemacetan CS dan jika bisa dipercepat, maka di akhir postingan pasti saya akan menambahkan informasi tentang hasil akhirnya.
UPD: Berkat nasehat kawan-kawan, saya berhasil mempercepat pembacaannya. Dulu:
159 operasi (644 tabel, 4 aliran, batch 5).
Ditambahkan oleh:
.withLoadBalancingPolicy(TokenAwarePolicy baru(DCAwareRoundRobinPolicy.builder().build()))
Dan saya bermain-main dengan jumlah utas. Hasilnya adalah sebagai berikut:
4 tabel, 100 thread, batch = 1 (sepotong demi sepotong): 301 ops
4 tabel, 100 thread, batch = 10: 447 ops
4 tabel, 100 thread, batch = 100: 625 ops
Nanti saya akan menerapkan tips penyetelan lainnya, menjalankan siklus pengujian penuh dan menambahkan hasilnya di akhir postingan.
Sumber: www.habr.com