PolarDB:Percepatan\ paralel\ untuk\ Hash\ Join

Prasyarat

Sebelum memulai, pastikan Anda memiliki:

• Kluster PolarDB for MySQL 8.0 Cluster Edition dengan versi revisi 8.0.2.1.0 atau lebih baru

Untuk memeriksa versi revisi Anda, lihat Kueri versi engine.

Cara kerja

Dengan tingkat paralelisme (DOP) sebesar 4, empat worker melakukan pemindaian tabel t1 secara paralel. Setiap worker membangun tabel hash lokal dari bagian datanya sendiri dari t1, lalu melakukan probing terhadap tabel hash tersebut dengan baris-baris t2. Sebuah node leader menjalankan operasi Gather untuk mengumpulkan dan menggabungkan hasil dari semua worker.

Strategi ini efektif ketika tabel hash muat dalam memori. Jika ukuran gabungan tabel hash terlalu besar dan memicu I/O disk, gunakan shuffle hash join sebagai gantinya.

Verifikasi bahwa simple hash join digunakan

Contoh

Buat dua tabel dan masukkan 1.000 baris ke masing-masing:

CREATE TABLE t1 (c1 INT, c2 INT);
CREATE TABLE t2 (c1 INT, c2 INT);

INSERT t1(c1, c2)
WITH RECURSIVE seq AS (
  SELECT 1 AS a, 1 AS b
  UNION ALL
  SELECT a + 1, b + 1 FROM seq WHERE a < 1000
)
SELECT a, b FROM seq;

INSERT INTO t2 SELECT * FROM t1;

Jalankan EXPLAIN FORMAT=TREE dengan petunjuk PQ_DISTRIBUTE untuk memastikan simple hash join dipilih:

EXPLAIN FORMAT=TREE SELECT /*+ PQ_DISTRIBUTE(t1 PQ_NONE) PQ_DISTRIBUTE(t2 PQ_NONE) */ * FROM t1 JOIN t2 ON t1.c1 = t2.c2;

Output yang diharapkan:

EXPLAIN FORMAT=TREE
 EXPLAIN
  -> Gather (slice: 1; workers: 4)  (cost=10.82 rows=4)
    -> Parallel inner hash join (t2.c2 = t1.c1)  (cost=0.57 rows=1)
        -> Parallel table scan on t2, with parallel partitions: 1  (cost=0.03 rows=1)
        -> Parallel hash
            -> Parallel table scan on t1, with parallel partitions: 1  (cost=0.16 rows=1)

Membaca Rencana Eksekusi

Prasyarat

Sebelum memulai, pastikan Anda memiliki:

• Kluster PolarDB for MySQL 8.0 Cluster Edition dengan versi revisi 8.0.2.2.0 atau lebih baru

Untuk memeriksa versi revisi Anda, lihat Kueri versi engine.

Cara kerja

Shuffle hash join (juga dikenal sebagai partition hash join) mengatasi tekanan memori pada simple hash join. Alih-alih setiap worker membangun tabel hash dari seluruh dataset, worker terlebih dahulu mempartisi ulang kedua tabel berdasarkan kunci gabungan. Setiap worker kemudian secara independen membangun tabel hash kecil hanya dari partisi yang ditugaskan kepadanya.

Dengan DOP sebesar 2, eksekusi berlangsung dalam tiga fase:

1. Fase build: Worker memindai t1, mempartisi ulang baris berdasarkan kunci gabungan, dan setiap worker membangun tabel hash kecil dari partisi yang ditugaskan.

2. Fase probe: Worker memindai t2, mempartisi ulang baris berdasarkan kunci gabungan yang sama, dan melakukan probing terhadap partisi tabel hash yang sesuai.

3. Gather: Leader mengumpulkan dan menggabungkan hasil dari semua worker.

Karena setiap tabel hash hanya mencakup subset data, shuffle hash join dapat menangani dataset besar tanpa tumpah ke disk.

Verifikasi bahwa shuffle hash join digunakan

Contoh

Gunakan tabel t1 dan t2 yang sama seperti pada contoh simple hash join. Jalankan EXPLAIN FORMAT=TREE tanpa petunjuk—PolarDB secara otomatis memilih shuffle hash join jika sesuai:

EXPLAIN FORMAT=TREE SELECT * FROM t1 JOIN t2 ON t1.c1 = t2.c2;

Output yang diharapkan:

EXPLAIN FORMAT=TREE
EXPLAIN
| -> Gather (slice: 1; workers: 2)  (cost=33.38 rows=4)
    -> Inner hash join (t2.c1 = t1.c1)  (cost=23.08 rows=2)
        -> Repartition (hash keys: t2.c1; slice: 2; workers: 1)  (cost=11.35 rows=2)
            -> Parallel table scan on t2, with parallel partitions: 1  (cost=0.65 rows=4)
        -> Hash
            -> Repartition (hash keys: t1.c1; slice: 3; workers: 1)  (cost=11.35 rows=2)
                -> Parallel table scan on t1, with parallel partitions: 1  (cost=0.65 rows=4)

Membaca Rencana Eksekusi