Pemilihan metode sharding yang tepat merupakan keputusan kritis yang menentukan performa dan kemudahan maintenance sistem. Metode sharding menentukan bagaimana data didistribusikan ke berbagai shard, yang secara langsung mempengaruhi efisiensi query, keseimbangan beban, dan fleksibilitas sistem secara keseluruhan. Memahami karakteristik setiap metode sangat penting untuk merancang arsitektur yang optimal sesuai dengan pola akses data aplikasi. 

  1. Sharding Berdasarkan Rentang (Range-Based Sharding)

Data dipartisi berdasarkan rentang nilai kunci shard yang telah ditentukan. Contoh: Data pelanggan dapat dibagi berdasarkan ID: Shard 1 (ID 1-1000), Shard 2 (ID 1001-2000), dan seterusnya. 

Kelebihan: 

  • Kemudahan Implementasi: Mudah dipahami dan diimplementasikan. 
  • Efisiensi Query Rentang: Sangat efisien untuk query yang mencari data dalam rentang tertentu (contoh: BETWEEN atau > dan <), karena hanya perlu mengakses satu atau beberapa shard terkait. 

Kekurangan: 

  • Potensi Hotspot: Dapat menyebabkan distribusi beban tidak merata jika data tidak tersebar secara merata di seluruh rentang. Misalnya, shard untuk pengguna baru akan lebih sibuk. 
  • Skalabilitas Tidak Optimal: Menambahkan shard baru mungkin memerlukan penyesuaian ulang rentang yang kompleks. 
  1. Sharding Berdasarkan Hash (Hash-Based Sharding)

Nilai kunci shard di-input ke dalam fungsi hash, dan output hash menentukan shard tujuan data. Contoh: Fungsi hash hash(user_id) % 4 akan mendistribusikan data secara merata ke dalam 4 shard. 

Kelebihan: 

  • Distribusi Data Merata: Menghasilkan distribusi data dan beban yang sangat merata di seluruh shard, meminimalkan risiko hotspot. 
  • Skalabilitas yang Dapat Diprediksi: Performa tetap konsisten seiring bertambahnya data. 

Kekurangan: 

  • Tidak Efisien untuk Query Rentang: Tidak mendukung query rentang dengan baik. Untuk mencari data dalam suatu rentang, sistem harus melakukan “scatter-gather query” yang mahal ke semua shard. 
  • Tidak Fleksibel: Mengubah jumlah shard (misal, dari 4 menjadi 5) seringkali memerlukan resharding ulang yang masif karena fungsi modulus berubah. 
  1. Sharding Berdasarkan Direktori (Directory-Based Sharding)

Menggunakan lookup table (sering disebut “peta shard” atau “direktori”) yang secara eksplisit memetakan kunci shard ke shard tertentu. Contoh: Tabel terpisah yang berisi customer_id dan shard_id yang sesuai. 

Kelebihan: 

  • Fleksibilitas Tinggi: Logika pemetaan dapat disesuaikan dan diubah dengan mudah tanpa memindahkan data. 
  • Mendukung Kunci Komposit: Dapat menggunakan beberapa kolom sebagai dasar pemetaan, tidak terpaku pada satu kunci. 

Kekurangan: 

  • Single Point of Failure: Lookup table menjadi komponen kritis. Jika rusak atau lambat, seluruh sistem terpengaruh. 
  • Overhead Tambahan: Setiap query harus melakukan lookup terlebih dahulu ke direktori, menambah latensi. 
  1. Sharding Geografis (Geosharding)

Data didistribusikan berdasarkan lokasi geografis pengguna atau entitas data. Contoh: Data pengguna di Eropa disimpan di shard Eropa, data pengguna di Asia disimpan di shard Asia. 

Kelebihan: 

  • Latensi Rendah: Data disimpan secara fisik dekat dengan penggunanya, sehingga mengurangi latency. 
  • Kepatuhan Regulasi: Memudahkan pemenuhan peraturan data seperti GDPR, yang mewajibkan data disimpan di wilayah tertentu. 

Kekurangan: 

  • Ketidakseimbangan Beban: Wilayah dengan populasi pengguna padat akan memiliki shard yang lebih besar dan lebih sibuk. 
  • Kompleksitas Replikasi Data: Jika data perlu diakses secara global, diperlukan mekanisme replikasi yang rumit antar shard geografis. 
  1. Sharding Berdasarkan Aplikasi (Application-Based Sharding)

Logika bisnis aplikasi menentukan di mana data akan disimpan. Contoh: Aplikasi SaaS dapat memisahkan data berdasarkan klien (tenant), di mana setiap klien besar memiliki shard dedicated. 

Kelebihan: 

  • Terisolasi untuk Beban Khusus: Beban kerja dari satu klien atau bagian aplikasi tidak memengaruhi yang lain. 
  • Optimal untuk Arsitektur Multi-Tenant: Sangat cocok untuk aplikasi yang melayani banyak tenant dengan kebutuhan terpisah. 

Kekurangan: 

  • Kompleksitas Logika Aplikasi: Aplikasi menjadi lebih rumit karena harus memiliki logika untuk menentukan shard tujuan. 
  • Manajemen yang Rumit: Mengelola banyak shard dedicated bisa menjadi tidak efisien. 

Referensi: 

https://www.geeksforgeeks.org/system-design/database-sharding-a-system-design-concept/ 

https://www.digitalocean.com/community/tutorials/understanding-database-sharding