MongoDB, Cassandra, dan HBase - tiga database NoSQL yang harus diperhatikan

Hadoop mendapatkan banyak kredit big data, tetapi kenyataannya adalah database NoSQL digunakan jauh lebih luas - dan dikembangkan jauh lebih luas. Faktanya, saat berbelanja vendor Hadoop relatif mudah, memilih database NoSQL sama sekali tidak. Bagaimanapun, ada lebih dari 100 database NoSQL, seperti yang ditunjukkan oleh peringkat popularitas database DB-Engines.

Mana yang harus Anda pilih?

Dimanjakan untuk pilihan

Karena memilih Anda harus. Betapa menyenangkan untuk hidup dalam utopia bahagia dari apa yang disebut persistensi poliglot, "di mana setiap perusahaan berukuran layak akan memiliki berbagai teknologi penyimpanan data yang berbeda untuk berbagai jenis data," seperti pendapat Martin Fowler, kenyataannya adalah Anda tidak bisa berinvestasi untuk mempelajari lebih dari beberapa.

Untungnya, pilihannya semakin mudah karena pasar menyatu di sekitar tiga database NoSQL yang dominan: MongoDB (didukung oleh perusahaan saya sebelumnya), Cassandra (terutama dikembangkan oleh DataStax, meskipun dibuat di Facebook), dan HBase (selaras dengan Hadoop dan dikembangkan oleh komunitas yang sama).

Perhatikan bahwa saya sengaja mengecualikan Redis dari daftar ini. Meskipun penyimpanan data yang bagus, ini terutama digunakan untuk menyimpan data dan tidak cocok untuk beragam beban kerja.

Data LinkedIn dari 451 Penelitian menunjukkan bagaimana pasar tertarik ke MongoDB, Cassandra, dan HBase:

Itulah data profil LinkedIn. Tampilan yang lebih lengkap adalah DB-Engines ', yang mengumpulkan pekerjaan, pencarian, dan data lain untuk memahami popularitas database. Sementara Oracle, SQL Server, dan MySQL berkuasa, MongoDB (no. 5), Cassandra (no. 9), dan HBase (no. 15) membuat mereka kabur.

Meskipun terlalu dini untuk menyebut setiap database NoSQL lainnya sebagai kesalahan pembulatan, kami dengan cepat mencapai titik itu, persis seperti yang terjadi di pasar database relasional.

Untuk lebih memahami mengapa ketiga database ini bersinar, saya meminta perwakilan dari masing-masing untuk mengidentifikasi atribut utama untuk kesuksesan mereka: Kelly Stirman, direktur produk di MongoDB; Patrick McFadin, kepala penginjil Cassandra di DataStax; dan Justin Kestelyn, direktur senior hubungan pengembang di Cloudera.

Tapi pertama-tama, kita perlu memahami mengapa NoSQL penting.

Dunia yang dibangun dengan data tidak terstruktur

Kita semakin hidup di dunia di mana data tidak cocok dengan baik ke dalam baris dan kolom yang rapi pada RDBMS. Komputasi seluler, sosial, dan cloud telah menghasilkan banyak sekali data. Menurut berbagai perkiraan, 90 persen data dunia dibuat dalam dua tahun terakhir, dengan Gartner menetapkan 80 persen dari semua data perusahaan sebagai tidak terstruktur. Terlebih lagi, data tidak terstruktur tumbuh dua kali lipat dari data terstruktur.

Seiring dunia berubah, persyaratan manajemen data melampaui cakupan efektif database relasional tradisional. Organisasi pertama yang mengamati kebutuhan akan solusi alternatif adalah pelopor Web, lembaga pemerintah, dan perusahaan yang berspesialisasi dalam layanan informasi.

Saat ini, perusahaan dari semua lapisan sedang mencari keuntungan dari alternatif seperti NoSQL dan Hadoop: NoSQL untuk membangun aplikasi operasional yang mendorong bisnis mereka melalui sistem keterlibatan, dan Hadoop untuk membangun aplikasi yang menganalisis data mereka secara retrospektif dan membantu memberikan wawasan yang kuat .

MongoDB: Dari para pengembang, untuk para pengembang

