Panduan Definitif untuk Database NoSQL

Tidak ada keraguan bahwa cara aplikasi web menangani data telah berubah secara signifikan selama dekade terakhir. Lebih banyak data sedang dikumpulkan dan lebih banyak pengguna mengakses data ini secara bersamaan daripada sebelumnya. Ini berarti bahwa skalabilitas dan kinerja lebih merupakan tantangan daripada sebelumnya untuk database relasional yang berbasis skema dan oleh karena itu dapat lebih sulit untuk diukur.

Evolusi NoSQL

Masalah skalabilitas SQL diakui oleh perusahaan Web 2.0 dengan kebutuhan data dan infrastruktur yang besar dan terus berkembang, seperti Google, Amazon, dan Facebook. Mereka datang dengan solusi mereka sendiri untuk masalah tersebut – teknologi seperti BigTable, DynamoDB, dan Cassandra.

Minat yang berkembang ini menghasilkan sejumlah Sistem Manajemen Basis Data NoSQL (DBMS), dengan fokus pada kinerja, keandalan, dan konsistensi. Sejumlah struktur pengindeksan yang ada digunakan kembali dan diperbaiki dengan tujuan meningkatkan kinerja pencarian dan pembacaan.

Pertama, ada jenis basis data NoSQL berpemilik (sumber tertutup) yang dikembangkan oleh perusahaan besar untuk memenuhi kebutuhan spesifik mereka, seperti BigTable Google, yang diyakini sebagai sistem NoSQL pertama, dan DynamoDB Amazon.

Keberhasilan sistem berpemilik ini mengawali pengembangan sejumlah sistem basis data sumber terbuka dan berpemilik yang serupa, yang paling populer adalah Hypertable, Cassandra, MongoDB, DynamoDB, HBase, dan Redis.

Apa yang Membuat NoSQL Berbeda?

Satu perbedaan utama antara database NoSQL dan database relasional tradisional adalah fakta bahwa NoSQL adalah bentuk penyimpanan tidak terstruktur .

Ini berarti bahwa database NoSQL tidak memiliki struktur tabel tetap seperti yang ditemukan dalam database relasional.

Keuntungan dan Kerugian Database NoSQL

Keuntungan

Basis data NoSQL memiliki banyak keunggulan dibandingkan dengan basis data relasional tradisional.

Satu perbedaan utama yang mendasar adalah bahwa database NoSQL memiliki struktur yang sederhana dan fleksibel. Mereka bebas skema.

Tidak seperti database relasional, database NoSQL didasarkan pada pasangan nilai kunci.

Beberapa tipe penyimpanan database NoSQL termasuk penyimpanan kolom, penyimpanan dokumen, penyimpanan nilai kunci, penyimpanan grafik, penyimpanan objek, penyimpanan XML, dan mode penyimpanan data lainnya.

Biasanya, setiap nilai dalam database memiliki kunci. Beberapa penyimpanan basis data NoSQL juga memungkinkan pengembang untuk menyimpan objek berseri ke dalam basis data, bukan hanya nilai string sederhana.

Basis data NoSQL sumber terbuka tidak memerlukan biaya lisensi yang mahal dan dapat berjalan pada perangkat keras yang murah, menjadikan penerapannya hemat biaya.

Juga, ketika bekerja dengan database NoSQL, apakah mereka open-source atau berpemilik, ekspansi lebih mudah dan lebih murah daripada saat bekerja dengan database relasional. Ini karena dilakukan dengan menskalakan dan mendistribusikan beban secara horizontal di semua node, daripada jenis penskalaan vertikal yang biasanya dilakukan dengan sistem basis data relasional, yaitu mengganti host utama dengan yang lebih kuat.

Kekurangan

Tentu saja, database NoSQL tidak sempurna, dan tidak selalu merupakan pilihan yang tepat.

Untuk satu hal, sebagian besar database NoSQL tidak mendukung fitur keandalan yang secara native didukung oleh sistem database relasional. Fitur keandalan ini dapat diringkas sebagai atomisitas, konsistensi, isolasi, dan daya tahan. Ini juga berarti bahwa database NoSQL, yang tidak mendukung fitur tersebut, memperdagangkan konsistensi untuk kinerja dan skalabilitas.

Untuk mendukung fitur keandalan dan konsistensi, pengembang harus menerapkan kode kepemilikan mereka sendiri, yang menambah lebih banyak kerumitan pada sistem.

