Back to IF4031 Arsitektur Aplikasi Terdistribusi
Mekanisme Scaling Database - Replikasi dan Partisi
Questions/Cues
Mengapa DB sering jadi bottleneck?
Apa peran RAM dan caching?
Apa itu horizontal scaling?
Bagaimana cara kerja Read Replica?
Apa kelebihan & kekurangan read replica?
Apa itu Partitioning / Sharding?
Apa itu functional vs data partitioning?
Apa kelebihan & kekurangan sharding?
Reference Points
- 14-IF4031-12-2022-Database-Storage.pdf
Database sebagai Bottleneck
Dalam arsitektur aplikasi web modern, komponen aplikasi (app clones) dapat dengan mudah di-scale out (ditambah jumlahnya) di belakang load balancer. Namun, semua klon tersebut biasanya berbagi satu database pusat. Database ini menjadi titik pusat untuk shared state dan koordinasi, sehingga sering menjadi bottleneck performa.
Kinerja database sangat bergantung pada kemampuannya untuk menyimpan data yang sering diakses (hot data) dan indeks di dalam RAM (cache), karena akses RAM ribuan kali lebih cepat daripada akses disk (SSD/HDD).
Strategi Scaling Database (Horizontal Scaling)
Untuk mengatasi keterbatasan satu mesin, digunakan teknik horizontal scaling:
1. Read Replica (Replikasi Baca)
Konsep: Membuat beberapa salinan lengkap dari database utama. Semua operasi tulis (
INSERT,UPDATE,DELETE) tetap dikirim ke database Primary, yang kemudian secara asinkron menyalin perubahan tersebut ke semua Replica. Operasi baca (SELECT) disebar ke banyak replica untuk mengurangi beban.Kelebihan:
Sangat efektif untuk workload yang dominan baca (read-heavy), yang merupakan kasus umum (>95% trafik).
Mudah diimplementasikan.
Kekurangan:
Write tidak scalable: Semua operasi tulis masih terpusat di satu Primary DB.
Kapasitas tidak scalable: Setiap replica harus menyimpan salinan lengkap dari seluruh data.
Primary menjadi Single Point of Failure.
Consistency Lag: Data di replica bisa sedikit tertinggal (stale) karena replikasi bersifat asinkron.
2. Partitioning / Sharding
Konsep: Memecah data secara horizontal menjadi beberapa bagian yang lebih kecil dan independen yang disebut shard. Setiap shard disimpan di node database yang terpisah.
Jenis Partisi:
Functional Partitioning: Memisahkan database berdasarkan fungsi bisnis (misal: DB Pengguna, DB Produk, DB Pesanan). Kurang skalabel.
Data Partitioning (Sharding): Membagi baris-baris dari sebuah tabel besar berdasarkan sebuah sharding key (misal: data pengguna dibagi berdasarkan region atau hash dari
user_id).Kelebihan:
- Capacity & Write Scalable: Kapasitas total adalah jumlah dari semua shard, dan operasi tulis dapat didistribusikan ke shard yang relevan, menghilangkan bottleneck terpusat.
Kekurangan:
Kompleksitas Aplikasi: Aplikasi harus tahu ke shard mana sebuah kueri harus diarahkan. SQL biasa tidak bisa langsung digunakan.
Cross-Shard Queries: Kueri yang membutuhkan data dari beberapa shard sekaligus (misalnya
JOIN) menjadi sangat lambat dan kompleks.Hot Spots: Jika sharding key tidak dipilih dengan baik, beberapa shard bisa menjadi jauh lebih sibuk daripada yang lain.
Database sering menjadi bottleneck karena perannya sebagai shared state terpusat. Untuk mengatasinya, digunakan horizontal scaling melalui dua teknik utama: Read Replica, yang mendistribusikan beban baca ke banyak salinan database, efektif untuk aplikasi read-heavy namun tidak menyelesaikan masalah write; dan Sharding, yang mempartisi data ke beberapa node untuk meningkatkan skalabilitas kapasitas dan write, namun dengan mengorbankan kompleksitas pada level aplikasi dan kueri lintas-shard.
Additional Information
Pendalaman: Hierarki Read Replica
Untuk mengurangi beban replikasi pada Primary DB jika jumlah replica sangat banyak, replica dapat disusun secara hierarkis. Primary hanya mereplikasi ke beberapa Middle Replica, dan kemudian Middle Replica inilah yang bertanggung jawab untuk mereplikasi data ke replica-replica di bawahnya. Ini menciptakan pohon replikasi yang mendistribusikan beban.
Pemilihan Sharding Key
Memilih sharding key yang baik adalah seni dan ilmu. Kunci yang buruk dapat menyebabkan “hot shards” (satu shard menerima sebagian besar trafik) dan membuat keuntungan dari sharding menjadi sia-sia. Dua pendekatan umum adalah:
Range-based Sharding: Mempartisi data berdasarkan rentang nilai (misal, A-D di shard 1, E-H di shard 2). Mudah, tetapi bisa menyebabkan hot spot jika data tidak terdistribusi merata (misal, lebih banyak pengguna dengan nama awalan ‘S’).
Hash-based Sharding: Mempartisi data berdasarkan nilai hash dari sharding key. Ini mendistribusikan data secara lebih acak dan merata, tetapi menghilangkan kemampuan untuk melakukan kueri rentang (range query) yang efisien.
Implementasi Sharding
Karena kebanyakan RDBMS tradisional tidak mendukung sharding secara native, pengembang sering kali mengandalkannya pada:
Level Aplikasi: Logika untuk menentukan shard mana yang akan dihubungi ditulis langsung di dalam kode aplikasi. Ini paling fleksibel tetapi paling rumit untuk dikelola.
Proxy SQL: Menggunakan proxy di antara aplikasi dan database (seperti Vitess atau ProxySQL) yang memahami skema sharding dan secara otomatis merutekan kueri ke shard yang benar. Ini menyembunyikan kompleksitas dari aplikasi.