Apa Itu NoSQL? Model Data, Perbedaan dengan SQL, dan Kapan Menggunakannya

Database NoSQL adalah keluarga database yang menggunakan model seperti dokumen, pasangan key-value, kolom lebar, dan graph daripada bergantung pada model tabel relasional. Pilih satu berdasarkan bentuk data Anda dan operasi yang dibutuhkan aplikasi Anda; label NoSQL saja tidak menjamin query lebih cepat atau desain lebih sederhana.

SQL (Structured Query Language) adalah bahasa untuk melakukan query dan manipulasi data, sementara NoSQL adalah kategori yang mencakup berbagai model. “Not Only SQL” adalah salah satu cara untuk menjelaskan namanya; ini tidak berarti setiap produk melarang SQL. AWS NoSQL overview menjelaskan berbagai model dan tujuan yang ada.

Empat model data utama NoSQL

Kategori-kategori ini menjelaskan bagaimana data direpresentasikan. Satu produk dapat mendukung beberapa model, dan produk dalam kategori yang sama dapat berbeda dalam kemampuan query dan operasi.

Basis data key-value

Model key-value mencari nilai menggunakan kunci seperti session:abc123. Pertimbangkan ini ketika akses dapat diprediksi, seperti mengambil sesi berdasarkan ID-nya. Mencari kondisi sembarang di dalam nilai memerlukan pemeriksaan fitur pengindeksan dan kueri dari produk tertentu.

Nilai tidak harus berupa string biasa. Redis mendukung hash, daftar, set, dan set terurut selain string, sebagaimana dijelaskan dalam referensi tipe data Redis. Untuk cache, tentukan juga tempat penyimpanan data acuan utama, waktu kedaluwarsa entri, dan tindakan ketika entri cache tidak ditemukan.

Basis data dokumen

Sebuah dokumen mengelompokkan bidang, array, dan objek bersarang dari suatu item. JSON (JavaScript Object Notation) adalah format teks untuk mengekspresikan struktur tersebut; MongoDB menyimpan dokumen menggunakan BSON (Binary JSON). Pertimbangkan dokumen untuk item dengan atribut yang berbeda atau untuk data yang biasanya dibaca bersama di satu layar.

Pilih antara menyematkan informasi terkait dalam sebuah dokumen dan merujuk ke identifier dokumen lain sesuai dengan frekuensi akses, ukuran, dan pembaruan. Menyalin alamat ke setiap pesanan dapat mempermudah pembacaan, tetapi Anda harus memutuskan apa arti salinan tersebut dan bagaimana itu dipelihara. Panduan pemodelan MongoDB merekomendasikan untuk merancang berdasarkan pola akses.

Basis data kolom-lebar

Model kolom-lebar mengatur data berdasarkan kunci baris atau partisi dan kolom. Bigtable menggunakan peta yang diurutkan berdasarkan kunci baris dan mengelompokkan kolom terkait ke dalam keluarga kolom. Dokumentasi model penyimpanan-nya menjelaskan baris, kolom, dan keluarga.

Penyimpanan wide-column tidak sama dengan penyimpanan kolumnar untuk analisis yang mengelompokkan nilai dalam satu kolom. Cassandra memerlukan desain tabel dan partisi yang berorientasi pada kueri, serta tidak mendukung join relasional. Pengantar pemodelan data Cassandra menjelaskan mengapa pertanyaan seperti “membaca catatan perangkat ini untuk periode tertentu” perlu ditentukan terlebih dahulu. Periksa apakah kandidat mendukung kueri rentang dan agregasi yang diperlukan.

Basis data graf

Sebuah graf mewakili entitas, seperti orang, produk, atau server, sebagai node dan koneksi mereka sebagai edge. Pertimbangkan ini untuk pertanyaan yang mengikuti hubungan, seperti mengidentifikasi layanan yang terkena dampak oleh kegagalan server.

Graf juga dapat menyimpan atribut. Model graf properti Neo4j memungkinkan properti pada node dan hubungan, seperti yang dijelaskan dalam panduan konsep graf Neo4j. Model graf tidak membuat setiap kueri menjadi cepat; tentukan kedalaman traversal, jenis hubungan, dan kondisi jalur.

Bagaimana NoSQL berbeda dari basis data relasional?