Ini mungkin membatasi jumlah aplikasi yang dapat mengandalkan database NoSQL untuk transaksi yang aman dan andal, seperti sistem perbankan.

Bentuk kerumitan lain yang ditemukan di sebagian besar basis data NoSQL termasuk ketidakcocokan dengan kueri SQL. Ini berarti bahwa bahasa kueri manual atau kepemilikan diperlukan, menambah lebih banyak waktu dan kerumitan.

NoSQL vs. Database Relasional

Tabel ini memberikan perbandingan fitur singkat antara NoSQL dan database relasional:

Perlu dicatat bahwa tabel tersebut menunjukkan perbandingan pada tingkat basis data , bukan berbagai sistem manajemen basis data yang menerapkan kedua model tersebut. Sistem ini menyediakan teknik kepemilikan mereka sendiri untuk mengatasi beberapa masalah dan kekurangan di kedua sistem, dan dalam beberapa kasus, secara signifikan meningkatkan kinerja dan keandalan.

Jenis Penyimpanan Data NoSQL

Toko Nilai Kunci

Dalam tipe penyimpanan Nilai Kunci, tabel hash digunakan di mana kunci unik menunjuk ke suatu item.

Kunci dapat diatur ke dalam kelompok kunci yang logis, hanya membutuhkan kunci untuk menjadi unik dalam kelompoknya sendiri. Hal ini memungkinkan untuk kunci identik dalam kelompok logis yang berbeda. Tabel berikut menunjukkan contoh penyimpanan nilai kunci, di mana kuncinya adalah nama kota, dan nilainya adalah alamat Universitas Ulster di kota itu.

Beberapa implementasi dari key value store menyediakan mekanisme caching, yang sangat meningkatkan kinerjanya.

Semua yang diperlukan untuk menangani item yang disimpan dalam database adalah kuncinya. Data disimpan dalam bentuk string, JSON, atau BLOB (Binary Large OBject).

Salah satu kelemahan terbesar dalam bentuk database ini adalah kurangnya konsistensi di tingkat database. Ini dapat ditambahkan oleh pengembang dengan kode mereka sendiri, tetapi seperti yang disebutkan sebelumnya, ini menambah lebih banyak upaya, kerumitan, dan waktu.

Basis data NoSQL paling terkenal yang dibangun di atas penyimpanan nilai kunci adalah DynamoDB Amazon.

Toko Dokumen

Penyimpanan dokumen mirip dengan penyimpanan nilai kunci karena tidak memiliki skema dan didasarkan pada model nilai kunci. Oleh karena itu, keduanya memiliki banyak kelebihan dan kekurangan yang sama. Keduanya tidak memiliki konsistensi pada tingkat basis data, yang membuat aplikasi menyediakan lebih banyak fitur keandalan dan konsistensi.

Namun, ada perbedaan utama di antara keduanya.

Di Toko Dokumen, nilai (dokumen) menyediakan pengkodean untuk data yang disimpan. Encoding tersebut dapat berupa XML, JSON, atau BSON (Binary encoded JSON).

Juga, query berdasarkan data dapat dilakukan.

Aplikasi database paling populer yang mengandalkan Document Store adalah MongoDB.

Toko kolom

Dalam database Column Store, data disimpan dalam kolom, bukan disimpan dalam baris seperti yang dilakukan di sebagian besar sistem manajemen database relasional.

Penyimpanan Kolom terdiri dari satu atau lebih Keluarga Kolom yang secara logis mengelompokkan kolom tertentu dalam database. Kunci digunakan untuk mengidentifikasi dan menunjuk ke sejumlah kolom dalam database, dengan atribut keyspace yang mendefinisikan ruang lingkup kunci ini. Setiap kolom berisi tupel nama dan nilai, diurutkan dan dipisahkan koma.

Toko Kolom memiliki akses baca/tulis yang cepat ke data yang disimpan. Di penyimpanan kolom, baris yang terkait dengan satu kolom disimpan sebagai entri disk tunggal. Ini membuat akses lebih cepat selama operasi baca/tulis.

Basis data paling populer yang menggunakan penyimpanan kolom termasuk BigTable Google, HBase, dan Cassandra.

Dasar Grafik

Dalam Graph Base NoSQL Database, struktur grafik terarah digunakan untuk merepresentasikan data. Graf terdiri dari edge dan node.

