Panduan NoSQL untuk Pengembang

Jika Anda telah mengikuti tren dalam pengembangan backend dan Big Data, Anda mungkin telah memperhatikan kehebohan seputar database NoSQL dalam beberapa tahun terakhir. Beberapa orang terinspirasi oleh pendekatan database ini, sementara yang lain berpikir bahwa ada semacam trik tersembunyi di dalamnya: model data di dalamnya tidak sama dengan database relasional biasa, antarmuka pemrograman aplikasi tidak biasa, dan aplikasi seringkali tidak dapat dipahami. Pada artikel ini saya akan memberi tahu Anda mengapa mereka pertama kali dibuat, database NoSQL ini, masalah apa yang mereka pecahkan dan mengapa begitu banyak database berbeda tiba-tiba dibutuhkan. Jika Anda baru mengenal NoSQL, Anda mungkin tertarik pada bagian terakhir artikel ini, yang mencantumkan tipe database NoSQL yang menurut saya perlu ditelusuri terlebih dahulu untuk mendapatkan pemahaman menyeluruh tentang bidang tersebut.

Mengapa kita tiba-tiba membutuhkan database baru?

Anda mungkin bingung bertanya: apa yang salah dengan database relasional? Intinya adalah mereka telah bekerja dengan sangat baik selama bertahun-tahun, tetapi sekarang ada masalah yang tidak dapat mereka atasi lagi. Menurut beberapa prediksi, pada tahun 2018 umat manusia akan menghasilkan 50.000 gigabyte data per detik. Ini adalah jumlah data yang sangat besar! Penyimpanan dan penanganannya menimbulkan tantangan teknis yang serius. Yang lebih buruk lagi adalah volume ini terus bertambah. Ternyata, database relasional kurang cocok untuk menangani data dalam jumlah besar. Mereka dirancang untuk berjalan pada satu mesin, dan jika Anda ingin menangani lebih banyak permintaan, satu-satunya pilihan adalah membeli komputer dengan lebih banyak RAM dan prosesor yang lebih bertenaga. Sayangnya, jumlah kueri yang dapat ditangani oleh satu mesin terbatas, dan untuk pekerjaan terdistribusi di beberapa mesin, kita memerlukan teknologi database yang berbeda. Tentu saja, beberapa pembaca akan tertawa saat ini dan mengatakan bahwa ada dua metode umum dalam menggunakan banyak mesin dalam kasus database relasional: replikasi dan sharding. Itu benar, tapi metode ini tidak cukup untuk mengatasi tugas kita. Replikasi baca adalah teknik di mana setiap pembaruan database disebarkan ke mesin lain yang hanya dapat menangani permintaan baca. Dalam hal ini, semua perubahan dilakukan oleh satu server, yang disebut node master, sedangkan server lain, yang disebut replika baca, hanya memelihara salinan data. Pengguna dapat membaca dari mesin mana pun, tetapi mengubah data hanya melalui node master. Ini adalah metode yang nyaman dan sangat populer, tetapi hanya memungkinkan Anda memproses lebih banyak permintaan baca dan tidak menyelesaikan masalah pemrosesan volume data yang diperlukan dengan cara apa pun. Sharding adalah pendekatan populer lainnya yang menggunakan banyak contoh database relasional. Masing-masing menangani operasi tulis dan baca untuk sebagian data. Jika database menyimpan informasi tentang pelanggan, misalnya menggunakan sharding, satu mesin dapat menangani semua permintaan pelanggan yang namanya dimulai dengan A, mesin lain dapat menyimpan semua data untuk pelanggan yang namanya dimulai dengan B, dan seterusnya. Meskipun sharding memungkinkan Anda merekam lebih banyak data, mengelola database seperti itu adalah mimpi buruk: Anda harus menyelaraskan data di seluruh mesin dan menskalakan cluster di kedua arah sesuai kebutuhan. Meskipun secara teori terlihat sederhana, melakukannya dengan benar cukup menantang.

Bisakah database relasional ditingkatkan?

