Pada postingan hari ini mari kita bahas tentang Arsitektur HBase. Mari memoles dasar-dasar HBase sebelum kita mempelajari lebih dalam arsitektur HBase.
HBase - Dasar-dasar:
HBase adalah sumber terbuka, NoSQL, terdistribusi, non-relasional, berversi, multi-dimensi, penyimpanan berorientasi kolom yang telah dimodelkan setelah Google BigTable yang berjalan di atas HDFS. '' NoSQL ”adalah istilah luas yang berarti bahwa database bukanlah RDBMS yang mendukung SQL sebagai bahasa akses utamanya, tetapi ada banyak jenis database NoSQL dan Berkeley DB adalah contoh yang baik dari database NoSQL lokal, sedangkan HBase adalah sangat banyak database terdistribusi.
HBase menyediakan semua fitur Google BigTable. Ini dimulai sebagai proyek oleh Powerset untuk memproses sejumlah besar data untuk pencarian bahasa alami. Ini dikembangkan sebagai bagian dari proyek Hadoop Apache dan berjalan di atas HDFS (Hadoop Distributed File System). Ini menyediakan cara yang toleran terhadap kesalahan untuk menyimpan data jarang dalam jumlah besar. HBase sebenarnya lebih merupakan 'Penyimpanan Data' daripada 'Basis Data' karena tidak memiliki banyak fitur yang tersedia di RDBMS, seperti kolom yang diketik, indeks sekunder, pemicu, dan bahasa kueri tingkat lanjut, dll.
Dalam database Berorientasi Kolom, tabel data disimpan sebagai bagian dari kolom data dan bukan sebagai baris data. Model data database berorientasi kolom terdiri dari nama tabel, kunci baris, keluarga kolom, kolom, cap waktu. Saat membuat tabel di HBase, baris akan diidentifikasi secara unik dengan bantuan tombol baris dan cap waktu. Dalam model data ini keluarga kolom bersifat statis sedangkan kolom dinamis. Sekarang mari kita lihat Arsitektur HBase.
Kapan harus memilih HBase?
HBase adalah pilihan yang baik hanya jika ada ratusan juta atau milyaran baris. HBase juga dapat digunakan di beberapa tempat ketika mempertimbangkan untuk pindah dari RDBMS ke HBase sebagai desain ulang lengkap sebagai lawan dari sebuah port. Dengan kata lain, HBase tidak dioptimalkan untuk aplikasi transaksional klasik atau bahkan analitik relasional. Ini juga bukan pengganti lengkap untuk HDFS saat melakukan MapReduce batch besar. Lalu mengapa Anda harus memilih HBase ?? Jika aplikasi Anda memiliki skema variabel di mana setiap baris sedikit berbeda, maka Anda harus melihat HBase.
Arsitektur HBase:
Gambar berikut dengan jelas menjelaskan Arsitektur HBase.
Di HBase, ada tiga komponen utama: Master, server Wilayah dan penjaga kebun binatang . Komponen lainnya adalah Memstore, HFile dan WAL.
Karena HBase berjalan di atas HDFS, ia menggunakan arsitektur Master-Slave di mana HMaster akan menjadi node master dan Server Wilayah adalah node slave. Saat klien mengirim permintaan tulis, HMaster mendapatkan permintaan itu dan meneruskannya ke Server Wilayah masing-masing.
Server Wilayah:
Ini adalah sistem yang bertindak mirip dengan node data. Ketika Server Wilayah (RS) menerima permintaan tulis, itu mengarahkan permintaan ke Wilayah tertentu. Setiap Wilayah menyimpan sekumpulan baris. Data baris dapat dipisahkan dalam beberapa keluarga kolom (CFs). Data CF tertentu disimpan di HStore yang terdiri dari Memstore dan satu set HFiles.
Apa yang dilakukan Memstore?
Memstore melacak semua log untuk operasi baca dan tulis yang telah dilakukan dalam server wilayah tertentu. Dari sini kita dapat mengatakan bahwa bertindak mirip dengan node nama di Hadoop. Memstore adalah penyimpanan dalam memori, oleh karena itu Memstore menggunakan penyimpanan dalam memori dari setiap node data untuk menyimpan log. Saat ambang tertentu terpenuhi, data Memstore dipindahkan ke HFile.
Tujuan utama menggunakan Memstore adalah kebutuhan untuk menyimpan data di DFS yang diurutkan berdasarkan kunci baris. Karena HDFS dirancang untuk pembacaan / penulisan berurutan, tanpa modifikasi file yang diizinkan, HBase tidak dapat secara efisien menulis data ke disk saat sedang diterima: data tertulis tidak akan disortir (ketika input tidak diurutkan) yang berarti tidak dioptimalkan untuk masa depan pengambilan. Untuk mengatasi masalah ini, buffer HBase terakhir kali menerima data dalam memori (di Memstore), 'mengurutkan' sebelum dibilas, lalu menulis ke HDFS menggunakan penulisan berurutan cepat. Karenanya, HFile berisi daftar baris yang diurutkan.
Setiap kali pembilasan Memstore terjadi, satu HFile dibuat untuk setiap CF dan pembilasan yang sering dapat menghasilkan berton-ton HFile. Karena selama membaca HBase harus melihat banyak HFile, kecepatan baca bisa terganggu. Untuk mencegah membuka terlalu banyak HFile dan menghindari penurunan kinerja baca, proses pemadatan HFiles digunakan. HBase akan secara berkala (ketika ambang tertentu yang dapat dikonfigurasi terpenuhi) memadatkan beberapa HFile yang lebih kecil menjadi yang besar. Jelas, semakin banyak file yang dibuat oleh Memstore, semakin banyak pekerjaan (beban ekstra) untuk sistem. Selain itu, sementara proses pemadatan biasanya dilakukan secara paralel dengan melayani permintaan lain dan ketika HBase tidak dapat mengikuti HFile pemadatan (ya, ada ambang batas yang dikonfigurasi untuk itu juga), itu akan memblokir penulisan di RS lagi. Seperti yang telah kita diskusikan di atas, ini sangat tidak diinginkan.
Kami tidak dapat memastikan bahwa data akan tetap ada di seluruh Memstore. Asumsikan bahwa datanode tertentu sedang down. Kemudian data yang berada di memori node data tersebut akan hilang.
Untuk mengatasi masalah ini, ketika permintaan datang dari master, permintaan tersebut juga ditulis ke WAL. WAL tidak lain adalah Menulis Log Depan yang berada di HDFS, penyimpanan permanen. Sekarang kita dapat memastikan bahwa meskipun node data sedang down, data tidak akan hilang yaitu .e. kami memiliki salinan dari semua tindakan yang seharusnya Anda lakukan di WAL. Jika node data sudah habis maka akan melakukan semua aktivitas lagi. Setelah operasi selesai, semuanya dikeluarkan dari Memstore dan WAL dan ditulis dalam HFile untuk memastikan bahwa kita tidak kehabisan memori.
Mari kita ambil contoh sederhana yang ingin saya tambahkan baris 10 lalu permintaan tulis itu masuk, katanya memberikan semua meta data ke Memstore dan WAL. Setelah baris tertentu itu ditulis ke HFile, semua yang ada di Memstore dan WAL dihapus.
Penjaga kebun binatang:
HBase terintegrasi dengan penjaga Kebun Binatang. Saat saya memulai HBase, instance penjaga kebun binatang juga dimulai. Alasannya adalah bahwa penjaga Kebun Binatang membantu kami melacak semua server wilayah yang ada untuk HBase. Zoo keeper melacak berapa banyak server wilayah yang ada, server wilayah mana yang menahan dari node data mana ke node data mana. Ini melacak kumpulan data yang lebih kecil di mana Hadoop hilang. Ini mengurangi overhead di atas Hadoop yang melacak sebagian besar data Meta Anda. Karenanya HMaster mendapatkan detail server wilayah dengan benar-benar menghubungi penjaga Kebun Binatang.
Ada pertanyaan untuk kami? Sebutkan mereka di bagian komentar dan kami akan menghubungi Anda kembali.
Posting terkait:
apa arti append di java