Brief by evilfactorylabs

Brief by evilfactorylabs • Untuk obrolan makan siangmu seputar dunia pemrograman. Terbit sebelum jam 13.37 WIB setiap hari Senin & Selasa.

Database: Tentang SQL dan NoSQL

ACID what

Salah satu hal yang paling sulit dalam membuat dan menjalankan sebuah layanan ataupun aplikasi adalah tentang menyimpan data, khususnya data pengguna. Data adalah salah satu fondasi dari sebuah aplikasi, memilih fondasi yang tepat tentu akan berpengeruh terhadap bagaimana 'sebuah bangunan' berdiri & ber-operasi nanti.

Ada 2 jenis database yang ada sejauh ini: SQL & NoSQL, yang mana akan kita bahas satu-satu berikut dengan pro-kontranya, seperti biasa.

SQL

SQL adalah singkatan dari Structured Query Language, yang intinya sebuah bahasa spesifik yang digunakan untuk mengatur data yang memiliki sistem relational (RDBMS, Relational Database Management System).

Database-database yang menggunakan SQL ini yang paling terkenal adalah MariaDB dan PostgreSQL. Meskipun ada produk lain yang lumayan terkenal (namun pemain baru) yakni CockroachDB, yang menggunakan sintaks yang serupa dengan Postrgres namun dirancang untuk lingkungan cloud.

Database ber-tipe SQL ini adalah yang paling tua, sehingga "ketangguhan" nya lumayan terjamin karena sudah ada & digunakan bertahun-tahun lamanya. Sebagaimana kepanjangan dari SQL, untuk ber-interaksi dengan data, kita harus menggunakan sintaks yang sudah ada.

SELECT `id`, `username`, `email` from `users`

Familiar dengan sintaks diatas? Ya, sintaks tersebut digunakan untuk mengambil data id , username, dan email yang berada di table users. Table singkatnya adalah kumpulan data yang menggunakan format table, yang mana terdiri dari kolom dan baris.

id username email
1 faultable [email protected]
2 ri7nz [email protected]
3 s4mpurn4 [email protected]



Data diatas adalah "Table" users dengan kolom (sebagai contoh, yang ingin diambil) id, username, dan email yang memiliki baris (data) sebanyak 3 baris. Ketika membuat table di RDBMS, nantinya kita akan mendefinisikan kolom-kolom yang ada di table tersebut, berikut dengan tipe datanya. Ada VARCHAR, TEXT, CHAR, INT, dll sesuai dengan kebutuhan.

Jika melihat data diatas, kolom-kolom tersebut bisa diasumsikan bertipe INT untuk id, VARCHAR untuk username, dan TEXT untuk kolom email. Biasanya per-tipe data memiliki batasan, misal CHAR yang biasanya hanya bisa menampung 255 karakter.

Driver (klien) untuk RDBMS ini juga sudah banyak, dari Java sampai Node.js. Sehingga tidak akan kesulitan ketika kita menggunakan database SQL ini di bahasa program yang kita inginkan.

'Type' System

Here we go again.

Seperti yang sudah dibahas sebelumnya, bahwa kolom harus didefinisikan beserta tipe datanya. Kolom ber-tipe CHAR(255) tidak bisa menampung karakter lebih dari 255, error nya serupa dengan menyimpan nilai integer di variabel yang ber-tipe string di level bahasa program.

Keuntungan & kekurangannya, hampir sama dengan apa yang dijual oleh Typing System di bahasa program: Safety.

ACID

ACID atau Atomicity Consistency Isolation Durability adalah sebuah konsep yang ada di database untuk mejamin keandalan sebuah database:

  • Atomicity: Database mengikuti aturan "All or nothing", yang singkatnya, operasi transaksi dilakukan sebagai satu kesatuan alias selesaikan transaksi selengkap-lengkapnya atau jangan lakukan.
  • Consistency: Memastikan hanya data yang valid (yang mengikuti aturan, seperti dibagian kolom tersebut) yang ditulis ke database.
  • Isolation: Memastikan bahwa transaksi berjalan secara aman dan independen pada waktu yang sama tanpa gangguan, tapi tidak memastikan urutan transaksi. Yang singkatnya, untuk menghindari kemungkinan terjadinya ketidak-konsisten-an data yang diproses.
  • Durability: Berdasarkan dari poin sebelumnya, isolasi berguna untuk menjaga data tetap konsisten. Yang singkatnya, bila ada kondisi user A mengubah data B, lalu user C pun sama. User C harus menunggu transaksi yang dilakukan oleh user A (operasi update misalnya) selesai sebelum transaksi yang dilakukan oleh user C berjalan.

    Bagaimana bila ternyata user A ada gagal dalam melakukan transaksi tersebut? Perubahan yang dibuat oleh user C akan dikembalikan ke kondisi sebelumnya untuk menjaga data yang disimpan tetap konsisten.