Saya pikir Anda sudah percaya bahwa database relasional bukanlah yang paling cocok untuk volume data yang dihasilkan di dunia modern. Meskipun demikian, Anda mungkin masih bertanya-tanya mengapa belum ada yang membuat database relasional yang "lebih baik" yang dapat berjalan secara efisien di banyak mesin. Tampaknya teknologi ini belum dikembangkan, dan database relasional terdistribusi akan segera muncul. Sayangnya, ini tidak akan terjadi. Ini secara matematis tidak mungkin, dan tidak ada yang bisa dilakukan untuk mengatasinya. Untuk memahami mengapa demikian, Anda perlu melihat apa yang disebut teorema CAP (alias teorema Brewer). Hal ini dibuktikan pada tahun 1999, dan dinyatakan bahwa database terdistribusi yang berjalan pada beberapa mesin dapat memiliki tiga properti berikut: Konsistensi - setiap operasi baca mengembalikan hasil operasi tulis terakhir yang sesuai. Jika sistem konsisten, setelah menulis data baru, tidak mungkin membaca data lama yang sudah tertimpa. Ketersediaan ( Ketersediaan ) - sistem terdistribusi dapat melayani permintaan masuk kapan saja dan mengembalikan respons bebas kesalahan. Toleransi partisi - database terus merespons permintaan baca dan tulis bahkan ketika beberapa servernya untuk sementara tidak dapat berkomunikasi satu sama lain. Kegagalan sementara ini disebut kegagalan konektivitas jaringan dan dapat disebabkan oleh berbagai faktor, mulai dari masalah fisik jaringan karena server yang lambat hingga kerusakan fisik pada peralatan jaringan. Semua properti ini tentunya berguna, dan kami sangat ingin database dapat menggabungkan semuanya. Tidak ada pengembang yang waras yang mau melepaskan, katakanlah, aksesibilitas tanpa mendapatkan imbalan apa pun. Sayangnya, teorema CAP juga menyatakan bahwa ketiga properti tidak mungkin dimiliki secara bersamaan. Menyadari hal ini mungkin tidak mudah, namun mungkin saja terjadi. Pertama, jika kita memerlukan database terdistribusi, database tersebut harus “toleran terhadap pemutusan hubungan”. Hal ini bahkan tidak dibahas. Pemutusan sambungan terjadi setiap saat dan database kami harus tetap berfungsi meskipun demikian. Sekarang mari kita pahami mengapa kita tidak dapat mencapai konsistensi dan ketersediaan. Bayangkan kita memiliki database sederhana yang berjalan di dua mesin: A dan B. Setiap pengguna dapat menulis ke salah satu mesin, setelah itu data disalin ke mesin lainnya. Sekarang bayangkan mesin-mesin ini untuk sementara tidak dapat berkomunikasi satu sama lain, dan mesin B tidak dapat mengirim data ke atau menerima data dari mesin A. Jika selama periode waktu ini mesin B menerima permintaan baca dari klien, ia memiliki dua opsi:

1. Dapatkan kembali data lokal Anda, meskipun itu bukan yang terbaru. Dalam hal ini, preferensi diberikan pada ketersediaan (untuk mengembalikan setidaknya beberapa data, bahkan data yang sudah ketinggalan zaman).
2. Kesalahan pengembalian. Dalam hal ini, konsistensi lebih diutamakan: klien tidak akan menerima data usang, tetapi tidak akan menerima data sama sekali.

Basis data relasional berusaha untuk mewujudkan sifat "konsistensi" dan "ketersediaan" secara bersamaan, dan oleh karena itu tidak dapat beroperasi dalam lingkungan terdistribusi. Mencoba menerapkan semua kemampuan database relasional dalam sistem terdistribusi akan menjadi tidak realistis atau tidak mungkin dilakukan . Di sisi lain, database NoSQL mengutamakan skalabilitas dan kinerja. Mereka biasanya tidak memiliki kemampuan “dasar” seperti koneksi dan transaksi, dan model datanya ternyata sangat berbeda, bahkan mungkin membatasi dalam beberapa hal. Semua ini memungkinkan untuk menyimpan volume data yang lebih besar dan memproses lebih banyak kueri dibandingkan sebelumnya.

Bagaimana database NoSQL menyeimbangkan konsistensi dan ketersediaan?

