Pelajari tentang keputusan desain di balik dukungan baru HBase untuk MOB.
Apache HBase adalah database nilai kunci yang terdistribusi, terukur, berkinerja, dan konsisten yang dapat menyimpan berbagai tipe data biner. Ini unggul dalam menyimpan banyak nilai yang relatif kecil (<10K), dan menyediakan baca dan tulis dengan latensi rendah.
Namun, ada permintaan yang meningkat untuk menyimpan dokumen, gambar, dan objek moderat (MOB) lainnya di HBase sambil mempertahankan latensi rendah untuk baca dan tulis. Salah satu kasus penggunaan tersebut adalah bank yang menyimpan dokumen pelanggan yang ditandatangani dan dipindai. Sebagai contoh lain, agen transportasi mungkin ingin menyimpan cuplikan lalu lintas dan mobil yang bergerak. MOB ini biasanya menulis sekali.
Sayangnya, performa dapat menurun dalam situasi di mana banyak nilai berukuran sedang (100K hingga 10MB) disimpan karena tekanan I/O yang terus meningkat yang disebabkan oleh pemadatan. Pertimbangkan kasus di mana 1TB foto dari kamera lalu lintas, masing-masing berukuran 1MB, disimpan ke dalam HBase setiap hari. Bagian dari file yang disimpan dipadatkan beberapa kali melalui pemadatan kecil dan akhirnya, data ditulis ulang oleh pemadatan besar. Seiring dengan akumulasi MOB ini, I/O yang dibuat oleh pemadatan akan memperlambat pemadatan, lebih lanjut memblokir pembilasan memstore, dan akhirnya memblokir pembaruan. Toko MOB besar akan sering memicu pemisahan wilayah, mengurangi ketersediaan wilayah yang terpengaruh.
Untuk mengatasi kelemahan ini, insinyur Cloudera dan Intel telah mengimplementasikan dukungan MOB di cabang HBase (hbase-11339:HBase MOB). Cabang ini akan digabungkan ke master di HBase 1.1 atau 1.2, dan juga sudah ada dan didukung di CDH 5.4.x.
Operasi pada MOB biasanya intensif menulis, dengan pembaruan atau penghapusan yang jarang dan pembacaan yang relatif jarang. MOB biasanya disimpan bersama dengan metadatanya. Metadata yang berkaitan dengan MOB dapat mencakup, misalnya, nomor mobil, kecepatan, dan warna. Metadata sangat kecil dibandingkan dengan MOB. Metadata biasanya diakses untuk analisis, sedangkan MOB biasanya diakses secara acak hanya jika diminta secara eksplisit dengan kunci baris.
Pengguna ingin membaca dan menulis MOB di HBase dengan latensi rendah di API yang sama, dan menginginkan konsistensi, keamanan, snapshot, dan replikasi HBase yang kuat antar cluster, dan seterusnya. Untuk memenuhi tujuan ini, MOB dipindahkan dari jalur I/O utama HBase dan ke jalur I/O baru.
Dalam postingan ini, Anda akan mempelajari tentang pendekatan desain ini, dan mengapa itu dipilih.
Pendekatan yang Mungkin
Ada beberapa kemungkinan pendekatan untuk masalah ini. Pendekatan pertama yang kami pertimbangkan adalah menyimpan MOB di HBase dengan kebijakan pemisahan dan pemadatan yang disetel—MaxFileSize yang diinginkan lebih besar akan mengurangi frekuensi pemisahan wilayah, dan pemadatan yang lebih sedikit atau tidak sama sekali dapat menghindari penalti amplifikasi tulis. Pendekatan itu akan meningkatkan latensi tulis dan throughput secara signifikan. Namun, seiring dengan bertambahnya jumlah file yang disimpan, akan ada terlalu banyak pembaca yang dibuka dalam satu toko, bahkan lebih dari yang diizinkan oleh OS. Akibatnya, banyak memori yang digunakan dan kinerja membaca akan menurun.
Pendekatan lain adalah dengan menggunakan model HBase + HDFS untuk menyimpan metadata dan MOB secara terpisah. Dalam model ini, satu file dihubungkan oleh entri di HBase. Ini adalah solusi klien, dan transaksi dikendalikan oleh klien—tidak ada memori sisi HBase yang dikonsumsi oleh MOB. Pendekatan ini akan bekerja untuk objek yang lebih besar dari 50MB, tetapi untuk MOB, banyak file kecil menyebabkan penggunaan HDFS tidak efisien karena ukuran blok default dalam HDFS adalah 128MB.
Sebagai contoh, katakanlah NameNode memiliki memori 48GB dan setiap file berukuran 100KB dengan tiga replika. Setiap file membutuhkan lebih dari 300 byte dalam memori, sehingga NameNode dengan memori 48 GB dapat menampung sekitar 160 juta file, yang akan membatasi kita untuk hanya menyimpan file MOB 16 TB secara total.
Sebagai peningkatan, kami dapat mengumpulkan file MOB kecil menjadi file yang lebih besar—yaitu, sebuah file dapat memiliki beberapa entri MOB—dan menyimpan offset dan panjangnya dalam tabel HBase untuk pembacaan cepat. Namun, menjaga konsistensi data dan mengelola MOB yang dihapus dan file MOB kecil dalam pemadatan itu sulit.
Selain itu, jika kami menggunakan pendekatan ini, kami harus mempertimbangkan kebijakan keamanan baru, kehilangan sifat atomisitas penulisan, dan berpotensi kehilangan cadangan dan pemulihan bencana yang disediakan oleh replikasi dan snapshot.
Desain HBase MOB
Pada akhirnya, karena sebagian besar kekhawatiran seputar penyimpanan MOB di HBase melibatkan I/O yang dibuat oleh pemadatan, kuncinya adalah memindahkan MOB dari pengelolaan oleh region normal untuk menghindari pemisahan dan pemadatan wilayah di sana.
Desain MOB HBase mirip dengan pendekatan HBase + HDFS karena kami menyimpan metadata dan MOB secara terpisah. Namun, perbedaannya terletak pada desain sisi server:memstore men-cache MOB sebelum di-flush ke disk, MOB ditulis ke dalam HFile yang disebut “MOB file” di setiap flush, dan setiap file MOB memiliki banyak entri alih-alih satu file dalam HDFS untuk setiap MOB. File MOB ini disimpan di wilayah khusus. Semua proses baca dan tulis dapat digunakan oleh HBase API saat ini.
Menulis dan Membaca
Setiap MOB memiliki ambang batas:jika panjang nilai sel lebih besar dari ambang ini, sel ini dianggap sebagai sel MOB.
Ketika sel MOB diperbarui di wilayah, mereka ditulis ke WAL dan memstore, seperti sel normal. Dalam pembilasan, MOB di-flush ke file MOB, dan metadata serta jalur file MOB di-flush untuk menyimpan file. Konsistensi data dan fitur replikasi HBase adalah bawaan dari desain ini.
Hasil edit MOB lebih besar dari biasanya. Dalam sinkronisasi, I/O yang sesuai juga lebih besar, yang dapat memperlambat operasi sinkronisasi WAL. Jika ada wilayah lain yang berbagi WAL yang sama, latensi tulis wilayah ini dapat terpengaruh. Namun, jika konsistensi dan non-volatilitas data diperlukan, WAL adalah suatu keharusan.
Sel diizinkan untuk berpindah antara file yang disimpan dan file MOB dalam pemadatan dengan mengubah ambang batas. Ambang batas default adalah 100KB.
Seperti diilustrasikan di bawah, sel yang berisi jalur file MOB disebut sel referensi . Tag disimpan di dalam sel, sehingga kami dapat terus mengandalkan mekanisme keamanan HBase.
Sel referensi memiliki tag referensi yang membedakannya dari sel normal. Tag referensi menyiratkan sel MOB dalam file MOB, dan dengan demikian diperlukan penyelesaian lebih lanjut dalam membaca.
Dalam membaca, pemindai toko membuka pemindai untuk memstore dan menyimpan file. Jika sel referensi terpenuhi, pemindai membaca jalur file dari nilai sel, dan mencari kunci baris yang sama dari file itu. Cache blok dapat diaktifkan untuk file MOB yang dipindai, yang dapat mempercepat pencarian.
Tidak perlu membuka pembaca untuk semua file MOB; hanya satu yang dibutuhkan saat dibutuhkan. Pembacaan acak ini tidak dipengaruhi oleh jumlah file MOB. Jadi, kita tidak perlu memadatkan file MOB berulang kali jika ukurannya cukup besar.
Nama file MOB dapat dibaca, dan terdiri dari tiga bagian:MD5 dari kunci mulai, tanggal sel terbaru dalam file MOB ini, dan UUID. Bagian pertama adalah kunci awal wilayah tempat file MOB ini dihapus. Biasanya, MOB memiliki TTL yang ditentukan pengguna, sehingga Anda dapat menemukan dan menghapus file MOB yang kedaluwarsa dengan membandingkan bagian kedua dengan TTL.
Snapshot
Agar lebih bersahabat dengan snapshot, file MOB disimpan di wilayah dummy khusus, di mana snapshot, ekspor/kloning tabel, dan arsip berfungsi seperti yang diharapkan.
Saat menyimpan snapshot ke tabel, seseorang membuat wilayah MOB di snapshot, dan menambahkan file MOB yang ada ke dalam manifes. Saat memulihkan snapshot, buat tautan file di wilayah MOB.
Pembersihan dan pemadatan
Ada dua situasi ketika file MOB harus dihapus:ketika file MOB kedaluwarsa, dan ketika file MOB terlalu kecil dan harus digabungkan menjadi yang lebih besar untuk meningkatkan efisiensi HDFS.
HBase MOB memiliki tugas di master:ia memindai file MOB, menemukan yang kedaluwarsa ditentukan oleh tanggal dalam nama file, dan menghapusnya. Dengan demikian, ruang disk diperoleh kembali secara berkala dengan menghapus file MOB yang kedaluwarsa.
File MOB mungkin relatif kecil dibandingkan dengan blok HDFS jika Anda menulis baris di mana hanya beberapa entri yang memenuhi syarat sebagai MOB; juga, mungkin ada sel yang dihapus. Anda perlu menghapus sel yang dihapus dan menggabungkan file kecil menjadi file yang lebih besar untuk meningkatkan pemanfaatan HDFS. Pemadatan MOB hanya memadatkan file kecil dan file besar tidak disentuh, yang menghindari pemadatan berulang ke file besar.
Beberapa hal lain yang perlu diingat:
- Ketahui sel mana yang dihapus. Dalam setiap pemadatan utama HBase, penanda penghapusan ditulis ke file del sebelum dihapus.
- Pada langkah pertama pemadatan MOB, file del ini digabungkan menjadi file yang lebih besar.
- Semua file MOB kecil dipilih. Jika jumlah file kecil sama dengan jumlah file MOB yang ada, pemadatan ini dianggap sebagai pemadatan besar dan disebut pemadatan ALL_FILES.
- File-file yang dipilih ini dipartisi dengan kunci mulai dan tanggal dalam nama file. File kecil di setiap partisi dipadatkan dengan file del sehingga sel yang dihapus dapat dihapus; sementara itu, HFile baru dengan sel referensi baru dihasilkan, compactor melakukan file MOB baru, dan kemudian memuat HFile ini secara massal ke HBase.
- Setelah pemadatan di semua partisi selesai, jika pemadatan ALL_FILES terlibat, file del diarsipkan.
Siklus hidup file MOB diilustrasikan di bawah ini. Pada dasarnya, mereka dibuat saat memstore di-flush, dan dihapus oleh HFileCleaner dari sistem file saat tidak dirujuk oleh snapshot atau kedaluwarsa dalam arsip.
Kesimpulan
Singkatnya, desain HBase MOB yang baru memindahkan MOB keluar dari jalur I/O utama HBase sambil mempertahankan sebagian besar fitur keamanan, pemadatan, dan pengambilan gambar. Ini memenuhi karakteristik operasi di MOB, membuat amplifikasi penulisan MOB lebih dapat diprediksi, dan menjaga latensi rendah dalam membaca dan menulis.
Jincheng Du adalah Software Engineer di Intel dan kontributor HBase.
Jon Hsieh adalah Software Engineer di Cloudera dan anggota HBase/PMC. Dia juga pendiri Apache Flume, dan pembuat Apache Sqoop.
