SQL vs NoSQL

Topik ini membahas kerangka keputusan untuk memilih keluarga basis data yang sesuai dengan kebutuhan aplikasi. Pembahasan mencakup empat keluarga basis data yang paling sering ditemui pada desain sistem, tabel keputusan yang memetakan kebutuhan ke pilihan yang wajar, serta satu model data yang sama dalam bentuk relasional dan dokumen. Setelah membaca topik ini, pemilihan basis data dapat dilandasi kapabilitas yang benar-benar dijamin oleh tiap keluarga, bukan oleh popularitas sesaat.

Empat keluarga basis data#

Basis data relasional menyimpan data dalam tabel berbaris dan berkolom dengan skema yang dideklarasikan terlebih dahulu. Hubungan antartabel dijaga dengan kunci asing (foreign key), sedangkan data diambil dengan query, yaitu pernyataan untuk mengambil atau mengubah data. Basis data keluarga ini, misalnya PostgreSQL dan MySQL, mengjamin properti ACID (atomicity, consistency, isolation, durability) pada transaksinya, sehingga operasi seperti pemindahan saldo antarrekening tidak meninggalkan data setengah selesai.

Basis data dokumen menyimpan data sebagai dokumen semacam JSON. Bentuknya lentur karena dokumen dalam satu koleksi tidak wajib memiliki kolom yang sama, dan satu entitas sering dapat dibaca dari satu dokumen tanpa join, yakni penggabungan baris dari beberapa tabel saat data diambil. Basis data key-value menyimpan pasangan kunci dan nilai tanpa struktur di dalam nilainya, sehingga pencarian satu kunci sangat cepat. Keluarga ini cocok untuk session serta cache, yaitu penyimpanan sementara yang lebih cepat daripada sumber aslinya. Basis data wide-column menyimpan baris lebar dengan kolom yang jarang diisi dan dirancang untuk throughput yang tinggi, yaitu banyaknya operasi per satuan waktu, pada data berukuran sangat besar.

Tiga keluarga terakhir beserta ragam lainnya lazim disebut NoSQL, yaitu istilah payung untuk basis data yang tidak mengikuti model relasional klasik. Tabel berikut merangkum kekuatan inti dan batasan inti keempat keluarga tersebut. Batasan yang disebut bukan kelemahan permanen, melainkan kemampuan yang tidak dijamin secara default sehingga menuntut upaya tambahan bila dibutuhkan.

Kerangka keputusan#

Pemilihan keluarga basis data diturunkan dari dua pertanyaan, yaitu bagaimana data diakses dan jaminan apa yang tidak boleh dilanggar. Aplikasi dengan transaksi lintas entitas, misalnya pemindahan saldo atau pemesanan tempat duduk, membutuhkan jaminan ACID bawaan basis data relasional. Aplikasi dengan atribut entitas yang bervariasi, misalnya halaman detail arsip berkas dengan metadata yang berbeda-beda, cocok dengan model dokumen karena seluruh atribut dapat disalin ke satu dokumen. Kebutuhan penyimpanan sementara berumur pendek, misalnya session dan cache hasil query, paling murah dijawab dengan key-value, sedangkan arsip log sensor dengan jutaan tulisan per hari sesuai dengan wide-column.

Tabel keputusan berikut memetakan kebutuhan yang sering muncul ke pilihan yang wajar. Pemetaannya berlaku sebagai titik awal, dan keputusan akhir tetap disesuaikan dengan alat yang tersedia di tim masing-masing.

Satu aplikasi juga tidak terikat pada satu keluarga. Pola yang lazim pada desain modern adalah mengombinasikan basis data relasional sebagai sumber kebenaran transaksional dengan basis data key-value sebagai lapisan cache yang menyerap pembacaan berulang. Kombinasi semacam ini berhasil justru karena tiap keluarga dipakai pada pekerjaan yang paling sesuai dengannya.

Satu model data dalam dua bentuk#

Kapabilitas tiap keluarga paling mudah dibandingkan pada satu model data yang sama. Misalkan aplikasi catatan menyimpan pengguna beserta catatan pribadinya. Bentuk relasionalnya memisahkan kedua entitas ke dua tabel, dan tiap tabel menetapkan primary key, yaitu kolom yang menandai setiap baris secara unik.

-- tidak-dijalankan
-- Skema relasional untuk aplikasi catatan beserta contoh querynya.
CREATE TABLE pengguna (
    id    INTEGER PRIMARY KEY,
    nama  VARCHAR(100) NOT NULL,
    email VARCHAR(200) NOT NULL UNIQUE
);

