Hologres:Distribution key

Di Hologres, properti tabel distribution_key menentukan strategi distribusi data untuk suatu tabel. Sistem menjamin bahwa catatan (record) dengan nilai kunci distribusi yang sama dialokasikan ke shard yang sama. Anda dapat mengatur properti ini saat membuat tabel dengan sintaks berikut:

-- Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru
CREATE TABLE <table_name> (...) WITH (distribution_key = '[<columnName>[,...]]');
-- Sintaks yang didukung oleh semua versi
BEGIN;
CREATE TABLE <table_name> (...);
call set_table_property('<table_name>', 'distribution_key', '[<columnName>[,...]]');
COMMIT;

Tabel berikut menjelaskan parameter-parameter tersebut.

Konfigurasi kunci distribusi yang tepat memberikan manfaat berikut:

• Performa komputasi yang lebih baik

  Komputasi dapat dijalankan secara paralel di berbagai shard, sehingga meningkatkan performa komputasi secara keseluruhan.

• Permintaan per detik (QPS) yang lebih tinggi

  Saat Anda menggunakan kunci distribusi sebagai kondisi filter, Hologres hanya perlu memindai shard yang relevan. Jika tidak, Hologres harus memindai semua shard, yang mengurangi QPS.

• Performa join yang jauh lebih baik

  Saat dua tabel berada dalam kelompok tabel yang sama dan kolom join-nya juga merupakan kunci distribusi mereka, Hologres memastikan bahwa data dengan kunci join yang sesuai berada di shard yang sama. Hal ini memungkinkan local join, di mana setiap node melakukan join terhadap datanya sendiri tanpa perlu memindahkan data antar node, sehingga efisiensi eksekusi meningkat drastis.

Ikuti prinsip-prinsip berikut saat menetapkan kunci distribusi:

• Pilih kolom dengan kardinalitas tinggi dan distribusi data yang merata sebagai kunci distribusi. Distribusi data yang tidak merata menyebabkan kesenjangan data dan beban kerja yang tidak seimbang, sehingga mengurangi efisiensi kueri. Untuk mengatasi kesenjangan data, lihat Deteksi dan penanganan workload skew.

• Pilih kolom yang sering digunakan dalam klausa GROUP BY sebagai kunci distribusi.

• Untuk operasi join, tetapkan kolom join sebagai kunci distribusi agar memungkinkan local join dan menghindari data shuffle. Tabel-tabel yang di-join harus berada dalam kelompok tabel yang sama.

• Kami menyarankan menetapkan kunci distribusi dengan maksimal dua kolom. Jika Anda menggunakan kunci multi-kolom, kueri dapat menyebabkan data shuffle jika tidak mencakup filter pada semua kolom kunci tersebut. Hindari penggunaan kunci distribusi komposit dengan kolom yang redundan, misalnya dua kolom yang selalu memiliki nilai yang sama. Hal ini dapat menyebabkan kesenjangan data jika data dasarnya juga memiliki kardinalitas rendah.

• Anda dapat menetapkan satu kolom atau beberapa kolom sebagai kunci distribusi. Jika menggunakan satu kolom, jangan tambahkan spasi ekstra dalam perintah. Jika menggunakan beberapa kolom, pisahkan nama kolom dengan koma (,) dan jangan tambahkan spasi ekstra. Urutan kolom dalam kunci distribusi multi-kolom tidak memengaruhi tata letak data atau performa kueri.

• Jika suatu tabel memiliki primary key (PK), kunci distribusi harus berupa PK atau subset dari kolom PK. Kunci distribusi tidak boleh kosong, artinya Anda harus menentukan minimal satu kolom. Persyaratan ini memastikan bahwa semua data untuk satu record hanya dimiliki oleh satu shard. Jika Anda tidak secara eksplisit menentukan kunci distribusi, Hologres menggunakan PK sebagai kunci distribusi default.

Menetapkan kunci distribusi

Saat Anda menetapkan kunci distribusi untuk suatu tabel, Hologres mengalokasikan data ke shard yang berbeda berdasarkan kunci tersebut. Hologres menggunakan algoritma Hash(distribution_key) % shard_count untuk menentukan shard tujuan setiap record. Sistem menjamin bahwa record dengan nilai kunci distribusi yang sama ditempatkan di shard yang sama. Contoh berikut menunjukkan cara menetapkan kunci distribusi.

• Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

  -- Tetapkan kolom 'a' sebagai kunci distribusi. Sistem melakukan hash terhadap nilai di kolom 'a', lalu menerapkan operasi modulo: hash(a) % shard_count = shard_id. Record dengan hasil yang sama didistribusikan ke shard yang sama.
  CREATE TABLE tbl (
      a int NOT NULL,
      b text NOT NULL
  )
  WITH (
      distribution_key = 'a'
  );
  -- Tetapkan kolom 'a' dan 'b' sebagai kunci distribusi. Sistem melakukan hash terhadap nilai dari kedua kolom, lalu menerapkan operasi modulo: hash(a,b) % shard_count = shard_id. Record dengan hasil yang sama didistribusikan ke shard yang sama.
  CREATE TABLE tbl (
      a int NOT NULL,
      b text NOT NULL
  )
  WITH (
      distribution_key = 'a,b'
  );

• Sintaks yang didukung oleh semua versi:

  -- Tetapkan kolom 'a' sebagai kunci distribusi. Sistem melakukan hash terhadap nilai di kolom 'a', lalu menerapkan operasi modulo: hash(a) % shard_count = shard_id. Record dengan hasil yang sama didistribusikan ke shard yang sama.
  begin;
  create table tbl (
  a int not null,
  b text not null
  );
  call set_table_property('tbl', 'distribution_key', 'a');
  commit;
  -- Tetapkan kolom 'a' dan 'b' sebagai kunci distribusi. Sistem melakukan hash terhadap nilai dari kedua kolom, lalu menerapkan operasi modulo: hash(a,b) % shard_count = shard_id. Record dengan hasil yang sama didistribusikan ke shard yang sama.
  begin;
  create table tbl (
    a int not null,
    b text not null
  );
  call set_table_property('tbl', 'distribution_key', 'a,b');
  commit;
                              

Gambar berikut mengilustrasikan distribusi data ini. Saat menetapkan kunci distribusi, pilih kolom yang mendistribusikan data secara merata. Di Hologres, jumlah shard berkaitan dengan jumlah node pekerja. Untuk informasi lebih lanjut, lihat Konsep dasar. Jika Anda memilih kunci yang menghasilkan distribusi data tidak merata, data akan terkonsentrasi di beberapa shard saja. Hal ini memaksa sejumlah kecil node pekerja menangani sebagian besar beban komputasi, yang dapat menyebabkan efek long tail dan mengurangi efisiensi kueri. Untuk informasi tentang cara mengidentifikasi dan mengatasi kesenjangan data, lihat Deteksi dan penanganan workload skew.

Mengabaikan kunci distribusi

Jika Anda tidak menetapkan kunci distribusi, data didistribusikan secara acak ke shard-shard tersebut. Record dengan nilai yang sama mungkin ditempatkan di shard yang sama atau di shard yang berbeda. Contoh berikut menunjukkan cara membuat tabel tanpa kunci distribusi.

-- Jangan tetapkan kunci distribusi.
begin;
create table tbl (
a int not null,
b text not null
);
commit;

Gambar berikut mengilustrasikan distribusi data acak ini.

Kunci distribusi untuk agregasi GROUP BY

Jika Anda menetapkan kunci distribusi, record dengan nilai kunci yang sama berada di shard yang sama. Untuk kueri agregasi GROUP BY, sistem mendistribusikan ulang data berdasarkan kunci pengelompokan. Dengan menetapkan kunci distribusi ke kolom yang sering digunakan dalam klausa GROUP BY, Anda memastikan bahwa data sudah terkumpul (co-located) di setiap shard. Hal ini mengurangi redistribusi data antar shard dan meningkatkan performa kueri. Contoh berikut menunjukkan cara melakukannya.

• Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

  CREATE TABLE agg_tbl (
      a int NOT NULL,
      b int NOT NULL
  )
  WITH (
      distribution_key = 'a'
  );
  -- Contoh kueri: agregasi pada kolom a.
  select a,sum(b) from agg_tbl group by a;

• Sintaks yang didukung oleh semua versi:

  begin;
  create table agg_tbl (
  a int not null,
  b int not null
  );
  call set_table_property('agg_tbl', 'distribution_key', 'a');
  commit;
  -- Contoh kueri: agregasi pada kolom a.
  select a,sum(b) from agg_tbl group by a;

Menjalankan perintah EXPLAIN menampilkan rencana eksekusi tanpa operator redistribution. Karena kunci distribusi tabel (a) sesuai dengan kolom GROUP BY, Hologres dapat melakukan agregasi langsung di dalam setiap shard, sehingga menghindari redistribusi data.

Kunci distribusi untuk join multi-tabel

Join multi-tabel lebih kompleks. Ikuti prinsip umum berikut:

• Jika semua tabel di-join berdasarkan kolom yang sama, tetapkan kolom join tersebut sebagai kunci distribusi untuk setiap tabel.

• Jika tabel-tabel tersebut di-join berdasarkan kolom yang berbeda, prioritaskan join antara tabel terbesar. Tetapkan kolom join tabel terbesar sebagai kunci distribusi mereka.

Contoh berikut menggunakan join tiga tabel untuk mengilustrasikan kasus-kasus tersebut. Anda dapat menerapkan logika yang sama untuk join yang melibatkan lebih dari tiga tabel.