Tampaknya bagi Anda jika Anda memilih database NoSQL, Anda akan selalu menerima beberapa data usang atau kesalahan jika terjadi kegagalan. Dalam praktiknya, ketersediaan dan konsistensi bukanlah satu-satunya pilihan yang tersedia. Ada berbagai pilihan yang tersedia untuk Anda pilih. Basis data relasional tidak memiliki opsi ini, tetapi NoSQL memungkinkan Anda mengontrol eksekusi kueri dengan cara yang serupa. Dengan satu atau lain cara, mereka memungkinkan Anda menyetel dua parameter saat melakukan operasi tulis atau baca di database NoSQL: W - berapa banyak mesin di cluster yang harus mengonfirmasi penyimpanan data saat melakukan operasi tulis . Semakin besar jumlah mesin tempat Anda menulis data, semakin mudah untuk membaca data terbaru pada operasi pembacaan berikutnya, namun juga semakin lama waktu yang dibutuhkan. R – berapa banyak mesin yang datanya ingin Anda baca . Dalam sistem terdistribusi, pendistribusian data ke semua mesin dalam sebuah cluster dapat memakan waktu, sehingga beberapa server akan memiliki data terbaru sementara yang lain akan lambat. Semakin banyak jumlah mesin yang datanya dibaca, semakin tinggi kemungkinan membaca data saat ini. Mari kita lihat contoh praktisnya. Jika Anda memiliki lima komputer di cluster Anda dan Anda memutuskan untuk menulis data hanya ke satu dan kemudian membaca data dari satu komputer yang dipilih secara acak, maka ada kemungkinan 80% Anda akan membaca data basi. Di sisi lain, ini akan menggunakan sumber daya yang minimal. Jadi, jika data lama tidak masalah bagi Anda, itu bukanlah pilihan yang buruk. Dalam hal ini, parameter W dan R sama dengan 1. Di sisi lain, jika Anda menulis data ke kelima mesin dalam database NoSQL, Anda dapat membaca data dari mesin mana pun dan dijamin mendapatkan data terkini setiap saat. Melakukan operasi yang sama pada lebih banyak mesin akan memakan waktu lebih lama, namun jika data terkini penting bagi Anda, maka Anda dapat memilih opsi ini. Dalam hal ini, W = R = 5. Berapa jumlah minimum pembacaan dan penulisan yang diperlukan untuk konsistensi database? Berikut rumus sederhananya: R + W ≥ N + 1 , dimana N adalah jumlah mesin dalam cluster. Artinya dengan lima server, Anda dapat memilih R = 2 dan W = 4, atau R = 3 dan W = 3, atau R = 4 dan W = 2. Dalam hal ini, tidak masalah mesin mana yang menyimpan data. ditulis, pembacaan akan selalu dilakukan dari setidaknya satu mesin dengan data terkini. Basis data lain, seperti DynamoDB, memiliki batasan berbeda dan hanya mengizinkan penulisan yang konsisten. Setiap bagian data disimpan di tiga server, dan ketika ada data yang ditulis, data tersebut ditulis ke dua dari tiga mesin. Namun saat membaca data, Anda dapat memilih salah satu dari dua opsi:

1. Pembacaan yang sangat konsisten, di mana data dibaca dari dua dari tiga mesin dan selalu mengembalikan data yang ditulis terbaru.
2. Pembacaan yang akhirnya konsisten, di mana satu mesin dipilih secara acak untuk membaca data. Namun, tindakan ini mungkin mengembalikan data yang sudah usang untuk sementara.

Mengapa ada begitu banyak database NoSQL?

Jika Anda mengikuti berita terkini di bidang pengembangan perangkat lunak, Anda mungkin pernah mendengar tentang banyak database NoSQL yang berbeda, seperti MongoDB, DynamoDB, Cassandra, Redis dan banyak lainnya. Anda mungkin bertanya-tanya: mengapa kita memerlukan begitu banyak database NoSQL yang berbeda? Alasannya sederhana: database NoSQL yang berbeda dirancang untuk memecahkan masalah yang berbeda. Inilah sebabnya mengapa jumlah database yang bersaing begitu besar. Database NoSQL terbagi dalam empat kategori utama:

Basis data berorientasi dokumen

Basis data ini menyediakan kemampuan untuk menyimpan dokumen bertingkat yang kompleks, sedangkan sebagian besar basis data relasional hanya mendukung baris satu dimensi. Fitur ini dapat berguna dalam banyak kasus, misalnya ketika diperlukan untuk menyimpan informasi tentang pengguna dengan beberapa alamat dalam sistem. Saat menggunakan database berorientasi dokumen, dalam hal ini Anda cukup menyimpan objek kompleks yang menyertakan array alamat, sedangkan dalam database relasional Anda harus membuat dua tabel: satu untuk informasi pengguna dan satu lagi untuk alamat. Basis data berorientasi dokumen menjembatani kesenjangan antara model objek dan model data. Beberapa database relasional, seperti PostgreSQL, kini juga mendukung penyimpanan berorientasi dokumen, namun sebagian besar database relasional masih kekurangan kemampuan ini.

Basis Data Kunci/Nilai

Basis data kunci/nilai biasanya menerapkan model NoSQL yang paling sederhana. Pada dasarnya, mereka memberi Anda tabel hash terdistribusi , memungkinkan Anda menulis data ke kunci tertentu dan membacanya kembali menggunakannya. Basis data kunci/nilai sangat skalabel dan memiliki latensi yang jauh lebih rendah dibandingkan basis data lainnya.

Database Grafik

Banyak bidang studi, misalnya jaringan sosial atau informasi tentang film dan aktor, dapat direpresentasikan dalam bentuk grafik. Meskipun grafik dapat direpresentasikan menggunakan database relasional, hal ini sulit dan merepotkan. Jika Anda memerlukan data grafik, lebih baik menggunakan database grafik khusus, yang dapat menyimpan informasi tentang grafik dalam cluster terdistribusi dan memungkinkan penerapan algoritma pada grafik secara efisien.

