Hologres：Runtime Filter

Skenario

Hologres V2.0 dan versi yang lebih baru mendukung Runtime Filter. Fitur ini biasanya digunakan dalam skenario hash join yang melibatkan dua atau lebih tabel, terutama saat menggabungkan tabel besar dengan tabel kecil. Tidak diperlukan konfigurasi manual—pengoptimal dan mesin eksekusi secara otomatis mengoptimalkan penyaringan selama eksekusi kueri, sehingga mengurangi beban I/O dan meningkatkan kinerja kueri penggabungan.

Cara kerja

Untuk memahami cara kerja Runtime Filter, Anda harus terlebih dahulu memahami proses penggabungan. Berikut adalah contoh pernyataan SQL untuk menggabungkan dua tabel:

select * from test1 join test2 on test1.x = test2.x;

Rencana eksekusi yang sesuai ditampilkan di bawah ini.

Seperti yang ditunjukkan dalam rencana eksekusi, ketika kedua tabel digabungkan, sebuah tabel hash dibuat dari tabel test2. Kemudian, data dari tabel test1 dicocokkan dengan tabel hash tersebut, dan hasilnya dikembalikan. Proses penggabungan ini melibatkan dua istilah kunci:

• Build side: Saat dua tabel atau subkueri digabungkan menggunakan hash join, data dari salah satu tabel atau subkueri digunakan untuk membuat tabel hash. Sisi ini disebut build side dan sesuai dengan node Hash dalam rencana eksekusi.

• Probe side: Sisi lain dari hash join membaca data dan mencocokkannya dengan tabel hash dari build side. Sisi ini disebut probe side.

Secara umum, jika rencana eksekusi benar, tabel yang lebih kecil berada di sisi build side dan tabel yang lebih besar berada di sisi probe side.

Runtime Filter menggunakan distribusi data dari sisi build side untuk menghasilkan filter ringan yang dikirim ke sisi probe side guna memangkas datanya. Proses ini mengurangi volume data dari sisi probe side yang terlibat dalam hash join dan ditransmisikan melalui jaringan, sehingga meningkatkan kinerja hash join.

Oleh karena itu, Runtime Filter paling efektif untuk penggabungan antara tabel besar dan tabel kecil dengan perbedaan volume data yang signifikan, memberikan peningkatan kinerja yang lebih besar dibandingkan penggabungan standar.

Batasan

• Hanya Hologres V2.0 dan versi yang lebih baru yang mendukung Runtime Filter.

• Runtime Filter hanya dipicu jika kondisi penggabungan berisi satu bidang saja. Namun, mulai dari Hologres V2.1, Runtime Filter mendukung penggabungan pada beberapa bidang dan dipicu jika beberapa bidang penggabungan memenuhi kondisi tersebut.

• Hanya Hologres V4.0 dan versi yang lebih baru yang mendukung TopN Runtime Filter, yang digunakan untuk meningkatkan kinerja dalam skenario yang melibatkan perhitungan TopN pada satu tabel.

Kondisi pemicu

Hologres menyediakan penggabungan berkinerja tinggi. Mesin secara otomatis memicu Runtime Filter jika pernyataan SQL memenuhi semua kondisi berikut:

• Volume data pada sisi probe adalah 100.000 baris atau lebih.

• Rasio volume data yang dipindai: sisi build / sisi probe <= 0,1. Semakin kecil rasio, semakin besar kemungkinan Runtime Filter akan dipicu.

• Rasio volume data yang digabungkan: sisi build / sisi probe <= 0,1. Semakin kecil rasio, semakin besar kemungkinan Runtime Filter akan dipicu.

Contoh 1: Gunakan Runtime Filter Lokal untuk kondisi penggabungan dengan satu kolom

• Kode sampel:

  begin; 
  create table test1(x int, y int);
  call set_table_property('test1', 'distribution_key', 'x');
  
  create table test2(x int, y int);
  call set_table_property('test2', 'distribution_key', 'x');
  end;
  
  insert into test1 select t, t from generate_series(1, 100000) t;
  insert into test2 select t, t from generate_series(1, 1000) t;
  analyze test1;
  analyze test2;
  
  explain analyze select * from test1 join test2 on test1.x = test2.x;

• Rencana eksekusi:

  • Tabel test2 memiliki 1.000 baris, dan tabel test1 memiliki 100.000 baris. Rasio volume data antara sisi build side dan sisi probe side adalah 0,01, dan rasio volume data yang digabungkan juga 0,01—keduanya kurang dari 0,1. Karena kondisi ini memenuhi syarat pemicu default, mesin secara otomatis menggunakan Runtime Filter.

  • Tabel test1 pada sisi probe side memiliki node Runtime Filter Target Expr, yang menunjukkan bahwa Runtime Filter telah didorong ke sisi probe side.

  • Pada sisi probe side, `scan_rows` merepresentasikan data yang dibaca dari penyimpanan, yaitu 100.000 baris. `rows` merepresentasikan jumlah baris dari operator pemindaian setelah disaring dengan Runtime Filter, yaitu 1.000 baris. Perbedaan antara kedua nilai ini menunjukkan efek penyaringan Runtime Filter.