Sistem manajemen basis data relasional (RDBMS) mengatur data menggunakan tabel, kunci, dan batasan. Ini memberikan dasar yang berguna untuk menghubungkan catatan yang terkait dan menerapkan aturan bersama. Produk NoSQL menawarkan operasi yang sesuai dengan modelnya, jadi bandingkan bagaimana setiap kandidat menjawab pertanyaan aplikasi Anda daripada menyalin skema yang sudah ada secara tidak berubah.

Menyimpan JSON tidak secara otomatis memerlukan NoSQL. PostgreSQL, misalnya, menawarkan tipe JSON dan pengindeksan untuk jsonb; lihat dokumentasi tipe JSON-nya. Menjaga aturan relasional dan transaksi sambil menggunakan atribut fleksibel untuk sebagian data juga merupakan desain yang dapat dipertimbangkan.

Skema yang fleksibel masih perlu dirancang

Sebuah skema mendefinisikan struktur dan aturan, seperti nama field, tipe, dan nilai yang diperlukan. Meskipun dokumen mungkin memiliki field yang berbeda, sebuah aplikasi memerlukan data yang dapat diprediksi. Katalog JSON fiksi ini menggambarkan dua produk dengan atribut yang berbeda:

[
  {
    "product_id": "book-101",
    "name": "Database Basics",
    "price_krw": 24000,
    "attributes": {
      "author": "Mina Kim",
      "pages": 320
    }
  },
  {
    "product_id": "headphones-201",
    "name": "Wireless Headphones",
    "price_krw": 79000,
    "attributes": {
      "wireless": true,
      "battery_hours": 30
    }
  }
]

Kedua produk berbagi product_id, name, dan price_krw, tetapi attributes yang bertingkat berbeda. Struktur dokumen mengekspresikan variasi tersebut secara alami. Menggabungkan angka dan string dalam field harga yang sama, bagaimanapun, dapat mempersulit pengurutan dan perhitungan, jadi tentukan tipe yang diperbolehkan dan penanganan nilai yang hilang.

MongoDB mendukung aturan validasi untuk tipe dan rentang nilai; dokumentasi validasi-skema menjelaskan cara menerapkan aturan di mana diperlukan. Sebaliknya, CQL (Cassandra Query Language) dari Cassandra mendefinisikan kolom dan tipe saat sebuah tabel dibuat, seperti yang ditunjukkan dalam referensi definisi-tabel. Oleh karena itu, pernyataan “Setiap database NoSQL tidak memiliki skema” tidak akurat.

JSON menggambarkan sebuah struktur; itu bukan data yang tidak terstruktur secara inheren. Secara terpisah tentukan apakah gambar dan video sebaiknya berada di dalam basis data atau di penyimpanan objek dengan lokasi dan metadata mereka di dalam basis data. Ukuran file, kebutuhan pengiriman, dan kebutuhan manajemen memengaruhi pilihan tersebut.

Periksa jaminan transaksi dan konsistensi per produk

Dukungan dan ruang lingkup transaksi

Sebuah transaksi memperlakukan perubahan sebagai satu kesatuan pekerjaan. ACID berarti Atomisitas, Konsistensi, Isolasi, dan Ketahanan. Untuk perubahan yang harus berhasil atau gagal secara bersamaan, seperti membuat pesanan dan mengurangi inventaris, tetapkan jaminan yang diperlukan terlebih dahulu.

NoSQL tidak berarti tidak ada transaksi. MongoDB mendukung transaksi multi-dokumen pada replica set dan klaster yang dibagi, dengan jaminan yang dipengaruhi oleh pengaturan penyebaran dan baca/tulis; lihat dokumentasi transaksi-nya. DynamoDB juga menyediakan API (Application Programming Interfaces) transaksi, namun memiliki batasan termasuk target yang didukung dan ruang lingkup Wilayah. referensi transaksi-nya menjelaskan batasan ini.

Apa yang bisa dikembalikan oleh pembacaan tepat setelah penulisan?

Perilaku replikasi juga penting. Dengan pembacaan yang konsisten pada akhirnya, penulisan yang baru saja diselesaikan mungkin belum muncul dalam hasil pembacaan. Tentukan persyaratan berdasarkan tindakan pengguna: apakah sebuah pesanan dapat sementara tidak terlihat segera setelah pengguna menyimpannya?

