Pertempuran dua Yakozun, atau Cassandra vs HBase. Pengalaman tim Sberbank

Ini bahkan bukan lelucon, sepertinya gambar khusus ini paling akurat mencerminkan esensi dari database ini, dan pada akhirnya akan menjadi jelas mengapa:



Menurut Peringkat DB-Engine, dua basis kolom NoSQL paling populer adalah Cassandra (selanjutnya CS) dan HBase (HB).



Dengan kehendak takdir, tim manajemen pemuatan data kami di Sberbank telah bekerja sama dengan HB sejak lama . Selama waktu ini, kami mempelajari kekuatan dan kelemahannya dengan cukup baik dan belajar cara memasaknya. Namun, kehadiran alternatif dalam bentuk CS sepanjang waktu membuat saya menyiksa diri sendiri dengan keraguan: apakah kita membuat pilihan yang tepat? Selain itu, hasil perbandingan yang dilakukan oleh DataStax mengatakan bahwa CS dengan mudah mengalahkan HB dengan skor yang hampir menghancurkan. Di sisi lain, DataStax adalah orang yang tertarik, dan Anda tidak boleh bicara di sini. Juga, sedikit informasi tentang kondisi pengujian itu memalukan, jadi kami memutuskan untuk mencari tahu sendiri siapa raja BigData NoSql, dan hasilnya sangat menarik.

Namun, sebelum beralih ke hasil pengujian yang dilakukan, perlu untuk menggambarkan aspek-aspek penting dari konfigurasi lingkungan. Faktanya adalah bahwa CS dapat digunakan dalam mode toleransi kehilangan data. Yaitu ini adalah ketika hanya satu server (node) yang bertanggung jawab untuk data kunci tertentu, dan jika jatuh karena suatu alasan, nilai kunci ini akan hilang. Untuk banyak tugas ini tidak kritis, tetapi untuk sektor perbankan ini merupakan pengecualian daripada aturan. Dalam kasus kami, penting untuk memiliki beberapa salinan data untuk penyimpanan yang andal.

Oleh karena itu, hanya mode CS dari replikasi tiga yang dipertimbangkan, yaitu pembuatan case dilakukan dengan parameter berikut:

CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3}; 

Selanjutnya, ada dua cara untuk memastikan tingkat konsistensi yang diperlukan. Aturan umum:
NW + NR> RF

Ini berarti bahwa jumlah konfirmasi dari node ketika menulis (NW) ditambah jumlah konfirmasi dari node ketika membaca (NR) harus lebih besar daripada faktor replikasi. Dalam kasus kami, RF = 3 sehingga opsi berikut cocok:
2 + 2> 3
3 + 1> 3

Karena sangat penting bagi kami untuk menjaga data seandal mungkin, skema 3 + 1 dipilih. Selain itu, HB bekerja dengan dasar yang sama, yaitu perbandingan seperti itu akan lebih jujur.

Perlu dicatat bahwa DataStax melakukan yang sebaliknya dalam penelitian mereka, mereka menetapkan RF = 1 untuk CS dan HB (untuk yang terakhir dengan mengubah pengaturan HDFS). Ini adalah aspek yang sangat penting, karena dampaknya pada kinerja CS dalam kasus ini sangat besar. Misalnya, gambar di bawah ini menunjukkan peningkatan waktu yang diperlukan untuk memuat data ke dalam CS:



Di sini kita melihat yang berikut, semakin banyak utas bersaing menulis data, semakin lama waktu yang dibutuhkan. Ini wajar, tetapi penting bahwa penurunan kinerja untuk RF = 3 secara signifikan lebih tinggi. Dengan kata lain, jika kita menulis dalam 4 tabel di masing-masing 5 aliran (total 20), maka RF = 3 kehilangan sekitar 2 kali (150 detik RF = 3 berbanding 75 untuk RF = 1). Tetapi jika kita menambah beban dengan memuat data ke dalam 8 tabel di masing-masing 5 aliran (total 40), maka kehilangan RF = 3 sudah 2,7 kali (375 detik berbanding 138).

Mungkin sebagian inilah rahasia keberhasilan pengujian DataStax untuk pengujian beban CS, karena untuk HB di stan kami, mengubah faktor replikasi dari 2 menjadi 3 tidak berpengaruh. Yaitu disk bukanlah hambatan untuk HB untuk konfigurasi kami. Namun, ada banyak jebakan lain, karena harus dicatat bahwa versi HB kami sedikit ditambal dan dikaburkan, lingkungannya sangat berbeda, dll. Perlu juga dicatat bahwa mungkin saya tidak tahu bagaimana mempersiapkan CS dengan benar dan ada beberapa cara yang lebih efektif untuk bekerja dengannya dan saya berharap di komentar kita akan mengetahuinya. Tetapi hal pertama yang pertama.