Contoh 2: Gunakan Runtime Filter Lokal untuk kondisi penggabungan dengan beberapa kolom (didukung di Hologres V2.1)

• Kode sampel:

  drop table if exists test1, test2;
  begin;
  create table test1(x int, y int);
  create table test2(x int, y int);
  end;
  insert into test1 select t, t from generate_series(1, 1000000) t;
  insert into test2 select t, t from generate_series(1, 1000) t;
  analyze test1;
  analyze test2;
  
  explain analyze select * from test1 join test2 on test1.x = test2.x and test1.y = test2.y;

• Rencana eksekusi:

  • Kondisi penggabungan memiliki beberapa kolom, dan Runtime Filter juga dihasilkan untuk beberapa kolom.

  • Sisi build side disiarkan (broadcast), sehingga Runtime Filter Lokal dapat digunakan.

Contoh 3: Gunakan Runtime Filter Global untuk penggabungan shuffle (didukung di Hologres V2.2)

• Kode sampel:

  SET hg_experimental_enable_result_cache = OFF;
  
  drop table if exists test1, test2;
  begin;
  create table test1(x int, y int);
  create table test2(x int, y int);
  end;
  insert into test1 select t, t from generate_series(1, 100000) t;
  insert into test2 select t, t from generate_series(1, 1000) t;
  analyze test1;
  analyze test2;
  
  explain analyze select * from test1 join test2 on test1.x = test2.x;

• Rencana eksekusi:

  Rencana eksekusi menunjukkan bahwa data sisi probe side di-shuffle ke operator Hash Join. Mesin secara otomatis menggunakan Runtime Filter Global untuk mempercepat kueri.

Contoh 4: Gabungkan filter In dengan indeks bitmap (didukung di Hologres V2.2)

• Kode sampel:

  set hg_experimental_enable_result_cache=off;
  
  drop table if exists test1, test2;
  
  begin;
  create table test1(x text, y text);
  call set_table_property('test1', 'distribution_key', 'x');
  call set_table_property('test1', 'bitmap_columns', 'x');
  call set_table_property('test1', 'dictionary_encoding_columns', '');
  
  create table test2(x text, y text);
  call set_table_property('test2', 'distribution_key', 'x');
  end;
  
  insert into test1 select t::text, t::text from generate_series(1, 10000000) t;
  
  insert into test2 select t::text, t::text from generate_series(1, 50) t;
  
  analyze test1;
  analyze test2;
  
  explain analyze select * from test1 join test2 on test1.x = test2.x;

• Rencana eksekusi:

  Rencana eksekusi menunjukkan bahwa bitmap digunakan pada operator pemindaian sisi probe side. Filter In memberikan penyaringan yang tepat, sehingga mengurangi keluaran hanya menjadi 50 baris. Nilai `scan_rows` lebih dari 7 juta, yang lebih sedikit daripada 10 juta baris aslinya. Pengurangan ini terjadi karena filter In dapat didorong ke mesin penyimpanan, yang mengurangi biaya I/O. Menggabungkan Runtime Filter tipe In dengan bitmap sangat efektif, terutama ketika kunci gabungan bertipe STRING.

Contoh 5: Kurangi I/O dengan filter MinMax (didukung di Hologres V2.2)

• Kode sampel:

  set hg_experimental_enable_result_cache=off;
  
  drop table if exists test1, test2;
  
  begin;
  create table test1(x int, y int);
  call set_table_property('test1', 'distribution_key', 'x');
  
  create table test2(x int, y int);
  call set_table_property('test2', 'distribution_key', 'x');
  end;
  
  insert into test1 select t::int, t::int from generate_series(1, 10000000) t;
  insert into test2 select t::int, t::int from generate_series(1, 100000) t;
  
  analyze test1;
  analyze test2;
  
  explain analyze select * from test1 join test2 on test1.x = test2.x;

• Rencana eksekusi:

  Rencana eksekusi menunjukkan bahwa operator pemindaian pada sisi probe side hanya membaca sedikit lebih dari 320.000 baris dari mesin penyimpanan—jauh lebih sedikit daripada 10 juta baris aslinya. Pengurangan ini terjadi karena Runtime Filter didorong ke mesin penyimpanan, yang menggunakan metadata blok data untuk menyaring seluruh blok, sehingga secara signifikan mengurangi biaya I/O. Metode ini sangat efektif ketika kunci gabungan bertipe numerik dan rentang nilai sisi build side lebih kecil daripada sisi probe side.