Tabel DynamoDB dan indeks sekunder lokal dapat menggunakan pembacaan yang konsisten kuat, sementara pembacaan dari indeks sekunder global dan aliran adalah konsisten pada akhirnya. Lihat dokumentasi konsistensi pembacaan DynamoDB untuk perbedaan berdasarkan target kueri. Konsistensi ACID dalam sebuah transaksi dan konsistensi pembacaan di seluruh replika adalah perhatian yang berbeda.

Skalabilitas horizontal tidak menjamin kinerja

Skalabilitas horizontal menambahkan server alih-alih mengganti satu server dengan mesin yang lebih besar. Sharding mendistribusikan data ke berbagai server; replikasi menjaga salinan. Memiliki beberapa server saja tidak menjamin data seimbang atau kueri lebih cepat. Ikhtisar sharding MongoDB menjelaskan konfigurasi terdistribusi secara terpisah.

Kunci yang didistribusikan dengan buruk dapat memusatkan permintaan pada partisi yang padat. Misalnya, mengelompokkan setiap peristiwa di bawah satu kunci tetap dapat menghambat distribusi beban. Pertimbangkan pola akses dan distribusi kunci secara bersamaan, seperti yang dijelaskan dalam Panduan kunci partisi DynamoDB.

Kinerja tergantung pada ukuran data, indeks, rentang kueri, campuran baca/tulis, pengaturan konsistensi, dan beban kerja. Bandingkan latensi permintaan lambat, kegagalan, dan perilaku pemulihan bersamaan dengan waktu respons rata-rata. Sertakan replika, cadangan, jaringan, dan pekerjaan operasional dalam penilaian biaya; kategori NoSQL saja tidak menetapkan biaya yang lebih rendah.

Kapan Anda harus mempertimbangkan NoSQL?

• Cache dengan kunci diketahui atau akses sesi: pertimbangkan penyimpanan key-value sambil menentukan masa berlaku, ketahanan, dan sinkronisasi dengan data acuan utama.
• Item katalog dengan atribut yang bervariasi: pertimbangkan dokumen sambil merancang validasi bidang bersama dan indeks pencarian.
• Peristiwa yang diquery berdasarkan kunci dan periode yang diketahui: pertimbangkan penyimpanan kolom-lebar saat memeriksa ukuran partisi dan query rentang.
• Penjelajahan hubungan multi-langkah: pertimbangkan graf saat mendefinisikan jenis koneksi dan kedalaman penjelajahan.

Saat laporan yang bervariasi menggabungkan beberapa tabel atau batasan lintas-record memerlukan penegakan terpusat, database relasional pantas untuk perbandingan awal. Jangan memutuskan hanya dari label industri atau volume data: periksa bagaimana pembacaan dan pembaruan yang paling penting akan bekerja di setiap kandidat.

Anda dapat menetapkan peran berbeda untuk sistem penyimpanan yang berbeda, seperti menggunakan basis data relasional sebagai sumber data utama dan penyimpanan key-value sebagai cache. Sistem penyimpanan tambahan juga membuat pembaruan salinan, penyebaran penghapusan, dan pemulihan lebih kompleks, jadi tambahkan mereka hanya untuk kebutuhan yang telah terbukti.

Sebuah urutan evaluasi praktis

1. Tulis kueri penting. Tentukan filter dan pengurutan untuk tugas-tugas seperti pencarian produk berdasarkan ID, pesanan pengguna terbaru, atau catatan harian sebuah perangkat.
2. Tentukan persyaratan ketepatan. Catat perubahan yang harus berhasil bersama, penanganan permintaan duplikat, pembacaan segera, dan nilai usang yang dapat diterima.
3. Rancang model kandidat yang sebenarnya. Periksa ukuran dokumen, embedding atau referensi, indeks, kunci partisi, dan jalur kueri seiring pertumbuhan data.
4. Bandingkan implementasi kecil. Gunakan data dan operasi yang sama untuk mereproduksi beban normal, beban terkonsentrasi, dan kegagalan; catat versi produk dan pengaturannya.
5. Rencanakan operasi dan migrasi. Periksa izin, pencadangan dan pemulihan, pemantauan, migrasi, perkiraan biaya, dan rute kembali ke penyimpanan yang ada jika diperlukan.

Mulailah dengan kueri dan persyaratan ketepatan, kemudian pilih model dan produk yang memenuhinya. Jika basis data yang sudah Anda gunakan memenuhi persyaratan tersebut, tentukan alasan untuk menambahkan jenis penyimpanan lain sebelum memperkenalkannya.