All Products
Search
Document Center

PolarDB:UNI_HASH

Last Updated:Mar 29, 2026

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 dengan 8 % 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

SkenarioUNI_HASHHASH
Hanya sharding database (tanpa sharding tabel)Melakukan routing berdasarkan nilai kunci % jumlah shard database.Perilaku identik.
Sharding database dan tabel menggunakan kunci shard yang samaRouting 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 berbedaOperasi 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.