All Products
Search
Document Center

PolarDB:Kapan memilih partisi LIST DEFAULT HASH

Last Updated:Mar 29, 2026

PEMBAGIAN PARTISI list murni tidak efektif dalam dua situasi: ketika kumpulan nilai kunci partisi bersifat terbuka (open-ended) atau tidak diketahui pada saat pembuatan tabel, dan ketika distribusi long-tail membuat pemberian partisi terpisah untuk setiap kunci ber-volume rendah menjadi tidak praktis. PEMBAGIAN PARTISI LIST DEFAULT HASH mengatasi kedua masalah tersebut dengan menggabungkan partisi list khusus untuk kunci ber-volume tinggi dan sub-partisi hash yang secara otomatis menampung semua nilai lainnya.

Kasus penggunaan

Gunakan PEMBAGIAN PARTISI LIST DEFAULT HASH jika salah satu kondisi berikut berlaku:

  • Nilai kunci partisi tidak dapat didaftar secara lengkap — nilai-nilai yang mungkin bersifat terbuka atau tidak diketahui saat Anda membuat tabel.

  • Distribusi kunci long-tail — sejumlah kecil kunci ber-volume tinggi menyimpan sebagian besar data, sementara banyak kunci ber-volume rendah berbagi sisa datanya. Salah satu indikator umum adalah pola 80/20: 20% nilai kunci partisi menyimpan 80% data, sedangkan 80% nilai lainnya menyimpan sisa 20%.

Pada kedua kasus tersebut, memaksa setiap kunci ber-volume rendah masuk ke partisi list bernama akan memboroskan partisi dan meningkatkan beban pemeliharaan. PEMBAGIAN PARTISI LIST DEFAULT HASH memungkinkan Anda memberikan partisi list khusus untuk kunci ber-volume tinggi dan mengarahkan semua nilai lainnya ke sekumpulan sub-partisi hash yang mendistribusikan beban secara merata.

Contoh multi-tenant

Sistem pesanan multi-tenant di mana beberapa akun utama menghasilkan sebagian besar data merupakan contoh khas yang cocok. Tabel berikut menunjukkan distribusi representatif:

TenantVolume dataPartisi
Key account 130 juta barisp1
Key account 226 juta barisp2
Key account 324 juta barisp3
Key account 420 juta barisp4
Pelanggan kecil dan menengah30 juta baris (gabungan)p_others

Empat akun utama masing-masing mendapatkan partisi list khusus untuk akses cepat dan terisolasi. Semua pelanggan lainnya diarahkan ke p_others, yang didukung oleh tiga sub-partisi hash (DEFAULT PARTITIONS 3) yang mendistribusikan beban gabungan secara merata.

CREATE TABLE cust_orders
(
  customer_id   VARCHAR(36),
  year          VARCHAR(60),
  order_id      INT,
  order_content TEXT
) PARTITION BY LIST COLUMNS(customer_id)
(
  PARTITION p1 VALUES IN ('Key account 1'),
  PARTITION p2 VALUES IN ('Key account 2'),
  PARTITION p3 VALUES IN ('Key account 3'),
  PARTITION p4 VALUES IN ('Key account 4'),
  PARTITION p_others DEFAULT PARTITIONS 3  -- menangkap semua nilai customer_id lainnya; dipisah menjadi 3 sub-partisi hash
);