• Ketiga tabel memiliki kolom join yang sama

  Jika ketiga tabel di-join berdasarkan kolom yang sama, skenarionya sederhana. Anda dapat menetapkan kolom join umum tersebut sebagai kunci distribusi untuk ketiga tabel agar memungkinkan local join.

  • Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

    BEGIN;
    CREATE TABLE join_tbl1 (
        a int NOT NULL,
        b text NOT NULL
    )
    WITH (
        distribution_key = 'a'
    );
    CREATE TABLE join_tbl2 (
        a int NOT NULL,
        d text NOT NULL,
        e text NOT NULL
    )
    WITH (
        distribution_key = 'a'
    );
    CREATE TABLE join_tbl3 (
        a int NOT NULL,
        e text NOT NULL,
        f text NOT NULL,
        g text NOT NULL
    )
    WITH (
        distribution_key = 'a'
    );
    COMMIT;
    -- Kueri join 3 tabel
    SELECT * FROM join_tbl1
    INNER JOIN join_tbl2 ON join_tbl2.a = join_tbl1.a
    INNER JOIN join_tbl3 ON join_tbl2.a = join_tbl3.a;

  • Sintaks yang didukung oleh semua versi:

    begin;
    create table join_tbl1(
    a int not null,
    b text not null
    );
    call set_table_property('join_tbl1', 'distribution_key', 'a');
    create table join_tbl2(
    a int not null,
    d text not null,
    e text not null
    );
    call set_table_property('join_tbl2', 'distribution_key', 'a');
    create table join_tbl3(
    a int not null,
    e text not null,
    f text not null,
    g text not null
    );
    call set_table_property('join_tbl3', 'distribution_key', 'a');
    commit;
    --Kueri join 3 tabel
    SELECT * FROM join_tbl1
    INNER JOIN join_tbl2 ON join_tbl2.a = join_tbl1.a
    INNER JOIN join_tbl3 ON join_tbl2.a = join_tbl3.a;

  Rencana eksekusi (EXPLAIN SQL) menunjukkan hal berikut:

  • Tidak ada operator redistribution. Hal ini menunjukkan bahwa data tidak direshuffle dan local join dilakukan.

  • Operator exchange memindahkan data antar tahap eksekusi atau node. Proses ini meningkatkan efisiensi kueri dengan memastikan hanya data dari shard yang relevan yang diproses.

  QUERY PLAN
  Gather  (cost=0.00..16.44 rows=10000 width=36)
    -> Hash Join  (cost=0.00..15.57 rows=10000 width=36)
          Hash Cond: ((join_tbl2.a = join_tbl3.a) AND (join_tbl1.a = join_tbl3.a))
          -> Hash Join  (cost=0.00..10.31 rows=10000 width=20)
                Hash Cond: (join_tbl2.a = join_tbl1.a)
                -> Exchange (Gather Exchange)  (cost=0.00..5.11 rows=10000 width=12)
                      -> Decode  (cost=0.00..5.11 rows=10000 width=12)
                            -> Seq Scan on join_tbl2  (cost=0.00..5.00 rows=10000 width=12)
                -> Hash  (cost=5.11..5.11 rows=10000 width=8)
                      -> Exchange (Gather Exchange)  (cost=0.00..5.11 rows=10000 width=8)
                            -> Decode  (cost=0.00..5.11 rows=10000 width=8)
                                  -> Seq Scan on join_tbl1  (cost=0.00..5.00 rows=10000 width=8)
          -> Hash  (cost=5.12..5.12 rows=10000 width=16)
                -> Exchange (Gather Exchange)  (cost=0.00..5.12 rows=10000 width=16)
                      -> Decode  (cost=0.00..5.12 rows=10000 width=16)
                            -> Seq Scan on join_tbl3  (cost=0.00..5.00 rows=10000 width=16)
  Optimizer: HQO version 1.3.0

