Hologres:Liquid Table

Apa itu Liquid Table

Liquid Table adalah mode penyimpanan tabel baru di Hologres dengan kemampuan utama sebagai berikut:

Fitur ini mengatasi masalah lama pada gudang data tradisional, di mana penyesuaian granularitas shard setelah pertumbuhan data sangat mahal:

Kemampuan utama

• Resharding Online: Gunakan ALTER TABLE untuk mengubah jumlah shard kapan saja, transparan bagi aplikasi.

• Beberapa format penyimpanan: Mendukung kolom (column), berorientasi baris (row), dan hibrida (row,column).

• Redistribusi data terkendali: Pilih antara redistribusi latar belakang otomatis atau melewati redistribusi untuk perpindahan metadata yang lebih cepat.

• Kontrol jendela partisi: Batasi redistribusi hanya pada N hari/bulan partisi terbaru, mengurangi overhead I/O.

• Kompatibilitas fitur luas: Berfungsi dengan Dynamic Table, GSI, indeks teks penuh, indeks vektor (HGraph), Time Travel (MVCC), Binlog, dan tabel partisi logis.

Kasus penggunaan khas

1. Pertumbuhan data melampaui estimasi shard awal: Mulai dengan 16 shard, skala ke 64 enam bulan kemudian.

2. Skala keluar sementara untuk event trafik: Tambahkan shard sebelum event penjualan untuk meningkatkan konkurensi kueri, lalu skala-masuk setelahnya untuk mereklaim resource.

3. Manajemen partisi hot/cold: Skala-masuk partisi historis cold sambil mempertahankan partisi hot dalam skala keluar.

4. Pencarian vektor AI dengan skalabilitas elastis: Skala dinamis tabel vektor seiring pertumbuhan volume recall; indeks tetap tersedia sepanjang proses.

Buat Liquid Table

Tambahkan WITH (liquid_table = 'true') ke pernyataan CREATE TABLE Anda:

-- Penyimpanan kolom (default, untuk workload OLAP)
CREATE TABLE my_table (
    id   INT NOT NULL,
    name TEXT,
    ts   TIMESTAMPTZ,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true');

-- Penyimpanan berorientasi baris (untuk pencarian titik / pembaruan frekuensi tinggi)
CREATE TABLE my_row_table (
    id   INT NOT NULL,
    name TEXT,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true', orientation = 'row');

-- Penyimpanan hibrida (untuk workload campuran pencarian titik + OLAP)
CREATE TABLE my_hybrid_table (
    id   INT NOT NULL,
    name TEXT,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true', orientation = 'row,column');

Ubah jumlah shard (Resharding)

Resharding dilakukan dengan menetapkan ulang tabel ke Table Group berbeda:

-- Buat Table Group target jika belum ada
CALL hg_create_table_group('tg_64', 64);

-- Skala keluar (berlaku secara sinkron)
ALTER TABLE my_table SET (table_group = 'tg_64');

-- Skala-masuk
ALTER TABLE my_table SET (table_group = 'tg_16');

Verifikasi konfigurasi shard saat ini

-- Periksa Table Group dan jumlah shard untuk suatu tabel
SELECT property_key, property_value
FROM hologres.hg_table_properties
WHERE table_name = 'my_table'
AND property_key = 'table_group';

-- Periksa metadata Table Group
SELECT * FROM hologres.hg_table_group_properties
WHERE tablegroup_name = 'tg_64';

Properti saat pembuatan

Memilih nilai yang tepat untuk liquid_table_enable_data_reorganization

Contoh jendela partisi

-- Redistribusi hanya partisi 30 hari terakhir (memerlukan kunci partisi bertipe waktu)
ALTER TABLE order_log SET (
    table_group = 'tg_64',
    liquid_table_reorganization_partition_window = '30 day'
);

Ini ideal untuk tabel log atau fakta dengan retensi panjang di mana partisi historis cold jarang diakses—hanya partisi hot yang perlu didistribusikan ulang.

Matriks kompatibilitas (V4.2.0)

Contoh koeksistensi indeks

-- Indeks teks penuh
CREATE INDEX ft_idx ON my_table USING FULLTEXT (content)
    WITH (tokenizer = 'jieba');

-- GSI (Global Secondary Index)
CREATE GLOBAL INDEX gsi_name ON my_table(name) INCLUDE (ts);

-- Indeks vektor (melalui properti vectors)
ALTER TABLE my_table SET (vectors = '{
    "embedding": {
        "algorithm": "HGraph",
        "distance_method": "Cosine"
    }
}');

Setelah membuat indeks pada Liquid Table, Anda dapat melakukan Resharding melalui ALTER TABLE ... SET (table_group = '...') secara langsung. Semua indeks tetap dapat digunakan pada shard baru secara otomatis.

Rangkuman dampak

Dampak pada penulisan

1) Tulisan tidak diharapkan gagal, tetapi konfigurasikan retry klien. Selama perpindahan metadata, sejumlah kecil permintaan konkuren mungkin mengalami error transien (misalnya timeout koneksi). Konektor harus memiliki retry otomatis yang diaktifkan. Tidak akan ada ketidaktersediaan tulis yang berkepanjangan.

2) Latensi tulis akan mengalami lonjakan yang teramati—ini bukan "dampak nol". Tulisan yang sedang berjalan harus menunggu topologi baru berlaku. Lonjakan biasanya dalam kisaran milidetik hingga detik, tetapi mungkin lebih lama ketika:

• Transaksi berdurasi panjang aktif pada tabel.

• Pemanfaatan I/O instans sudah tinggi.

• Faktor penskalaan sangat besar (misalnya 8 shard langsung ke 128 shard).

3) Selama fase redistribusi, tulisan tidak diblokir tetapi latensi mungkin sedikit meningkat.