Di antara opsi NoSQL, MongoDB's Stirman menunjukkan, MongoDB bertujuan untuk pendekatan seimbang yang cocok untuk berbagai macam aplikasi. Meskipun fungsinya mirip dengan database relasional tradisional, MongoDB memungkinkan pengguna untuk memanfaatkan manfaat infrastruktur cloud dengan skalabilitas horizontal dan untuk dengan mudah bekerja dengan beragam kumpulan data yang digunakan saat ini berkat model datanya yang fleksibel.

MongoDB sering kali menjadi pengembang database NoSQL pertama yang mencoba karena sangat mudah dipelajari. Will Shulman, CEO MongoLab (penyedia layanan MongoDB-as-a-service), mengatakannya seperti ini:

Keberhasilan MongoDB yang tidak proporsional sebagian besar didasarkan pada inovasinya sebagai penyimpanan struktur data yang memungkinkan kami membuat model "hal-hal" di jantung aplikasi kami dengan lebih mudah dan ekspresif….

Memiliki model data dasar yang sama dalam kode dan database kami adalah metode unggulan untuk sebagian besar kasus penggunaan, karena secara dramatis menyederhanakan tugas pengembangan aplikasi, dan menghilangkan lapisan kode pemetaan kompleks yang sebaliknya diperlukan.

Khususnya, MongoDB, seperti database lain dalam daftar ini, bukanlah poni satu trik. Perusahaan yang mempelajari MongoDB “dapat mengamortisasi investasi mereka di MongoDB di banyak, banyak proyek, menjadikannya salah satu dari daftar pendek standar yang mereka andalkan untuk semua manajemen data,” seperti yang dikatakan Stirman kepada saya.

Tentu saja, seperti teknologi lainnya, MongoDB memiliki kekuatan dan kelemahannya sendiri. MongoDB dirancang untuk beban kerja OLTP. Ini bisa melakukan kueri kompleks, tetapi belum tentu paling sesuai untuk beban kerja gaya pelaporan. Atau jika Anda membutuhkan transaksi yang rumit, itu bukanlah pilihan yang baik. Namun, kesederhanaan MongoDB menjadikannya tempat yang tepat untuk memulai.

Cassandra: Aman dijalankan dalam skala besar

Setidaknya ada dua jenis kesederhanaan database: kesederhanaan pengembangan dan kesederhanaan operasional. Sementara MongoDB benar mendapatkan kredit untuk pengalaman out-of-the-box yang mudah, Cassandra mendapatkan nilai penuh karena mudah dikelola dalam skala besar.

Seperti yang dikatakan McFadin dari DataStax kepada saya, pengguna cenderung tertarik pada Cassandra semakin mereka membenturkan kepala terhadap kesulitan membuat database relasional lebih cepat dan lebih andal, terutama dalam skala. Mantan DBA Oracle, McFadin sangat gembira menemukan bahwa "replikasi dan penskalaan linier adalah primitif" dengan Cassandra, dan fiturnya adalah "tujuan desain utama sejak awal".

Di dunia RDBMS, fitur database seperti penskalaan dan replikasi adalah bagian tersulit yang diserahkan kepada pengguna. Ini bekerja dengan baik di perusahaan kemarin ketika skala bukanlah masalah besar. Hari itu cepat menjadi yang masalah.

Seperti yang saya dengar dari McFadin dan lainnya, Cassandra sangat menonjol dalam penerapan skala. Cassandra hadir dengan dukungan terintegrasi untuk beberapa pusat data. Untuk menambahkan kapasitas ke cluster, “Anda cukup mem-boot mesin baru dan memberi tahu Cassandra di mana node lainnya berada," kata McFadin, "dan sisanya akan ditangani.”

Kemudahan penskalaan ini, ditambah dengan kinerja tulis yang luar biasa (“Yang Anda lakukan hanyalah menambahkan ke akhir file log”) dan kinerja kueri yang dapat diprediksi, menambah tenaga kerja berkinerja tinggi di Cassandra.

Salah satu artikel kepercayaan NoSQL yang sudah lama saya pegang adalah bahwa Cassandra mungkin kuat dalam skala besar, tetapi membutuhkan gelar doktor untuk memulai. Tidak demikian, McFadin bersikeras:

Jalur replikasi dan baca dan tulis sengaja dibuat sederhana. Anda dapat mempelajari inti internal Cassandra dalam beberapa jam. Hal itu dapat membawa banyak kepercayaan saat Anda menerapkan teknologi baru karena lebih sedikit detail "kotak hitam" yang memperkenalkan mode kegagalan yang kompleks.