Secara formal, graf adalah representasi dari sekumpulan objek, di mana beberapa pasang objek dihubungkan oleh tautan. Objek yang saling berhubungan diwakili oleh abstraksi matematika, yang disebut simpul, dan tautan yang menghubungkan beberapa pasang simpul disebut tepi. Himpunan simpul dan sisi yang menghubungkannya disebut graf.

Ini menggambarkan struktur basis data grafik yang menggunakan tepi dan simpul untuk mewakili dan menyimpan data. Node ini diatur oleh beberapa hubungan satu sama lain, yang diwakili oleh tepi antara node. Baik node dan hubungan memiliki beberapa properti yang ditentukan.

Database grafik paling sering digunakan dalam aplikasi jejaring sosial. Database grafik memungkinkan pengembang untuk lebih fokus pada hubungan antar objek daripada pada objek itu sendiri. Dalam konteks ini, mereka memang memungkinkan lingkungan yang skalabel dan mudah digunakan.

Saat ini, InfoGrid dan InfiniteGraph adalah database grafik paling populer.

Sistem Manajemen Basis Data NoSQL

Untuk perbandingan singkat dari database, tabel berikut memberikan perbandingan singkat antara sistem manajemen database NoSQL yang berbeda.

MongoDB memiliki penyimpanan skema yang fleksibel, yang berarti objek yang disimpan tidak harus memiliki struktur atau bidang yang sama. MongoDB juga memiliki beberapa fitur pengoptimalan, yang mendistribusikan kumpulan data ke seluruh, menghasilkan peningkatan kinerja secara keseluruhan dan sistem yang lebih seimbang.

Sistem database NoSQL lainnya, seperti Apache CouchDB, juga merupakan database tipe penyimpanan dokumen, dan berbagi banyak fitur dengan MongoDB, dengan pengecualian bahwa database dapat diakses menggunakan RESTful API.

REST adalah gaya arsitektur yang terdiri dari sekumpulan batasan arsitektur terkoordinasi yang diterapkan pada komponen, konektor, dan elemen data, di dalam World Wide Web. Itu bergantung pada protokol komunikasi tanpa kewarganegaraan, client-server, cacheable (misalnya, protokol HTTP).

Aplikasi RESTful menggunakan permintaan HTTP untuk memposting, membaca data, dan menghapus data.

Sedangkan untuk basis data kolom, Hypertable adalah basis data NoSQL yang ditulis dalam C++ dan didasarkan pada BigTable Google.

Hypertable mendukung pendistribusian penyimpanan data di seluruh node untuk memaksimalkan skalabilitas, seperti MongoDB dan CouchDB.

Salah satu database NoSQL yang paling banyak digunakan adalah Cassandra, yang dikembangkan oleh Facebook.

Cassandra adalah database penyimpanan kolom yang mencakup banyak fitur yang ditujukan untuk keandalan dan toleransi kesalahan.

Daripada memberikan pandangan mendalam pada setiap DBMS NoSQL, Cassandra dan MongoDB, dua dari sistem manajemen database NoSQL yang paling banyak digunakan, akan dieksplorasi di subbagian berikutnya.

Cassandra

Cassandra adalah sistem manajemen basis data yang dikembangkan oleh Facebook.

Tujuan di balik Cassandra adalah untuk membuat DBMS yang tidak memiliki titik kegagalan tunggal dan menyediakan ketersediaan maksimum.

Cassandra sebagian besar merupakan database toko kolom. Beberapa penelitian menyebut Cassandra sebagai sistem hybrid, terinspirasi oleh BigTable Google, yang merupakan database penyimpanan kolom, dan DynamoDB Amazon, yang merupakan database nilai kunci.

Hal ini dicapai dengan menyediakan sistem nilai kunci, tetapi kunci di Cassandra menunjuk ke sekumpulan kelompok kolom, dengan mengandalkan sistem file terdistribusi BigTable Google dan fitur ketersediaan Dynamo (tabel hash terdistribusi).

Cassandra dirancang untuk menyimpan sejumlah besar data yang didistribusikan di berbagai node. Cassandra adalah DBMS yang dirancang untuk menangani sejumlah besar data, tersebar di banyak server, sambil menyediakan layanan yang sangat tersedia tanpa satu titik kegagalan, yang penting untuk layanan besar seperti Facebook.

Fitur utama Cassandra meliputi:

• Tidak ada satu titik kegagalan. Agar hal ini tercapai, Cassandra harus berjalan pada sekelompok node, bukan pada satu mesin. Itu tidak berarti bahwa data pada setiap cluster sama, tetapi perangkat lunak manajemennya. Ketika terjadi kegagalan pada salah satu node, data pada node tersebut tidak dapat diakses. Namun, node lain (dan data) akan tetap dapat diakses.
• Hashing Terdistribusi adalah skema yang menyediakan fungsionalitas tabel hash sedemikian rupa sehingga penambahan atau penghapusan satu slot tidak secara signifikan mengubah pemetaan kunci ke slot. Ini memberikan kemampuan untuk mendistribusikan beban ke server atau node sesuai dengan kapasitasnya, dan pada gilirannya, meminimalkan waktu henti.
• Antarmuka Klien yang relatif mudah digunakan . Cassandra menggunakan Apache Thrift untuk antarmuka kliennya. Apache Thrift menyediakan klien RPC lintas bahasa, tetapi sebagian besar pengembang lebih memilih alternatif sumber terbuka yang dibangun di atas Apple Thrift, seperti Hector.
• Fitur ketersediaan lainnya. Salah satu fitur Cassandra adalah replikasi data. Pada dasarnya, ini mencerminkan data ke node lain di cluster. Replikasi bisa acak, atau spesifik untuk memaksimalkan perlindungan data dengan menempatkannya di sebuah node di pusat data yang berbeda, misalnya. Fitur lain yang ditemukan di Cassandra adalah kebijakan partisi. Kebijakan partisi memutuskan di mana di simpul mana untuk menempatkan kunci. Ini juga bisa acak atau berurutan. Saat menggunakan kedua jenis kebijakan partisi, Cassandra dapat mencapai keseimbangan antara penyeimbangan beban dan pengoptimalan kinerja kueri.
• Konsistensi. Fitur seperti replikasi membuat konsistensi menjadi menantang. Hal ini disebabkan oleh fakta bahwa semua node harus up-to-date setiap saat dengan nilai terbaru, atau pada saat operasi baca dipicu. Namun, pada akhirnya, Cassandra mencoba menjaga keseimbangan antara tindakan replikasi dan tindakan baca/tulis dengan memberikan kemampuan penyesuaian ini kepada pengembang.
• Baca/Tulis Tindakan. Klien mengirimkan permintaan ke satu node Cassandra. Node, menurut kebijakan replikasi, menyimpan data ke cluster. Setiap node pertama-tama melakukan perubahan data di log komit, dan kemudian memperbarui struktur tabel dengan perubahan, keduanya dilakukan secara sinkron. Operasi baca juga sangat mirip, permintaan baca dikirim ke satu node, dan node tunggal itu yang menentukan node mana yang menyimpan data, sesuai dengan kebijakan partisi/penempatan.

MongoDB

MongoDB adalah database berorientasi dokumen bebas skema yang ditulis dalam C++. Basis data adalah berbasis penyimpanan dokumen, yang berarti menyimpan nilai (disebut sebagai dokumen) dalam bentuk data yang dikodekan.

Pilihan format yang disandikan dalam MongoDB adalah JSON. Ini sangat kuat, karena meskipun data disarangkan di dalam dokumen JSON, data tersebut akan tetap dapat dikueri dan diindeks .

Subbagian berikutnya menjelaskan beberapa fitur utama yang tersedia di MongoDB.

pecahan

Sharding adalah partisi dan distribusi data di beberapa mesin (node). Shard adalah kumpulan node MongoDB, berbeda dengan Cassandra di mana node didistribusikan secara simetris. Menggunakan pecahan juga berarti kemampuan untuk menskalakan secara horizontal di beberapa node. Jika ada aplikasi yang menggunakan server database tunggal, itu dapat dikonversi ke sharded cluster dengan sedikit perubahan pada kode aplikasi asli karena cara sharding dilakukan oleh MongoDB. oftware hampir sepenuhnya dipisahkan dari API publik yang diekspos ke sisi klien.

Bahasa Kueri Mongo

Seperti yang telah dibahas sebelumnya, MongoDB menggunakan RESTful API. Untuk mengambil dokumen tertentu dari koleksi db, dokumen kueri dibuat berisi bidang yang harus cocok dengan dokumen yang diinginkan.

tindakan

Di MongoDB, ada sekelompok server yang disebut router. Masing-masing bertindak sebagai server untuk satu atau lebih klien. Demikian pula, Cluster berisi sekelompok server yang disebut server konfigurasi. Masing-masing memegang salinan metadata yang menunjukkan pecahan mana yang berisi data apa. Tindakan membaca atau menulis dikirim dari klien ke salah satu server router di cluster, dan secara otomatis dirutekan oleh server tersebut ke pecahan yang sesuai yang berisi data dengan bantuan server konfigurasi.