CREATE TABLE catatan (
    id          INTEGER PRIMARY KEY,
    id_pengguna INTEGER NOT NULL REFERENCES pengguna(id),
    isi         TEXT NOT NULL,
    dibuat_pada TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Join menggabungkan isi catatan dengan nama pemiliknya saat dibaca.
SELECT pengguna.nama, catatan.isi
FROM catatan
JOIN pengguna ON pengguna.id = catatan.id_pengguna
WHERE pengguna.id = 1024;

Bentuk relasional menempatkan setiap fakta pada satu tempat, sehingga perubahan nama pengguna cukup dilakukan pada satu baris. Harganya dibayar pada waktu baca, yaitu nama pemilik harus digabungkan kembali dengan join setiap kali daftar catatan ditampilkan.

Bentuk dokumen dari data yang sama menanamkan catatan ke dalam dokumen pengguna.

{
  "_id": "u-1024",
  "nama": "Budi",
  "email": "[email protected]",
  "catatan": [
    {
      "isi": "Daftar belanja: kopi, gula, beras",
      "dibuat_pada": "2026-11-07T08:30:00Z"
    }
  ]
}

Seluruh halaman profil kini dapat dibaca dalam satu query tanpa join, sehingga waktu baca menjadi lebih pendek dan dapat diprediksi. Harganya dibayar pada waktu tulis, yaitu perubahan yang menyangkut banyak entitas harus disalin ke masing-masing dokumen yang memuatnya. Prinsipnya sederhana, yaitu data yang selalu diakses bersama disimpan bersama, sedangkan data yang diakses terpisah tetap dirujuk dengan pengenal. Catatan yang selalu dibuka bersama profil pemiliknya cocok ditanamkan, sedangkan catatan yang dibuka terpisah dari profilnya lebih baik menjadi koleksi tersendiri dengan pengenal pemiliknya.

Kapabilitas yang jujur#

Perbandingan yang jujur menyebutkan kapabilitas sebagaimana dijamin, bukan sebagaimana diperkirakan. Basis data relasional menawarkan query bebas pada kolom mana pun serta transaksi lintas baris secara default, tetapi kapasitas tulisnya bertumpu pada satu node hingga upaya tambahan seperti sharding dilakukan. Basis data NoSQL umumnya dirancang untuk menyebar tulisan ke banyak node sejak awal, tetapi bentuk querynya dibatasi oleh model datanya, misalnya key-value yang hanya dapat diakses lewat kuncinya dan wide-column yang pola bacanya mengikuti desain tabel.

Konsistensi juga berbeda secara default. Banyak basis data NoSQL menyebarkan salinan data secara asinkron, sehingga pembacaan pada salinan dapat melihat data lama selama lag replikasi belum habis. Sebaliknya, basis data relasional pada satu node menjamin setiap pembacaan melihat hasil transaksi yang sudah berkomitmen. Perbedaan ini bukan soal lebih baik atau lebih buruk, melainkan pilihan desain yang ditukar dengan latensi dan biaya.

Terakhir, skema lentur tidak berarti tanpa perancangan. Struktur yang tidak dijaga basis data berpindah menjadi tanggung jawab kode aplikasi, sehingga disiplin penamaan dan validasi justru harus lebih ketat. Basis data yang menyimpan apa pun tanpa protes hari ini adalah basis data yang menyimpan kekacauan yang tidak terdeteksi hari ini juga.

Kesalahan umum#

Tiga kesalahan berikut paling sering muncul ketika keluarga basis data baru dipilih.

• Memilih basis data NoSQL semata karena antisipasi trafik besar yang belum terukur. Kapasitas yang dibutuhkan sebaiknya dihitung terlebih dahulu, karena scaling vertikal dan replikasi sering kali sudah cukup untuk beban nyata. Migrasi antarkeluarga basis data di tengah jalan jauh lebih mahal daripada menambah kapasitas pada keluarga yang sudah dipilih.
• Menganggap skema lentur berarti tanpa perancangan. Struktur yang tidak dijaga skema berpindah ke kode aplikasi, sehingga pola query justru harus dirancang dengan lebih disiplin. Kebiasaan yang membantu adalah menuliskan pola query utama sebelum menulis model datanya, bukan sesudahnya.
• Memodelkan dokumen seolah tabel relasional, yaitu memecah entitas menjadi banyak dokumen kecil yang saling dirujuk. Gejalanya berupa banyak query kecil yang saling menunggu untuk menyusun satu halaman. Perbaikannya adalah menanamkan data yang diakses bersama ke dokumen yang sama.
• Mengabaikan biaya operasional keluarga yang dipilih. Setiap keluarga membawa alat, kebiasaan pemantauan, dan keahlian tim yang berbeda, sehingga pilihan yang wajar adalah yang dapat dioperasikan tim dengan baik, bukan yang paling banyak dibicarakan.

Ringkasan#

• Pemilihan keluarga basis data diturunkan dari pola akses dan jaminan yang tidak boleh dilanggar, bukan dari popularitas.
• Basis data relasional unggul pada transaksi ACID dan query bebas, basis data dokumen pada skema lentur, key-value pada akses kunci berlatensi rendah, dan wide-column pada throughput tulis tinggi.
• Bentuk relasional menahan duplikasi dan membayar join saat baca, sedangkan bentuk dokumen menyalin data yang diakses bersama dan membayar sinkronisasi saat tulis.
• Kapabilitas antarkeluarga saling meminjam, tetapi jaminan yang diberikan secara default tetap berbeda, dan itulah yang harus dibandingkan.

Referensi#

• Data Modeling in MongoDB — MongoDB — Panduan resmi pemodelan data dokumen, termasuk prinsip data yang diakses bersama disimpan bersama.
• Chapter 2. The SQL Language — PostgreSQL — Dokumentasi resmi konsep relasional PostgreSQL, dari tabel hingga join.