Dari Model Relasional ke Dokumen

Back to IF4031 Arsitektur Aplikasi Terdistribusi

Dari Model Relasional ke Dokumen

Questions/Cues

• Bagaimana DB Relasional melakukan scaling?

• Apa itu scale up vs scale out?

• Apa itu partitioning?

• Apa tantangan partitioning?

• Bagaimana data relasional direpresentasikan?

• Apa itu model Dokumen (JSON)?

• Apa kelebihan model Dokumen?

• Kapan memilih Relasional vs Dokumen?

Reference Points

• 12-IF4031-XX-DataModel.pdf (hlm. 2-12)

Skalabilitas Database Relasional

Database relasional (RDBMS) dirancang untuk berjalan pada satu node. Skalabilitasnya dapat dicapai melalui dua cara utama:

1. Scale Up (Vertical Scaling): Menambah kekuatan pada satu server dengan meningkatkan spesifikasinya (lebih banyak CPU, RAM, storage).

2. Scale Out (Horizontal Scaling): Mendistribusikan beban kerja ke beberapa server.

   • Read Replicas: Membuat salinan database hanya untuk dibaca (read-only). Kueri SELECT dialihkan ke replika ini, mengurangi beban pada database utama (Primary). Kelemahannya adalah data di replika bisa sedikit tertinggal (stale data) karena replikasi biasanya bersifat asinkron.

   • Partitioning (Sharding): Memecah sebuah tabel besar menjadi beberapa partisi fisik yang lebih kecil, yang dapat disimpan di node yang berbeda.

Jenis Partitioning:

• Horizontal: Membagi baris-baris tabel (misalnya, data pelanggan dibagi berdasarkan wilayah).

• Vertical: Membagi kolom-kolom tabel (misalnya, data produk yang jarang berubah dipisah dari data stok yang sering berubah).

Tantangan Partitioning: Kueri yang membutuhkan JOIN antar partisi yang berbeda menjadi sangat mahal karena memerlukan banyak lalu lintas jaringan dan koordinasi antar node.

Model Relasional vs. Model Dokumen

Model Relasional (Normalisasi)

Dalam RDBMS, data dipecah-pecah menjadi banyak tabel kecil untuk mengurangi redundansi (proses normalisasi). Misalnya, profil pengguna dipecah menjadi tabel users, positions, education, dll. Untuk mendapatkan profil lengkap, diperlukan beberapa JOIN.

Model Dokumen (JSON)

Model ini merepresentasikan data dalam format dokumen yang memiliki struktur hirarkis (seperti JSON), mirip dengan objek dalam kode aplikasi. Seluruh informasi yang berhubungan (seperti profil lengkap pengguna) disimpan dalam satu dokumen tunggal.

Kelebihan Model Dokumen:

• Lokalitas Data (Data Locality): Karena semua data yang relevan ada dalam satu dokumen, tidak diperlukan JOIN. Mengambil satu profil pengguna hanya memerlukan satu kali baca dari database, yang membuatnya sangat cepat dan efisien.

• Kesesuaian dengan Aplikasi: Struktur JSON sangat cocok dengan model objek yang digunakan di banyak bahasa pemrograman, mempermudah pekerjaan pengembang.

• Fleksibilitas Skema: Database dokumen sering kali schemaless, artinya tidak semua dokumen dalam satu koleksi harus memiliki struktur yang sama persis.

Kapan Memilih Salah Satunya?

• Gunakan Model Relasional jika aplikasi Anda memiliki banyak hubungan many-to-many dan memerlukan konsistensi data yang kuat (ACID).

• Gunakan Model Dokumen jika data Anda secara alami memiliki struktur seperti dokumen atau pohon (hubungan one-to-many), dan aplikasi Anda sering membaca/menulis seluruh unit data secara bersamaan (misalnya, profil pengguna, postingan blog, katalog produk).

Summary

Database relasional melakukan scaling melalui scale up (memperbesar server) atau scale out (menggunakan read replicas dan partitioning), namun menghadapi tantangan pada operasi JOIN terdistribusi. Sebagai alternatif, model Dokumen (seperti JSON) menawarkan performa lebih baik untuk kasus penggunaan tertentu dengan menyimpan semua data terkait dalam satu unit tunggal, menghilangkan kebutuhan JOIN dan meningkatkan lokalitas data, sehingga sangat cocok untuk aplikasi dengan data berstruktur hirarkis.

Additional Information

Pendalaman Teknis: Embedding vs. Referencing

Dalam model dokumen, Anda memiliki dua pilihan utama untuk menangani hubungan data:

1. Embedding (Menanamkan): Ini adalah pendekatan default di mana Anda menempatkan data terkait langsung di dalam dokumen induk. Ini sangat ideal untuk hubungan one-to-one atau one-to-many di mana data anak tidak memiliki eksistensi di luar induknya (misalnya, daftar alamat untuk seorang pengguna). Inilah yang memberikan keuntungan data locality.

2. Referencing (Mereferensikan): Mirip dengan foreign key di RDBMS, Anda hanya menyimpan ID dari dokumen lain di dalam dokumen induk. Anda kemudian perlu melakukan kueri kedua (disebut application-level join) untuk mengambil data yang direferensikan. Pendekatan ini digunakan untuk hubungan many-to-many atau ketika data yang direferensikan sering diperbarui dan perlu konsisten di banyak tempat (misalnya, profil penulis yang direferensikan oleh banyak artikel).

Memilih antara embedding dan referencing adalah salah satu keputusan desain paling penting dalam model dokumen, yang menyeimbangkan antara performa baca dan kemudahan pembaruan.

Eksplorasi Mandiri

Coba modelkan sebuah “Playlist Lagu” sederhana.

• Versi Relasional: Anda mungkin butuh tabel playlists (id, name), tabel songs (id, title, artist_id), tabel artists (id, name), dan sebuah tabel penghubung playlist_songs (playlist_id, song_id).

• Versi Dokumen: Anda bisa membuat satu dokumen playlist yang berisi array dari objek-objek lagu. Pertimbangkan: apakah informasi artis harus di-embed di setiap lagu, atau direferensikan dengan artist_id? Apa trade-off-nya?