Prinsip ACID ini berguna untuk menghindari kerusakan data yang disebabkan oleh kerusakan transaksi, sistem, ataupun hardware.

Scalability

Kebanyakan, scaling untuk database RDBMS dilakukan secara vertikal. Alias, dengan menambah hal-hal yang sifatnya kekuatan seperti CPU, RAM, ataupun SSD.

Tapi CockroachDB—pemain baru yang khusus dirancang untuk lingkungan cloud—melakukan scaling secara horizontal (dengan menambah server) namun tetap memenuhi prinsip ACID tersebut, yang artinya, kita tidak perlu khawatir akan kemungkinan terjadinya kerusakan data yang salah satunya dikarenakan memproses transaksi yang ada secara tidak konsisten.

NoSQL

Sebagaimana sebutannya: NoSQL. Yang berarti, tidak ada Structure Query Language yang harus dibuat untuk berurusan dengan data. Database yang ber-tipe NoSQL ini ada 3 jenis:

  • Berbasis key:value (seperti Redis)
  • Berbasis dokumen (seperti MongoDB)
  • Berbasis kolom (seperti Cassandra)
  • Berbasis Graph (seperti Neo4J)

Membahas seputar NoSQL disini tentu sangat luas, namun pada dasarnya sama-sama menyimpan data yang tidak memiliki struktur. Karena penggunaan yang paling umum untuk database NoSQL ini adalah yang berbasis dokumen, mari kita fokus membahas itu saja untuk sekarang.

Document what?

Agar lebih mudah dipahami, mari kita bandingkan dengan MySQL (SQL) & Redis (KV NoSQL). Untuk mengambil suatu data, biasanya kita menggunakan "identifier", dan yang paling efektif adalah via id nya.

SELECT `email`, `name` FROM `users` WHERE `id` = 0

Maka data email dan name dari users yang memiliki id 0 akan muncul bila ada. Lihat, kita mengambil data tersebut berdasarkan kolom id.

Di Redis, misal menggunakan HMGET users:0 email name. Sama seperti keluaran yang didapat dari SQL diatas, bedanya kita mengambil data tersebut berdasarkan key bukan kolom (lihat bagian users:0 yang mana itu adalah key nya).

Di MongoDB, kita menyimpan data (document) didalam collection. Collection adalah kumpulan dokumen. Misal kita memiliki collection bernama users, dan ada data seperti ini:

[{
  _id: "5d2357a54995d450d97ee1d4",
  name: 'fariz',
  email: '[email protected]',
  password: 'wh4tTh3fuCk1nGfuCk?'
}]

Untuk mengambil data tersebut, kita bisa menggunakan "gaya" berikut:

db.users.find("5d2357a54995d450d97ee1d4", { _id: 0, name: 1, email: 1 })

Yang mana users tersebut mengarah ke collection, dan parameter yang ada didalam find tersebut mengarah ke id dokumen yang kita inginkan.

Bentuk dokumen yang ada di document-based database bisa beragam, namun yang paling umum adalah bentuk JSON dan BSON. Jika melihat dari contoh diatas, data (document) disimpan rapih di collection, beda dengan yang KV-based seperti Redis yang tidak memiliki konsep dokumen.

Dan juga beda dengan RDBMS yang pemanggilannya harus menggunakan "domain-specific language" yang juga datanya tersimpan didalam bentuk table yang ter-struktur.

Yang artinya, di document-based tidak memperdulikan struktur (tipe) data. Kamu bisa menyimpan data apa saja, tanpa perlu mengkhawatirkan struktur kolom (yang tidak konsisten) dan juga tipe datanya (yang harus diatur secara eksplisit). It just works.

Ya, dan data tersebut biasanya berbentuk JSON, siapa juga yang masih menggunakan format XML?

ACID what?

Sebelum kita membahas lebih lanjut tentang ACID, mari kita bahas tentang apa sih maksud "transaksi" yang ada di database ini.

Transaction singkatnya adalah sebuah "kumpulan pekerjaan" pada satu waktu yang dilakukan terhadap database. Mari kita ilustrasikan:

  • Fariz memiliki saldo 20rb, dan mengirim 10rb ke Rizaldy
  • Rizaldy memiliki saldo 30rb
  • Transaksi berhasil dilakukan, saldo Fariz sekarang menjadi 10rb dan saldo Rizaldy sekarang menjadi 40rb
  • Bagaimana bila transaksi tersebut gagal (misal ketika mengirim malah mati listrik total)? Tinggal gagalkan operasi tersebut. Saldo Fariz tetap 20rb dan saldo Rizaldy tetap 30rb.