Semua tes dilakukan pada kluster besi yang terdiri dari 4 server, masing-masing dalam konfigurasi:

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


Pengaturan GC:


Memori jvm.options dialokasikan 16Gb (masih mencoba 32 Gb, tidak ada perbedaan yang terlihat).

Membuat tabel dilakukan oleh 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 (dalam kelas org.apache.hadoop.hbase.regionserver.HRegion kami mengecualikan MetricsRegion yang mengarah ke GC dengan lebih dari 1000 wilayah di RegionServer)


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 - deskripsi DataStax tidak mengatakan berapa banyak daerah yang digunakan untuk membuat tabel HB, meskipun ini sangat penting untuk volume besar. Oleh karena itu, untuk pengujian, angka = 64 dipilih, yang memungkinkan penyimpanan hingga 640 GB, mis. meja ukuran sedang.

Pada saat pengujian, HBase memiliki 22 ribu tabel dan 67 ribu wilayah (ini akan mematikan untuk versi 1.2.0, jika bukan karena tambalan yang disebutkan di atas).

Sekarang untuk kodenya. Karena tidak jelas konfigurasi mana yang lebih menguntungkan untuk database tertentu, pengujian dilakukan dalam berbagai kombinasi. Yaitu dalam beberapa tes, beban berjalan secara bersamaan ke 4 tabel (semua 4 node digunakan untuk koneksi). Dalam tes lain, mereka bekerja dengan 8 tabel berbeda. Dalam beberapa kasus, ukuran bets adalah 100, dalam 200 lainnya (parameter batch - lihat kode di bawah). Ukuran data untuk nilai adalah 10 byte atau 100 byte (dataSize). Secara total, 5 juta catatan ditulis dan dikurangi setiap kali dalam setiap tabel. Pada saat yang sama, 5 aliran ditulis / dibaca ke dalam setiap tabel (nomor aliran adalah angka), masing-masing menggunakan rentang kunci sendiri (jumlah = 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 klien harus menjaga distribusi data yang seragam dalam HB, fungsi pengasinan utama 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 yang paling menarik adalah hasilnya:



Sama seperti grafik:



Keuntungan dari HB sangat menakjubkan sehingga ada kecurigaan semacam kemacetan dalam pengaturan CS. Namun, googling dan torsi parameter yang paling jelas (seperti concurrent_writes atau memtable_heap_space_in_mb) tidak memberikan akselerasi. Pada saat yang sama, log bersih, jangan bersumpah apa pun.

Data berbaring secara merata di seluruh node, statistik dari semua node kira-kira sama.


Upaya untuk mengurangi ukuran bets (hingga mengirim satu per satu) tidak memberikan efek, hanya saja semakin buruk. Ada kemungkinan bahwa sebenarnya ini benar-benar kinerja maksimum untuk CS, karena hasil yang diperoleh pada CS mirip dengan yang diperoleh untuk DataStax - sekitar ratusan ribu operasi per detik. Selain itu, jika Anda melihat pemanfaatan sumber daya, Anda akan melihat bahwa CS menggunakan lebih banyak CPU dan disk:


Gambar tersebut menunjukkan pemanfaatan selama menjalankan semua tes berturut-turut untuk kedua basis data.

Mengenai manfaat membaca yang kuat dari HB. Dapat dilihat bahwa untuk kedua basis data, pemanfaatan disk saat membaca sangat rendah (tes baca adalah bagian akhir dari siklus pengujian untuk setiap basis data, misalnya, untuk CS mulai 15:20 hingga 15:40). Dalam kasus HB, alasannya jelas - sebagian besar data hang di memori, di memstore, dan beberapa di-cache di blockcache. Adapun CS, tidak begitu jelas cara kerjanya, namun, pemanfaatan disk juga tidak terlihat, tetapi untuk berjaga-jaga, upaya dilakukan untuk mengaktifkan row_cache_size_in_mb = 2048 cache dan mengatur caching = {'keys': 'ALL', 'rows_per_partition': ' 2.000.000}, tetapi itu membuatnya sedikit lebih buruk.

Sekali lagi perlu dikatakan poin penting tentang jumlah daerah dalam HB. Dalam kasus kami, nilai 64 ditunjukkan. Jika Anda menguranginya dan membuatnya sama dengan misalnya 4, maka ketika membaca kecepatan turun 2 kali. Alasannya adalah bahwa memstore akan tersumbat lebih cepat dan file akan lebih sering memerah dan ketika membacanya perlu memproses lebih banyak file, yang merupakan operasi yang agak rumit untuk HB. Dalam kondisi nyata, ini dapat diatasi dengan memikirkan strategi persiapan dan pemadatan, khususnya, kami menggunakan utilitas buatan sendiri yang mengumpulkan sampah dan memadatkan HFiles secara terus-menerus di latar belakang. Ada kemungkinan bahwa untuk tes DataStax, umumnya 1 wilayah dialokasikan per tabel (yang tidak benar) dan ini akan sedikit menjelaskan mengapa HB kehilangan begitu banyak dalam tes baca mereka.

Kesimpulan awal dari ini adalah sebagai berikut. Dengan asumsi tidak ada kesalahan besar yang dibuat selama pengujian, Cassandra seperti raksasa dengan kaki tanah liat. Lebih tepatnya, ketika dia menyeimbangkan pada satu kaki, seperti pada gambar di awal artikel, dia menunjukkan hasil yang relatif baik, tetapi ketika dia bertarung dalam kondisi yang sama, dia langsung kalah. Pada saat yang sama, dengan mempertimbangkan pemanfaatan CPU yang rendah pada perangkat keras kami, kami belajar untuk menanam dua HB RegionServer per host dan dengan demikian menggandakan produktivitas. Yaitu dengan mempertimbangkan pemanfaatan sumber daya, situasi untuk CS bahkan lebih menyedihkan.

Tentu saja, tes ini cukup sintetik dan jumlah data yang digunakan di sini relatif sederhana. Ada kemungkinan bahwa ketika beralih ke terabyte, situasinya akan berbeda, tetapi jika untuk HB kita dapat memuat terabyte, maka untuk CS ini ternyata bermasalah. Itu sering melempar OperationTimedOutException bahkan dengan volume ini, meskipun parameter harapan respon sudah meningkat beberapa kali dibandingkan dengan yang standar.

Saya berharap bahwa dengan upaya bersama kita akan menemukan kemacetan CS dan jika kita berhasil mempercepatnya, maka saya pasti akan menambahkan informasi tentang hasil akhir di akhir posting.

UPD: Pedoman berikut ini diterapkan pada pengaturan CS:

disk_optimization_strategy: spinning
MAX_HEAP_SIZE = "32G"
HEAP_NEWSIZE = "3200M"
-Xms32G
-Xmx32G
-XX: + UseG1GC
-XX: G1RSetUpdatingPauseTimePercent = 5
-XX: MaxGCPauseMillis = 500
-XX: MemulaiHeapOccupancyPercent = 70
-XX: ParallelGCThreads = 32
-XX: ConcGCThreads = 8

Adapun pengaturan OS, ini adalah prosedur yang agak panjang dan rumit (mendapatkan root, me-reboot server, dll), jadi rekomendasi ini tidak diterapkan. Di sisi lain, kedua database berada dalam kondisi yang sama, jadi semuanya adil.

Di bagian kode, satu konektor dibuat untuk semua utas menulis ke tabel:

 connector = new CassandraConnector(); connector.connect(node, null, CL); session = connector.getSession(); session.getCluster().getConfiguration().getSocketOptions().setConnectTimeoutMillis(120000); KeyspaceRepository sr = new KeyspaceRepository(session); sr.useKeyspace(keyspace); prepared = session.prepare("insert into " + tableName + " (id, title) values (?, ?)"); 

Data dikirim melalui pengikatan:

 for (Long key = count * thNum; key < count * (thNum + 1); key++) { String value = RandomStringUtils.random(dataSize, true, true); session.execute(prepared.bind(key, value)); } 

Ini tidak memiliki dampak signifikan pada kinerja perekaman. Untuk keandalan, saya meluncurkan beban dengan alat YCSB, hasil yang benar-benar sama. Di bawah ini adalah statistik untuk satu utas (dari 4):

2020-01-18 14: 41: 53: 180 315 dt: 10.000.000 operasi; 21589.1 operasi saat ini / detik; [CLEANUP: Hitung = 100, Max = 2236415, Min = 1, Rata-rata = 22356,39, 90 = 4, 99 = 24, 99,9 = 2236415, 99,99 = 2236415] [INSERT: Hitung: 119551, Max = 174463, Min = 273, Rata-rata = 2582,71, 90 = 3491, 99 = 16767, 99,9 = 99711, 99,99 = 171263]
[KESELURUHAN], RunTime (ms), 315539
[KESELURUHAN], Throughput (ops / dtk), 31691.803548848162
[TOTAL_GCS_PS_Scavenge], Hitung, 161
[TOTAL_GC_TIME_PS_Scavenge], Waktu (ms), 2433
[TOTAL_GC_TIME _% _ PS_Scavenge], Waktu (%), 0.7710615803434757
[TOTAL_GCS_PS_MarkSweep], Hitung, 0
[TOTAL_GC_TIME_PS_MarkSweep], Waktu (ms), 0
[TOTAL_GC_TIME _% _ PS_MarkSweep], Waktu (%), 0,0
[TOTAL_GCs], Hitung, 161
[TOTAL_GC_TIME], Waktu (ms), 2433
[TOTAL_GC_TIME_%], Waktu (%), 0.7710615803434757
[INSERT], Operasional, 10.000.000
[INSERT], AverageLatency (us), 3114.2427012
[INSERT], MinLatency (kami), 269
[INSERT], MaxLatency (kami), 609279
[INSERT], 95thPercentileLatency (kami), 5007
[INSERT], 99thPercentileLatency (us), 33439
[INSERT], Return = OK, 10000000


Di sini Anda dapat melihat bahwa kecepatan satu aliran adalah sekitar 32 ribu catatan per detik, 4 aliran bekerja, ternyata 128 ribu. Tampaknya tidak ada lagi yang perlu diperas pada pengaturan saat ini dari subsistem disk.

Tentang membaca lebih menarik. Berkat saran rekan-rekannya, dia berhasil mempercepat secara radikal. Membaca dilakukan bukan di 5 aliran, tetapi di 100. Peningkatan ke 200 tidak menghasilkan efek. Juga ditambahkan ke pembangun:
.withLoadBalancingPolicy (TokenAwarePolicy baru (DCAwareRoundRobinPolicy.builder (). build ()))

Akibatnya, jika sebelumnya tes menunjukkan 159 644 ops (5 stream, 4 tables, 100 batch), sekarang:
100 utas, 4 tabel, kumpulan = 1 (satu per satu): 301 969 ops
100 utas, 4 tabel, kumpulan = 10: 447 608 ops
100 utas, 4 tabel, kumpulan = 100: 625 655 ops

Karena hasilnya lebih baik dengan batch, saya menjalankan tes * serupa dengan HB:

* Karena ketika bekerja di 400 utas, fungsi RandomStringUtils, yang digunakan sebelumnya, memuat CPU sebesar 100%, itu digantikan oleh generator yang lebih cepat.

Dengan demikian, peningkatan jumlah utas saat memuat data memberi sedikit peningkatan kinerja HB.

Sedangkan untuk membaca, berikut adalah hasil dari beberapa opsi. Atas permintaan 0x62ash , perintah flush dieksekusi sebelum membaca, dan beberapa opsi lain juga diberikan untuk perbandingan:
Memstore - membaca dari memori, mis. sebelum dibilas ke disk.
HFile + zip - membaca dari file yang dikompres oleh algoritma GZ.
HFile + upzip - baca dari file tanpa kompresi.

Fitur yang menarik patut diperhatikan - file kecil (lihat bidang "Data", tempat ditulisnya 10 byte) diproses lebih lambat, terutama jika dikompres. Jelas, ini hanya mungkin sampai ukuran tertentu, jelas file 5 GB tidak akan diproses lebih cepat dari 10 MB, tetapi jelas menunjukkan bahwa dalam semua tes ini masih belum ada bidang bajak untuk meneliti berbagai konfigurasi.

Untuk kepentingan, saya mengoreksi kode YCSB untuk bekerja dengan batch HB 100 buah untuk mengukur latensi dan banyak lagi. Di bawah ini adalah hasil karya 4 salinan yang menulis ke meja mereka, masing-masing dengan 100 utas. Ternyata yang berikut ini:


Ternyata jika CS AverageLatency (kami) memiliki catatan 3114, maka HB AverageLatency (kami) = 1162 (ingat bahwa 1 operasi = 100 catatan dan karenanya harus dibagi).

Secara umum, kesimpulan ini diperoleh - dalam kondisi tertentu, ada keuntungan yang signifikan dari HBase. Namun, tidak dapat disangkal bahwa SSD dan penyempurnaan OS yang hati-hati akan mengubah gambar secara radikal. Anda juga perlu memahami bahwa banyak tergantung pada skenario penggunaan, dapat dengan mudah berubah bahwa jika Anda mengambil bukan 4 tabel, tetapi 400 dan bekerja dengan terabyte, keseimbangan kekuatan akan berkembang dengan cara yang sama sekali berbeda. Seperti yang dikatakan orang klasik: praktik adalah kriteria kebenaran. Anda harus mencoba. Pertama, ScyllaDB sekarang masuk akal untuk diperiksa, jadi untuk dilanjutkan ...