Memahami Database Sharding

Sharding adalah pola arsitektur basis data yang terkait dengan partisi horizontal - praktik memisahkan baris satu tabel menjadi beberapa tabel yang berbeda, yang dikenal sebagai partisi. Setiap partisi memiliki skema dan kolom yang sama, tetapi juga baris yang sama sekali berbeda. Demikian juga, data yang disimpan di masing-masing adalah unik dan independen dari data yang disimpan di partisi lain.
Akan membantu untuk memikirkan partisi horisontal dalam hal bagaimana hubungannya dengan partisi vertikal . Dalam tabel yang dipartisi secara vertikal, seluruh kolom dipisahkan dan dimasukkan ke dalam tabel baru yang berbeda. Data yang disimpan dalam satu partisi vertikal tidak tergantung dari data di semua partisi lainnya, dan masing-masing memegang baris dan kolom yang berbeda. Diagram berikut menggambarkan bagaimana sebuah tabel dapat dipartisi secara horizontal dan vertikal:

Sharding melibatkan memecah data seseorang menjadi dua atau lebih bongkahan kecil, yang disebut pecahan logis . Pecahan logis kemudian didistribusikan di seluruh node basis data yang terpisah, disebut sebagai pecahan fisik , yang dapat menampung banyak pecahan logis. Meskipun demikian, data yang disimpan dalam semua pecahan secara kolektif mewakili seluruh dataset logis.
Basis data mencontohkan arsitektur shared-nothing . Ini berarti bahwa pecahannya otonom; mereka tidak berbagi data atau sumber daya komputasi yang sama. Dalam beberapa kasus, meskipun, mungkin masuk akal untuk mereplikasi tabel tertentu ke dalam setiap beling untuk dijadikan tabel referensi. Misalnya, katakanlah ada database untuk aplikasi yang tergantung pada tingkat konversi tetap untuk pengukuran berat. Dengan mereplikasi tabel yang berisi data tingkat konversi yang diperlukan ke dalam setiap beling, akan membantu memastikan bahwa semua data yang diperlukan untuk kueri disimpan di setiap beling.

Seringkali, sharding diimplementasikan pada level aplikasi, yang berarti bahwa aplikasi menyertakan kode yang mendefinisikan shard untuk mentransmisikan membaca dan menulis. Namun, beberapa sistem manajemen basis data memiliki kemampuan sharding, memungkinkan Anda untuk mengimplementasikan sharding secara langsung di tingkat basis data.

Arsitektur Sharding
Setelah Anda memutuskan untuk membuang basis data Anda, hal berikutnya yang perlu Anda ketahui adalah bagaimana Anda akan melakukannya. Saat menjalankan kueri atau mendistribusikan data yang masuk ke tabel atau database yang di-shard, sangat penting untuk mengakses shard yang benar. Kalau tidak, itu bisa mengakibatkan hilangnya data atau permintaan yang sangat lambat. Pada bagian ini, kita akan membahas beberapa arsitektur sharding umum, yang masing-masing menggunakan proses yang sedikit berbeda untuk mendistribusikan data di seluruh pecahan.
Sharding Berbasis Kunci
Sharding berbasis kunci , juga dikenal sebagai sharding berbasis hash , melibatkan penggunaan nilai yang diambil dari data yang baru ditulis - seperti nomor ID pelanggan, alamat IP aplikasi klien, kode ZIP, dll. - dan memasukkannya ke fungsi hash untuk menentukan ke mana data harus dibuang. Fungsi hash adalah fungsi yang mengambil input sepotong data (misalnya, email pelanggan) dan menampilkan nilai diskrit, yang dikenal sebagai nilai hash . Dalam kasus sharding, nilai hash adalah ID shard yang digunakan untuk menentukan di mana shard data yang akan disimpan. Secara keseluruhan, prosesnya terlihat seperti ini:

Untuk memastikan bahwa entri ditempatkan di pecahan yang benar dan secara konsisten, nilai-nilai yang dimasukkan ke dalam fungsi hash semua harus berasal dari kolom yang sama. Kolom ini dikenal sebagai kunci beling . Secara sederhana, kunci beling mirip dengan kunci primer karena keduanya adalah kolom yang digunakan untuk membuat pengidentifikasi unik untuk setiap baris. Secara umum, kunci beling harus statis, artinya seharusnya tidak mengandung nilai yang mungkin berubah seiring waktu. Jika tidak, itu akan meningkatkan jumlah pekerjaan yang digunakan untuk memperbarui operasi, dan dapat memperlambat kinerja.
Sharding bisa menjadi solusi yang bagus bagi mereka yang ingin skala database mereka secara horizontal. Namun, itu juga menambahkan banyak kerumitan dan menciptakan lebih banyak titik kegagalan potensial untuk aplikasi Anda. Sharding mungkin diperlukan untuk beberapa orang, tetapi waktu dan sumber daya yang diperlukan untuk membuat dan memelihara arsitektur yang terbengkalai dapat melebihi manfaatnya bagi yang lain.