• Migrasi data latar belakang mengonsumsi I/O instans dan mungkin bersaing dengan tulisan foreground untuk resource.

• Pada instans dengan pemanfaatan I/O tinggi, latensi tulis selama redistribusi mungkin sedikit lebih tinggi daripada kondisi stabil, dan throughput juga mungkin sedikit menurun.

• Kami menyarankan terus memantau I/O instans dan metrik RT tulis selama fase redistribusi.

4) Untuk workload COPY / impor massal: mulai impor massal hanya setelah Resharding dan redistribusi benar-benar selesai. Mengimpor volume besar selama Resharding secara signifikan memperpanjang waktu redistribusi dan memperkuat fluktuasi latensi tulis.

Dampak terhadap kueri

1) Kueri tidak diharapkan gagal atau diblokir.

• Selama perpindahan metadata, kueri baru dieksekusi terhadap topologi baru.

• Kueri yang sedang berjalan selesai secara normal.

• Dalam kasus langka, kueri yang dikeluarkan tepat pada saat perpindahan mungkin timeout karena pengalihan rute. Retry klien harus menangani hal ini.

2) Dampak latensi baca pada saat perpindahan biasanya minimal, tetapi tidak nol.

• Dibandingkan dengan tulisan, jalur baca kurang terpengaruh oleh perpindahan.

• Kueri yang mengenai momen perpindahan menjalani pengalihan rute; API real-time sensitif latensi mungkin mengamati jitter tingkat milidetik.

• Untuk skenario kueri titik QPS tinggi, rencanakan pengaturan timeout upstream dengan asumsi jitter singkat akan terjadi.

3) Performa kueri data lama mungkin menurun secara signifikan hingga redistribusi selesai:

4) Kueri pada data yang baru ditulis sebagian besar tidak terpengaruh.

• Data baru ditulis ke topologi shard baru; performa kueri konsisten dengan kondisi stabil.

• Namun, jika kueri mencakup data baru dan lama (misalnya pemindaian rentang waktu), RT keseluruhan tetap ditarik turun oleh performa data lama yang menurun.

5) Kueri indeks (GSI / teks penuh / vektor) tetap berfungsi tetapi mungkin tidak memiliki performa stabil. Indeks tetap dapat digunakan setelah Resharding, tetapi I/O fisik untuk pencarian indeks mungkin bersaing dengan redistribusi latar belakang, menyebabkan waktu respons meningkat hingga redistribusi selesai. Pantau kueri P99 dan ekor panjang secara ketat.

Rekomendasi untuk workload sensitif latensi

Jika workload Anda termasuk dalam kategori berikut, perlakukan Resharding sebagai perubahan berisiko dan ikuti proses manajemen perubahan Anda:

Perkiraan durasi dampak (konservatif)

Kesimpulan

Perilaku default

Liquid Table dengan Binlog diaktifkan tidak mengizinkan Resharding secara default. Menjalankan ALTER TABLE ... SET (table_group = ...) secara langsung mengembalikan error.

Prosedur Resharding paksa

-- Langkah 1: Aktifkan GUC eksperimental (hanya tingkat sesi)
SET hg_experimental_enable_liquid_resharding_for_table_with_binlog = on;

-- Langkah 2: Lakukan Resharding
ALTER TABLE my_binlog_table SET (table_group = 'tg_64');

-- Langkah 3: Bersihkan data delta pada shard lama
CALL hg_liquid_resharding_drop_non_current_delta('my_binlog_table');

Dampak terhadap konsumen Binlog

Pendekatan 1: Konversi melalui REBUILD (direkomendasikan)

Mulai dari Hologres V4.2, Anda dapat menggunakan ASYNC REBUILD TABLE untuk merebuild tabel yang sudah ada menjadi Liquid Table di tempat, tanpa tabel baru, tanpa migrasi data manual, dan nama tabel tidak berubah. Untuk detail tentang REBUILD, lihat REBUILD.

-- Konversi tabel yang sudah ada menjadi Liquid Table di tempat (nama tabel tidak berubah)
ASYNC REBUILD TABLE my_table
SET (
    liquid_table = 'true'
);

Pendekatan 2: Migrasi tabel baru

Buat Liquid Table baru, migrasikan data dari tabel yang sudah ada, dan alihkan menggunakan rename transaksional atomik.

-- 1. Buat Liquid Table baru dengan skema yang sama
CREATE TABLE my_table_new (
    id   INT NOT NULL,
    name TEXT,
    ts   TIMESTAMPTZ,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true');

-- 2. Salin data
INSERT INTO my_table_new SELECT * FROM my_table_old;

-- 3. Buat ulang indeks (jika ada)
CREATE INDEX ... ON my_table_new ...;

-- 4. Pertukaran atomik menggunakan transaksi
BEGIN;
ALTER TABLE my_table_old RENAME TO my_table_bak;
ALTER TABLE my_table_new RENAME TO my_table;
COMMIT;

-- 5. Hapus cadangan setelah verifikasi
DROP TABLE my_table_bak;

Kapan mengaktifkan Liquid Table

Sangat direkomendasikan:

• Volume data diperkirakan tumbuh 5x atau lebih selama masa pakai tabel.

• Trafik memiliki lonjakan musiman atau event penjualan yang memerlukan penskalaan shard elastis.

• Tabel fakta inti atau tabel lebar dalam gudang data real-time.

• Tabel pencarian vektor AI.

Dapat ditunda:

• Tabel dimensi kecil dengan volume data stabil.

• Workload yang bergantung pada tabel partisi fisik.

• Workload yang bergantung pada pembacaan langsung MaxCompute.

Pedoman perencanaan jumlah shard

Kiat eksekusi Resharding

1. Jalankan selama jam sepi: Eksekusi ALTER selama jendela pemeliharaan dengan trafik rendah.

2. Hentikan sementara DML besar: Pastikan tidak ada pekerjaan INSERT/UPDATE/DELETE massal yang berjalan.

3. Pilih kelipatan pangkat-dua: misalnya 16 → 32 → 64 menghasilkan performa lebih lancar daripada 16 → 50.

4. Gunakan jendela partisi untuk tabel besar: Atur liquid_table_reorganization_partition_window untuk membatasi cakupan redistribusi pada tabel partisi berumur panjang.

5. Lakukan latihan end-to-end untuk tabel Binlog: Uji alur lengkap Resharding + restart downstream di lingkungan staging terlebih dahulu.

Rekomendasi pemantauan

• Sebelum redistribusi selesai: bandingkan secara berkala waktu respons kueri di shard lama dan baru untuk mengukur progres.

• Pemanfaatan resource instans: Resharding menimbulkan overhead I/O tambahan—pantau penggunaan CPU dan I/O.

• Lag kursor Binlog: untuk tabel yang diaktifkan Binlog, pantau lag konsumen downstream.