Dari ilustrasi diatas, terdapat kurang lebih 2 operasi: update dan insert. Insert ke "ledger" dan Update ke nilai saldo akhir (contoh aja). Prinsip ACID berperan untuk membuat data yang disimpan tetap konsisten, karena:

  • 4 langkah diatas, dilakukan secara utuh (atomic) bukan terpecah-pecah
  • Data mengikuti struktur yang ada (consistent)
  • "Proses" diatas tidak boleh "terganggu" oleh proses lain (isolated)
  • Bayangkan bila Fariz mengirim 10rb sekaligus mengambil tunai 20rb dalam waktu yang sama (durability)

Operasinya menggunakan model begin-commit, yang intinya bila tidak ada error terjadi maka commit perubahan, selainnya balikkan kondisi ke kondisi sebelumnya (yang konsisten itu).

Di SQL, kita bisa menggunakan sintaks START TRANSACTION dan diakhiri dengan COMMIT, maka operasi yang berada diantara itu akan terjamin konsistensi nya.

Bagaimana di NoSQL?

Yang tidak memiliki konsep relational?

MongoDB mendukung multi-document ACID, yang pada dasarnya menjamin ke-konsisten-an data yang disimpan, meskipun data tersebut tidak memiliki "struktur" seperti database SQL.

Yang mana, menggunakan prinsip yang sama juga: All or nothing.

Bagaimana MongoDB menggunakan pendekatan tersebut? Hmm, tertarik membaca ini?

Scalability

Sudah jelas: Secara horizontal, dengan menambah mesin yang ada.

Mengapa? Karena beda dengan SQL yang relational yang mana biasanya satu row bergantung dengan row yang lain. Di NoSQL, data disimpan sebagaimana adanya (misal sebagai object JSON), yang artinya tidak ada "kesulitan" untuk melakukan "peng-konsisten-an" antar data yang tersebar di beberapa server yang ter-distribusi karena data disimpan "apa adanya".

Meskipun di SQL pun bisa melakukan scaling secara horizontal ini (sharding), namun tidak semudah dan se-efisien yang dilakukan oleh database NoSQL.

SQL atau NoSQL?

Seperti biasa, tergantung.

Pertama, mungkin bisa disandingkan dengan pertimbangan menggunakan static typing vs dynamic typing.

Kedua, NoSQL cocok untuk kebutuhan yang sekiranya tidak memiliki struktur data yang jelas (ya, maksudnya, yang tidak terlalu harus ter-struktur). Untuk kebutuhan yang memiliki pertumbuhan yang cepat. Untuk bisnis yang ingin turun cepat ke pasar.

Ketiga, SQL cocok untuk kebutuhan yang benar-benar bergantung dengan struktur berikut dengan tipe datanya.

Untuk kebutuhan yang benar-benar menomor-satukan konsistensi.

Penutup

Bagaimanapun, pemilihan technology stack harus sesuaii dengan keinginan dan kebutuhan. Dan sumber daya juga, pastinya.

Dan karena data adalah fondasi dari suatu aplikasi, maka memilih basis data yang bijak diawal akan menentukan bagaimana nantinya 'bangunan' tersebut berdiri & ber-operasi.

Di era sekarang yang serba ter-distribusi, mungkin pemilihan database ini bukanlah hal yang lumayan risky mengingat kita sudah biasa membuat 1 layanan 1 basis data (hello microservice!) dan menormalisasi data-data yang ada tersebut (say hello to who am I here?).

Jika ACID adalah satu-satunya hal yang penting untukmu sekarang, go use SQL. Selainnya, pertimbangkan menggunakan NoSQL. NoSQL membuat kamu bisa bergerak lebih, terjun ke pasar lebih cepat, dan hey, pernah merasakan bagaimana ribetnya melakukan migration di RDBMS, kan?

Menikmati tulisan ini?

Blog ini tidak menampilkan iklan, yang berarti blog ini didanai oleh pembaca seperti kamu. Gabung bersama Loading... yang telah membantu blog ini agar terus bisa mencakup tulisan yang lebih berkualitas dan bermanfaat!

Pendukung

Dukung Mengapa saya harus mendukung?
You've successfully subscribed to Brief by evilfactorylabs
Great! Next, complete checkout for full access to Brief by evilfactorylabs
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.