Ketika dua tabel logis menggunakan kunci shard yang sama tetapi memiliki jumlah shard tabel berbeda, fungsi HASH standar mengubah rute shard database seiring perubahan jumlah shard tabel. Hal ini menyebabkan operasi join antara kedua tabel berdasarkan kunci shard memicu join lintas database, yang mahal dari segi performa. UNI_HASH mengatasi masalah ini dengan menjaga stabilitas rute shard database meskipun jumlah shard tabel berubah, sehingga operasi join berdasarkan kunci shard tetap berada dalam satu shard database.
UNI_HASH menghasilkan distribusi yang merata hanya jika nilai kunci shard itu sendiri tersebar secara merata.
Batasan
Tipe data kunci shard harus berupa integer atau string.
Memerlukan instans PolarDB-X 1.0 versi 5.1.28-1508068 atau lebih baru.
Cara kerja routing
UNI_HASH melakukan routing data menggunakan operasi modulo pada kunci shard:
Integer keys: Nilai kunci dibagi dengan jumlah shard database. Sisa bagi (remainder) menentukan shard database tujuan.
Kunci string: String tersebut pertama-tama dikonversi menjadi nilai hash, lalu operasi modulo yang sama diterapkan. Sebagai contoh,
HASH('8')setara dengan8 % D, di mana D adalah jumlah shard database.
Ketika sharding database dan sharding tabel keduanya menggunakan kunci shard yang sama, UNI_HASH pertama-tama melakukan routing ke shard database, lalu mendistribusikan data secara merata ke seluruh shard tabel di dalam shard database tersebut.
Properti utama: Untuk nilai kunci shard tertentu, shard database tujuan tidak berubah meskipun jumlah shard tabel berubah. Stabilitas inilah yang membedakan UNI_HASH dari HASH.
Kasus penggunaan
UNI_HASH cocok digunakan untuk:
Sharding berdasarkan ID pengguna atau ID pesanan: Ini merupakan kunci integer atau string yang umum dan biasanya memiliki distribusi nilai yang luas.
Melakukan join antar tabel dengan jumlah shard tabel berbeda: Ketika dua tabel logis menggunakan kunci shard yang sama tetapi memiliki jumlah shard tabel berbeda, UNI_HASH memastikan kedua tabel selalu diarahkan ke shard database yang sama untuk nilai kunci tertentu. Operasi join berdasarkan kunci shard tetap berada dalam satu shard database, sehingga menghindari join lintas database.
Membuat tabel ter-shard
Pernyataan bahasa definisi data (DDL) berikut membuat tabel yang di-shard menggunakan UNI_HASH pada kolom id, dengan 4 shard tabel per shard database:
create table test_hash_tb (
id int,
name varchar(30) DEFAULT NULL,
create_time datetime DEFAULT NULL,
primary key(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
dbpartition by UNI_HASH(ID)
tbpartition by UNI_HASH(ID) tbpartitions 4;Perbandingan UNI_HASH vs. HASH
| Skenario | UNI_HASH | HASH |
|---|---|---|
| Hanya sharding database (tanpa sharding tabel) | Melakukan routing berdasarkan nilai kunci % jumlah shard database. | Perilaku identik. |
| Sharding database dan tabel menggunakan kunci shard yang sama | Routing shard database stabil — hasilnya tidak berubah meskipun jumlah shard tabel berubah. | Pengarahan shard basis data berubah saat jumlah shard tabel berubah. |
| Dua tabel logis menggunakan kunci shard yang sama tetapi memiliki jumlah shard tabel berbeda | Operasi join berdasarkan kunci shard tetap berada dalam satu shard database — tidak terjadi join lintas database. | Operasi join berdasarkan kunci shard dapat mencakup beberapa shard database — terjadi join lintas database. |
Pilih UNI_HASH daripada HASH jika kedua kondisi berikut terpenuhi:
Anda menggunakan kunci shard yang sama untuk sharding database dan sharding tabel.
Dua atau lebih tabel logis menggunakan kunci shard yang sama tetapi memiliki jumlah shard tabel berbeda, dan tabel-tabel tersebut sering di-join berdasarkan kunci shard tersebut.