Basis Data Kolom

Perbedaan utama antara database kolom dan jenis database lainnya adalah cara data disimpan di disk. Basis data relasional membuat file untuk setiap tabel dan menyimpan nilai untuk semua baris secara berurutan. Basis data kolom membuat file untuk setiap kolom di tabel Anda. Struktur ini memungkinkan Anda mengumpulkan data dan menjalankan kueri tertentu dengan lebih efisien, namun Anda harus memastikan bahwa data tersebut sesuai dengan batasan database tersebut.

Basis data mana yang harus Anda pilih?

Memilih database biasanya merupakan masalah yang membuat frustrasi, dan dengan begitu banyak pilihan yang tersedia, hal ini bisa tampak seperti tugas yang berat. Kabar baiknya adalah tidak perlu memilih satu saja. Daripada membuat satu aplikasi monolitik yang mengimplementasikan semua kemampuan dan memiliki akses ke semua data sistem, Anda dapat menggunakan pola modern lain yang disebut layanan mikro : memecah aplikasi menjadi serangkaian layanan independen. Setiap layanan memecahkan masalahnya sendiri, dan hanya menggunakan databasenya sendiri, yang paling sesuai untuk memecahkan masalah ini.

Bagaimana Anda bisa mempelajari semua ini?

Dengan begitu banyak database , mempelajari semuanya tampak seperti tugas yang mustahil. Kabar baik: Anda tidak perlu melakukan ini. Hanya ada beberapa tipe dasar database NoSQL, dan jika Anda memahami cara kerjanya, tipe lainnya akan lebih mudah dipahami. Selain itu, beberapa database NoSQL lebih sering digunakan dibandingkan yang lain, jadi sebaiknya fokuskan upaya Anda pada solusi yang paling populer. Berikut adalah daftar database NoSQL yang paling umum digunakan yang menurut saya harus Anda lihat:

1. MongoDB . Mungkin database NoSQL paling populer di pasaran. Jika perusahaan tidak menggunakan database relasional sebagai penyimpanan data utamanya, mungkin perusahaan tersebut menggunakan MongoDB. Ini adalah penyimpanan dokumen yang fleksibel dengan seperangkat alat yang bagus. Pada awal karirnya, MongoDB memiliki reputasi buruk karena kehilangan data dalam beberapa kasus , namun sejak itu stabilitas dan keandalannya telah meningkat pesat. Lihatlah kursus MongoDB ini jika Anda ingin mempelajari lebih lanjut.


2. DynamoDB . Jika Anda menggunakan Amazon Web Services (AWS), Anda sebaiknya mempelajari lebih lanjut tentang DynamoDB. Ini adalah database latensi rendah yang sangat andal, dapat diskalakan, dengan rangkaian fitur yang kaya dan integrasi dengan banyak layanan AWS lainnya. Bagian terbaiknya adalah Anda tidak perlu menerapkannya sendiri. Menyiapkan klaster DynamoDB yang dapat diskalakan dan dapat menangani ribuan kueri hanya dengan beberapa klik saja. Jika ini menarik minat Anda, Anda dapat melihat kursus ini .


3. Neo4j . Basis data grafik yang paling umum. Ini adalah solusi terukur dan stabil yang cocok bagi mereka yang ingin menggunakan model data grafik. Jika Anda ingin mempelajari lebih lanjut, mulailah dengan kursus ini .


4. ulang . Meskipun database lain yang dijelaskan di sini digunakan untuk menyimpan data aplikasi inti, Redis digunakan terutama untuk mengimplementasikan cache dan menyimpan data tambahan. Dalam banyak kasus, salah satu database yang disebutkan di atas digunakan bersama dengan Redis. Untuk mempelajari lebih lanjut, lihat kursus ini.

Pada tahun 2018 dengan NoSQL

Basis data NoSQL adalah bidang yang luas dan berkembang pesat. Mereka memungkinkan Anda untuk menyimpan dan memproses data dalam jumlah yang sebelumnya tidak terbayangkan, namun ada biayanya. Basis data ini tidak memiliki banyak fitur yang Anda kenal dalam basis data relasional, dan mungkin sulit untuk menyiapkan diri Anda untuk menggunakannya. Namun setelah Anda menguasainya, Anda dapat membuat database terdistribusi dan terukur yang dapat menangani permintaan baca dan tulis dalam jumlah yang sangat besar, yang bisa menjadi sangat penting karena volume data yang dihasilkan semakin besar. Asli: https://simpleprogrammer.com/guide-nosql-software-developers/