• Ketiga tabel memiliki kolom join yang berbeda

  Dalam praktiknya, kolom join dalam join multi-tabel mungkin berbeda. Dalam kasus ini, gunakan prinsip berikut untuk menetapkan kunci distribusi:

  • Prinsip optimasi utama adalah memprioritaskan join antara tabel terbesar. Tetapkan kolom join tabel besar sebagai kunci distribusi. Tabel kecil berisi data lebih sedikit, sehingga strategi distribusinya menjadi prioritas lebih rendah.

  • Jika tabel-tabel tersebut memiliki jumlah data yang kurang lebih sama, tetapkan kunci distribusi ke kolom join yang paling sering digunakan dalam klausa GROUP BY.

  Pada contoh berikut, tiga tabel di-join, dan kolom join-nya tidak identik. Strategi terbaik adalah memilih kolom join tabel terbesar sebagai kunci distribusi. Tabel join_tbl_1 memiliki 10 juta baris, sedangkan join_tbl_2 dan join_tbl_3 masing-masing memiliki 1 juta baris. Oleh karena itu, join_tbl_1 menjadi target utama untuk optimasi.

  • Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

    BEGIN;
    -- join_tbl_1 berisi 10 juta baris.
    CREATE TABLE join_tbl_1 (
        a int NOT NULL,
        b text NOT NULL
    )
    WITH (
        distribution_key = 'a'
    );
    -- join_tbl_2 berisi 1 juta baris.
    CREATE TABLE join_tbl_2 (
        a int NOT NULL,
        d text NOT NULL,
        e text NOT NULL
    )
    WITH (
        distribution_key = 'a'
    );
    -- join_tbl_3 berisi 1 juta baris.
    CREATE TABLE join_tbl_3 (
        a int NOT NULL,
        e text NOT NULL,
        f text NOT NULL,
        g text NOT NULL
    )
    WITH (
        distribution_key = 'a'
    );
    COMMIT;
    -- Saat kunci join berbeda, pilih kunci join tabel terbesar sebagai kunci distribusi.
    SELECT * FROM join_tbl_1
    INNER JOIN join_tbl_2 ON join_tbl_2.a = join_tbl_1.a
    INNER JOIN join_tbl_3 ON join_tbl_2.d = join_tbl_3.f;

  • Sintaks yang didukung oleh semua versi:

    begin;
    --join_tbl_1 berisi 10 juta baris.
    create table join_tbl_1(
    a int not null,
    b text not null
    );
    call set_table_property('join_tbl_1', 'distribution_key', 'a');
    --join_tbl_2 berisi 1 juta baris.
    create table join_tbl_2(
    a int not null,
    d text not null,
    e text not null
    );
    call set_table_property('join_tbl_2', 'distribution_key', 'a');
    --join_tbl_3 berisi 1 juta baris.
    create table join_tbl_3(
    a int not null,
    e text not null,
    f text not null,
    g text not null
    );
    call set_table_property('join_tbl_3', 'distribution_key', 'a');
    commit;
    -- Saat kunci join berbeda, pilih kunci join tabel terbesar sebagai kunci distribusi.
    SELECT * FROM join_tbl_1
    INNER JOIN join_tbl_2 ON join_tbl_2.a = join_tbl_1.a
    INNER JOIN join_tbl_3 ON join_tbl_2.d = join_tbl_3.f;

  Rencana eksekusi (EXPLAIN SQL) menunjukkan hal berikut:

  • Operator redistribution muncul untuk join antara join_tbl_2 dan join_tbl_3. Karena join_tbl_3 adalah tabel yang lebih kecil dan kolom join-nya tidak sesuai dengan kunci distribusinya, Hologres mendistribusikan ulang datanya.

  • Tidak ada operator redistribution untuk join antara join_tbl_1 dan join_tbl_2. Karena kedua tabel menggunakan kolom join umum mereka sebagai kunci distribusi, bagian join ini tidak memerlukan redistribusi data.

  QUERY PLAN
  Gather  (cost=0.00..183.90 rows=1000000 width=49)
    -> Hash Join  (cost=0.00..64.87 rows=1000000 width=49)
        Hash Cond: (join_tbl_2.d = join_tbl_3.f)
        -> Redistribution  (cost=0.00..40.22 rows=1000000 width=27)
            Hash Key: join_tbl_2.d
            -> Hash Join  (cost=0.00..35.99 rows=1000000 width=27)
                Hash Cond: (join_tbl_1.a = join_tbl_2.a)
                -> Exchange (Gather Exchange)  (cost=0.00..18.45 rows=10000000 width=11)
                    -> Decode  (cost=0.00..18.08 rows=10000000 width=11)
                        -> Seq Scan on join_tbl_1  (cost=0.00..7.75 rows=10000000 width=11)
                -> Hash  (cost=6.93..6.93 rows=1000000 width=16)
                    -> Exchange (Gather Exchange)  (cost=0.00..6.93 rows=1000000 width=16)
                        -> Decode  (cost=0.00..6.88 rows=1000000 width=16)
                            -> Seq Scan on join_tbl_2  (cost=0.00..5.29 rows=1000000 width=16)
        -> Hash  (cost=10.97..10.97 rows=1000000 width=22)
            -> Redistribution  (cost=0.00..10.97 rows=1000000 width=22)
                Hash Key: join_tbl_3.f
                -> Exchange (Gather Exchange)  (cost=0.00..7.53 rows=1000000 width=22)
                    -> Decode  (cost=0.00..7.45 rows=1000000 width=22)
                        -> Seq Scan on join_tbl_3  (cost=0.00..5.31 rows=1000000 width=22)
  Optimizer: HQO version 1.3.0