Konsekuensi Scaling - Konsistensi dan NoSQL

Back to IF4031 Arsitektur Aplikasi Terdistribusi

Konsekuensi Scaling - Konsistensi dan NoSQL

Questions/Cues

• Mengapa sharding sulit di RDBMS?

• Apa itu graph partitioning problem?

• Bagaimana NoSQL menyelesaikan masalah sharding?

• Apa itu denormalisasi?

• Apa kekurangan denormalisasi?

• Apa masalah konsistensi di sistem terdistribusi?

• Apa itu Client-Centric Consistency?

• Apa itu Monotonic Reads?

• Apa itu Read Your Writes?

• Apa itu Monotonic Writes?

Reference Points

• 15-IF4031-13-2022-Database-Konsistensi-Availability.pdf

Tantangan Sharding pada Data Ternormalisasi

Dalam RDBMS, data dinormalisasi untuk menghindari duplikasi, menggunakan foreign key untuk menghubungkan data antar tabel. Ketika data ini di-shard, hubungan foreign key menjadi edge antar node dalam sebuah graf.

Graph Partitioning Problem: Tujuan sharding adalah mempartisi graf data ini sedemikian rupa sehingga jumlah edge (referensi) antar partisi minimal. Masalah ini secara komputasi sangat sulit (NP-complete) dan dalam praktiknya, akses data lintas partisi (JOIN) tetap tidak terhindarkan dan menjadi bottleneck.

Solusi NoSQL: Denormalisasi

Database NoSQL mengambil pendekatan radikal: hilangkan foreign key dan JOIN. Sebagai gantinya, mereka menggunakan denormalisasi: data yang direferensikan diduplikasi dan disimpan bersama dengan data induk dalam satu dokumen atau baris.

• Contoh: Alih-alih menyimpan region_id di profil pengguna dan melakukan JOIN ke tabel regions, profil pengguna di NoSQL akan langsung menyimpan nama region “Greater Seattle Area”.

Dengan denormalisasi, setiap unit data (misal, satu profil pengguna) menjadi independen dan dapat disimpan di satu shard tanpa memerlukan referensi ke shard lain. Ini membuat partitioning menjadi trivial dan sangat skalabel.

Kekurangan Denormalisasi:

• Pemborosan Ruang: Data menjadi terduplikasi di banyak tempat.

• Anomali Update: Jika data yang diduplikasi perlu diubah (misalnya, nama region berubah), perubahan itu harus diterapkan di semua tempat data tersebut muncul, yang lebih kompleks.

Masalah Konsistensi di Sistem Terdistribusi

Ketika data direplikasi dan dipartisi, akan ada jeda waktu (delay) hingga perubahan data disebarkan ke semua replika. Hal ini menciptakan kemungkinan inkonsistensi sementara, di mana klien dapat membaca data yang usang (stale data).

Model Konsistensi Berpusat pada Klien (Client-Centric)

Model ini tidak menjamin konsistensi global, tetapi memberikan jaminan tertentu dari sudut pandang satu klien tunggal untuk memberikan pengalaman pengguna yang masuk akal.

1. Monotonic Reads

• Jaminan: Jika seorang klien membaca sebuah nilai, setiap pembacaan berikutnya oleh klien yang sama akan selalu mengembalikan nilai yang sama atau yang lebih baru.

• Mencegah: Pengguna melihat suatu data (misal, komentar postingan), lalu me-refresh halaman dan data tersebut “menghilang” sementara.

2. Read Your Writes

• Jaminan: Setelah seorang klien menulis sebuah nilai, setiap pembacaan berikutnya oleh klien yang sama akan selalu melihat nilai yang baru saja ia tulis (atau yang lebih baru).

• Mencegah: Pengguna memposting komentar, me-refresh halaman, dan tidak melihat komentarnya sendiri.

3. Monotonic Writes

• Jaminan: Jika seorang klien melakukan beberapa penulisan secara berurutan, sistem akan memprosesnya dalam urutan yang sama.

• Mencegah: Pengguna mengedit postingan lalu menghapusnya, tetapi karena network delay, sistem malah memproses penghapusan terlebih dahulu lalu editan, menyebabkan postingan “muncul kembali”.

Penyebab Kegagalan: Semua properti ini bisa gagal jika klien pada permintaan yang berbeda dilayani oleh replika yang berbeda, di mana salah satu replika belum menerima pembaruan terbaru.

Summary

Sharding pada RDBMS menjadi sulit karena data yang ternormalisasi menciptakan banyak dependensi lintas shard. NoSQL mengatasi ini dengan denormalisasi, yaitu menduplikasi data untuk membuat setiap unit data independen, sehingga mudah dipartisi. Namun, pendekatan terdistribusi ini menimbulkan masalah konsistensi. Untuk mengatasinya, model konsistensi berpusat pada klien seperti Monotonic Reads, Read Your Writes, dan Monotonic Writes memberikan jaminan perilaku yang dapat diprediksi dari perspektif pengguna tunggal, meskipun konsistensi global belum tercapai.

Additional Information

Pendalaman: Bagaimana Jaminan Konsistensi Diterapkan?

Untuk mencapai jaminan client-centric, sistem terdistribusi sering menggunakan beberapa teknik:

• Sticky Sessions (Client Affinity): Load balancer atau router aplikasi dapat dikonfigurasi untuk selalu mengarahkan permintaan dari klien yang sama ke node atau replika yang sama. Ini adalah cara paling sederhana untuk menjamin Monotonic Reads dan Read Your Writes, karena klien akan selalu “berbicara” dengan database yang sama yang memiliki data terbarunya (dari perspektif klien tersebut).

• Membaca dari Quorum: Untuk Read Your Writes, klien dapat menunggu hingga penulisan dikonfirmasi oleh sejumlah replika (W) dan kemudian melakukan pembacaan dari sejumlah replika (R) di mana W + R > N (N adalah jumlah total replika). Ini memastikan bahwa setidaknya ada satu replika yang tumpang tindih antara set penulisan dan pembacaan, sehingga klien pasti akan melihat tulisannya sendiri.

• Vector Clocks: Untuk Monotonic Writes dan deteksi konflik yang lebih canggih, setiap data dapat diberi stempel versi (vector clock) yang melacak riwayat perubahannya di berbagai replika. Ini memungkinkan sistem untuk memahami urutan kausal dari berbagai peristiwa.

Eksplorasi: Denormalisasi pada E-commerce

Bayangkan data pesanan (order) di situs e-commerce.

• Model Normalisasi (SQL): Tabel orders akan memiliki product_id dan user_id. Untuk menampilkan detail pesanan, Anda perlu melakukan JOIN ke tabel products untuk mendapatkan nama dan harga produk, dan ke tabel users untuk mendapatkan alamat pengiriman.

• Model Denormalisasi (NoSQL): Dokumen order akan menyimpan salinan lengkap dari informasi produk (nama, harga saat dibeli) dan alamat pengiriman pengguna.

• Pertimbangkan: Apa yang terjadi jika harga produk berubah setelah pesanan dibuat? Dalam model normalisasi, JOIN akan mengambil harga baru yang salah. Dalam model denormalisasi, harga historis yang benar sudah tersimpan di dalam pesanan itu sendiri. Ini adalah contoh di mana denormalisasi tidak hanya untuk performa, tetapi juga untuk kebenaran data historis.