Pos blog ini dipublikasikan di Hortonworks.com sebelum merger dengan Cloudera. Beberapa tautan, sumber daya, atau referensi mungkin tidak lagi akurat.
Ringkasan
Karena semakin banyak beban kerja yang dibawa ke perangkat keras modern di cloud, penting bagi kami untuk memahami cara memilih database terbaik yang dapat memanfaatkan perangkat keras terbaik. Amazon telah memperkenalkan instans dengan SSD yang terpasang langsung (Solid state drive). Baik Apache HBase dan Apache Cassandra adalah basis data nilai kunci yang populer. Dalam tolok ukur ini, kami berharap dapat mempelajari lebih lanjut tentang bagaimana mereka memanfaatkan SSD yang terpasang langsung di lingkungan cloud.
Desain tolok ukur
Benchmark dirancang untuk menjalankan Apache HBase dan Apache Cassandra dalam lingkungan produksi yang optimal. Ini berarti menggunakan mesin yang disesuaikan untuk operasi io tinggi dengan SSD yang terpasang langsung. Kami telah menempatkan write-ahead-logs/commit log serta penyimpanan data pada SSD. Sebelumnya, banyak tolok ukur telah mengonfirmasi bahwa kedua solusi dapat diskalakan secara linier, sehingga uji penskalaan berada di luar cakupan tolok ukur ini.
Hasil
Analisis
Sepanjang tolok ukur kami, kami telah melihat HBase secara konsisten mengungguli Cassandra pada beban kerja yang berat untuk dibaca. Ini selaras dengan kasus penggunaan utama HBase seperti mesin pencari, aplikasi transaksi frekuensi tinggi, analisis data log, dan aplikasi perpesanan. HBase bersinar pada beban kerja di mana pemindaian tabel dua dimensi yang besar merupakan persyaratan. Di sisi lain, Cassandra bekerja dengan baik dalam menangani beban kerja yang berat dengan konsistensi. Oleh karena itu, ini lebih cocok untuk pengumpulan data analitik atau pengumpulan data sensor ketika konsistensi dari waktu ke waktu dapat diterima.
Salah satu faktor lain yang perlu dipertimbangkan ketika memilih solusi juga adalah apakah ada perangkat yang sesuai untuk menganalisis data. Dalam kasus HBase, yang dibangun di atas platform Apache Hadoop, HBase mendukung Map Reduce dan berbagai konektor ke solusi lain seperti Apache Hive dan Apache Spark untuk mengaktifkan kueri agregasi yang lebih besar dan analitik kompleks.
Pengaturan pengujian
Mesin:
Cluster uji terdiri dari 5 mesin. Detail mesin:
AWS I3.xlarge
GP2 60GB untuk menjalankan OS
Penyimpanan NVMe yang terpasang langsung, 0.95TB
4 vCPU, setiap vCPU (Virtual CPU) adalah hyper-thread perangkat keras pada prosesor Intel E5-2686 v4 (Broadwell) yang berjalan pada 2,3 GHz.
RAM 30.5GB
Untuk meminimalkan masalah tetangga yang berisik, kami menjalankan pengujian pada instans khusus AWS.
Perangkat lunak tolok ukur:
Kumpulan data uji:1 TB dihasilkan melalui YCSB
Rangkaian uji:https://github.com/brianfrankcooper/YCSB
Skrip pengujian: https://github.com/2bethere/hbase-cassandra-bench
Perangkat lunak dan lingkungan:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Untuk sepenuhnya menggunakan perangkat keras, kami telah mengubah Jumlah Penangan per RegionServer di HBase menjadi 120. Semua pengaturan lainnya dibiarkan sebagai default. Daftar lengkap konfigurasi tersedia di akhir posting ini.
Selama penerapan, kami juga mengikuti panduan pengoptimalan Cassandra yang diposting di sini:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
Klien YCSB terletak di masing-masing dari 5 node dan dijalankan secara bersamaan untuk menghasilkan beban. Selama pembuatan kumpulan data, kami telah menurunkan jumlah utas menjadi 40.
Metodologi pengujian
Kami memuat dataset dengan 40 thread untuk setiap beban kerja mengingat distribusi dataset berbeda untuk setiap benchmark. Setelah memuat, kami menunggu semua operasi pemadatan selesai sebelum memulai pengujian beban kerja. Setiap beban kerja dijalankan 3 kali dengan 5.000.000 operasi. Jumlah rata-rata diambil dari 3 tes untuk menghasilkan angka akhir.
Tentang YCSB
YCSB, atau Yahoo! Cloud Serving Benchmark adalah alat benchmark yang umum digunakan. Ini memberikan hasil komparatif di berbagai solusi. Kami telah menjalankan beban kerja default yang disediakan oleh YCSB.
Beban Kerja A:Perbarui berat
Contoh aplikasi:Penyimpanan sesi, merekam tindakan terbaru
Beban Kerja B:Kebanyakan membaca
Contoh aplikasi:Penandaan foto; menambahkan tag adalah pembaruan, tetapi sebagian besar operasi adalah membaca tag
Beban Kerja C:Hanya baca
Contoh aplikasi:cache profil pengguna, di mana profil dibuat di tempat lain (mis., Hadoop)
Beban Kerja D:Membaca beban kerja terbaru
Contoh aplikasi:Pembaruan status pengguna; orang ingin membaca info terbaru
Beban Kerja E:Rentang pendek
Contoh aplikasi:percakapan berulir, di mana setiap pemindaian adalah untuk posting di utas tertentu (diasumsikan dikelompokkan berdasarkan id utas)
Beban Kerja F:Beban kerja baca-ubah-tulis
Contoh aplikasi:database pengguna, di mana catatan pengguna dibaca dan dimodifikasi oleh pengguna atau untuk merekam aktivitas pengguna.