Ini berarti bahwa harga untuk masuk ke pengembangan Cassandra yang efektif adalah dalam memahami model data dan cara kerjanya dengan aplikasi Anda. Mengingat keakraban bahasa kueri CQL Cassandra (dimaksudkan untuk "persis seperti SQL kecuali jika tidak"), McFadin berkata, ini bukan kurva pembelajaran yang curam.

Lebih penting lagi, dia mengatakan kepada saya, “Cassandra menghadiahi Anda dengan satu hal yang Anda inginkan dari database: tidak ada drama. Inilah mengapa pengguna suka menggunakan Cassandra. ”

HBase: Teman dada dengan Hadoop

HBase, seperti Cassandra, penyimpan nilai-kunci yang berorientasi pada kolom, banyak digunakan karena kesamaan silsilahnya dengan Hadoop. Memang, seperti yang dikatakan oleh Kestelyn dari Cloudera, "HBase menyediakan lapisan penyimpanan berbasis catatan yang memungkinkan pembacaan dan penulisan data secara cepat dan acak, melengkapi Hadoop dengan menekankan throughput yang tinggi dengan mengorbankan I / O latensi rendah."

Kestelyn melanjutkan:

Perubahan secara efisien dikatalogkan dalam memori untuk mencapai akses maksimum sementara data disimpan ke HDFS. Desain ini memungkinkan EDH berbasis Hadoop [hub data perusahaan] untuk melayani pembacaan dan penulisan acak kepada pengguna dan aplikasi secara real time, namun tetap menikmati toleransi kesalahan dan ketahanan HDFS.

Afinitas dengan Hadoop bukanlah satu-satunya alasan HBase terus naik dalam peringkat popularitas database, meskipun itu mungkin sudah cukup. Mirip dengan Cassandra, akar HBase sebagai implementasi open source dari Bigtable Google diterjemahkan ke dalam database yang sangat skalabel berdasarkan desain.

Karena dapat memanfaatkan penyimpanan, memori, dan sumber daya CPU dari sejumlah server, serta memiliki fitur penskalaan seperti sharding otomatis, HBase dapat menskalakan tanpa batas karena tuntutan beban dan kinerja meningkat hanya dengan menambahkan node server. HBase dirancang dari awal untuk memberikan kinerja yang optimal ketika konsistensi sangat penting.

Tapi skala bukan hanya utilitas. Seperti yang dicatat Kestelyn, “Berkat integrasinya yang erat dengan ekosistem Hadoop lainnya, data sudah tersedia bagi pengguna dan aplikasi melalui kueri SQL (menggunakan Cloudera Impala, Apache Phoenix, atau Apache Hive) atau bahkan pencarian teks bebas segi (menggunakan Cloudera Search). ” Dengan demikian, HBase memberi pengembang cara untuk memanfaatkan keahlian yang ada dengan SQL sambil membangun basis data terdistribusi yang lebih modern.

Setiap database dilengkapi dengan kekuatan dan kekurangannya sendiri, tetapi masing-masing dari tiga yang diprofilkan di sini telah mengisi lubang besar di lanskap data besar. Meskipun ada kemungkinan bahwa database baru akan datang untuk mengklaim tempat di tiga teratas NoSQL (DynamoDB?), Kenyataannya adalah bahwa pengembang dan perusahaan yang mereka layani sudah melakukan standarisasi pada beberapa opsi kuat: MongoDB, Cassandra, dan HBase.

Sekarang VP seluler di Adobe, Matt Asay sebelumnya adalah wakil presiden komunitas di MongoDB, Inc. Dia adalah anggota dewan emeritus dari Open Source Initiative (OSI) dan memperoleh gelar doktor hukum di Stanford, di mana dia fokus pada open source dan lainnya masalah perizinan kekayaan intelektual, dan masternya dari University of Kent di Canterbury dan gelar sarjana dari Universitas Brigham Young. Asay adalah salah satu blogger pertama.

Forum Teknologi Baru menyediakan tempat untuk mengeksplorasi dan mendiskusikan teknologi perusahaan yang sedang berkembang secara mendalam dan luas. Pemilihannya subjektif, berdasarkan pilihan teknologi yang kami yakini penting dan paling menarik bagi pembaca. tidak menerima jaminan pemasaran untuk publikasi dan berhak untuk mengedit semua konten yang dikontribusikan. Kirim semua pertanyaan ke [email protected]