Mirip dengan Cassandra, shard di MongoDB memiliki skema replikasi data, yang membuat kumpulan replika dari setiap shard yang menyimpan data yang sama persis. Ada dua jenis skema replika di MongoDB: replikasi Master-Slave dan replikasi Replica-Set. Replica-Set menyediakan lebih banyak otomatisasi dan penanganan yang lebih baik untuk kegagalan, sementara Master-Slave terkadang memerlukan intervensi administrator. Terlepas dari skema replikasi, kapan pun dalam satu set replika, hanya satu pecahan yang bertindak sebagai pecahan utama, semua pecahan replika lainnya adalah pecahan sekunder. Semua operasi tulis dan baca pergi ke shard utama, dan kemudian didistribusikan secara merata (jika diperlukan) ke shard sekunder lainnya di set.

Pada grafik di bawah, kita melihat arsitektur MongoDB yang dijelaskan di atas, menunjukkan server router berwarna hijau, server konfigurasi berwarna biru, dan shard yang berisi node MongoDB.

Perlu dicatat bahwa sharding (atau berbagi data antar shard) di MongoDB sepenuhnya otomatis, yang mengurangi tingkat kegagalan dan menjadikan MongoDB sistem manajemen basis data yang sangat skalabel.

Struktur Pengindeksan untuk Basis Data NoSQL

Pengindeksan adalah proses mengasosiasikan kunci dengan lokasi catatan data yang sesuai dalam DBMS. Ada banyak struktur data pengindeksan yang digunakan dalam database NoSQL. Bagian berikut akan membahas secara singkat beberapa metode yang lebih umum; yaitu, pengindeksan B-Tree, pengindeksan T-Tree, dan pengindeksan O2-Tree.

Pengindeksan B-Tree

B-Tree adalah salah satu struktur indeks yang paling umum di DBMS.

Dalam B-tree, node internal dapat memiliki sejumlah variabel node anak dalam beberapa rentang yang telah ditentukan.

Satu perbedaan utama dari struktur pohon lainnya, seperti AVL, adalah bahwa B-Tree memungkinkan node memiliki sejumlah variabel node anak, yang berarti lebih sedikit penyeimbangan pohon tetapi lebih banyak ruang yang terbuang.

B+-Tree adalah salah satu varian B-Trees yang paling populer. B+-Tree adalah peningkatan dari B-Tree yang mengharuskan semua kunci berada di daun.

Pengindeksan Pohon-T

Struktur data T-Trees dirancang dengan menggabungkan fitur dari AVL-Trees dan B-Trees.

AVL-Trees adalah jenis pohon pencarian biner self-balancing, sedangkan B-Trees tidak seimbang, dan setiap node dapat memiliki jumlah anak yang berbeda.

Dalam T-Tree, strukturnya sangat mirip dengan AVL-Tree dan B-Tree.

Setiap node menyimpan lebih dari satu tuple {key-value, pointer}. Juga, pencarian biner digunakan dalam kombinasi dengan node multi-tupel untuk menghasilkan penyimpanan dan kinerja yang lebih baik.

Sebuah T-Tree memiliki tiga jenis node: Sebuah T-Node yang memiliki anak kanan dan kiri, node daun tanpa anak, dan node setengah daun dengan hanya satu anak.

Dipercaya bahwa T-Trees memiliki kinerja keseluruhan yang lebih baik daripada AVL-Trees.

Pengindeksan Pohon O2

O2-Tree pada dasarnya merupakan perbaikan dari pohon Merah-Hitam, suatu bentuk pohon Binary-Search, di mana node daun berisi tupel {nilai kunci, pointer}.

O2-Tree diusulkan untuk meningkatkan kinerja metode pengindeksan saat ini. Sebuah O2-Pohon orde m (m 2), di mana m adalah derajat minimum pohon, memenuhi sifat-sifat berikut:

• Setiap simpul berwarna merah atau hitam. Akarnya berwarna hitam.
• Setiap simpul daun berwarna hitam dan terdiri dari blok atau halaman yang menyimpan pasangan “nilai kunci, penunjuk rekor”.
• Jika sebuah simpul berwarna merah, maka kedua anaknya berwarna hitam.
• Untuk setiap simpul internal, semua jalur sederhana dari simpul ke simpul daun turunan berisi jumlah simpul hitam yang sama. Setiap node internal memegang nilai kunci tunggal.
• Leaf-node adalah blok yang memiliki antara m/2⌉ dan m pasangan “nilai kunci, penunjuk rekor”.
• Jika sebuah pohon memiliki satu simpul, maka itu harus berupa daun, yang merupakan akar dari pohon, dan dapat memiliki antara 1 hingga m item data kunci.
• Node daun terhubung ganda dalam arah maju dan mundur.

Di sini, kita melihat perbandingan kinerja langsung antara O2-Tree, T-Tree, B+-Tree, AVL-Tree, dan Red-Black Tree:

Orde T-Tree, B+-Tree, dan O2-Tree yang digunakan adalah m = 512.

Waktu dicatat untuk operasi pencarian, penyisipan, dan penghapusan dengan rasio pembaruan yang bervariasi antara 0%-100% untuk indeks 50 juta catatan, dengan operasi yang menghasilkan penambahan 50 juta catatan lain ke indeks.

Jelas bahwa dengan rasio pembaruan 0-10%, B-Tree dan T-Tree berkinerja lebih baik daripada O2-Tree. Namun, dengan rasio pembaruan yang meningkat, indeks O2-Tree berkinerja jauh lebih baik daripada kebanyakan struktur data lainnya, dengan struktur B-Tree dan Red-Black Tree yang paling menderita.

Kasus untuk NoSQL?

Pengenalan singkat ke database NoSQL, menyoroti area utama di mana database relasional tradisional gagal, mengarah ke takeaway pertama:

Sementara database relasional menawarkan konsistensi, mereka tidak dioptimalkan untuk kinerja tinggi dalam aplikasi di mana data besar disimpan dan sering diproses.

Basis data NoSQL mendapatkan banyak popularitas karena kinerja tinggi, skalabilitas tinggi, dan kemudahan akses; namun, mereka masih kekurangan fitur yang memberikan konsistensi dan keandalan.

Untungnya, sejumlah DBMS NoSQL mengatasi tantangan ini dengan menawarkan fitur baru untuk meningkatkan skalabilitas dan keandalan.

Tidak semua sistem database NoSQL berkinerja lebih baik daripada database relasional.

MongoDB dan Cassandra memiliki kinerja yang serupa, dan dalam banyak kasus lebih baik daripada database relasional dalam operasi tulis dan hapus.

Tidak ada korelasi langsung antara tipe penyimpanan dan kinerja DBMS NoSQL. Implementasi NoSQL mengalami perubahan, sehingga kinerja dapat bervariasi.

Oleh karena itu, pengukuran kinerja di seluruh tipe basis data dalam studi yang berbeda harus selalu diperbarui dengan perangkat lunak basis data versi terbaru agar angka-angka tersebut akurat.

Meskipun saya tidak dapat memberikan keputusan yang pasti tentang kinerja, berikut adalah beberapa hal yang perlu diingat:

• Pengindeksan B-Tree dan T-Tree tradisional umumnya digunakan dalam database tradisional.
• Satu studi menawarkan perbaikan dan penyempurnaan dengan menggabungkan karakteristik struktur pengindeksan ganda untuk menghasilkan O2-Tree.
• O2-Tree mengungguli struktur lain di sebagian besar pengujian, terutama dengan kumpulan data yang sangat besar dan rasio pembaruan yang tinggi.
• Struktur B-Tree memberikan kinerja terburuk dari semua struktur pengindeksan yang tercakup dalam artikel ini.

Pekerjaan lebih lanjut dapat dan harus dilakukan untuk meningkatkan konsistensi DBMS NoSQL. Integrasi kedua sistem, NoSQL dan database relasional, adalah area untuk dieksplorasi lebih lanjut.

Terakhir, penting untuk dicatat bahwa NoSQL adalah tambahan yang bagus untuk standar database yang ada, tetapi dengan beberapa peringatan penting. NoSQL memperdagangkan fitur keandalan dan konsistensi untuk kinerja dan skalabilitas belaka. Ini menjadikannya solusi khusus, karena jumlah aplikasi yang dapat mengandalkan database NoSQL tetap terbatas.

Keuntungannya? Spesialisasi mungkin tidak menawarkan banyak fleksibilitas, tetapi bila Anda ingin menyelesaikan pekerjaan khusus secepat dan seefisien mungkin, Anda tidak memerlukan Pisau Tentara Swiss. Anda membutuhkan NoSQL.