Hologres:Dukungan dan batasan Dynamic Table

Batasan

• Penggunaan Sumber Daya

  Mulai dari Hologres V3.1, tabel baru secara default menggunakan resource serverless untuk menjalankan tugas refresh. Jika instans tidak memiliki resource serverless yang diaktifkan, sistem akan beralih secara otomatis ke resource lokal. Tabel yang dibuat di Hologres V3.0 tetap menggunakan resource yang ditentukan saat pembuatan dan tidak beralih otomatis ke resource serverless.

• Batasan pada tabel dasar

  • Hanya tabel internal Hologres, tabel eksternal Paimon, dan Dynamic Table lain yang didukung sebagai tabel dasar. Untuk membuat Dynamic Table, Anda harus memiliki izin SELECT pada tabel dasar tersebut.

  • Secara default, Hologres V3.1 mengonsumsi data tabel dasar secara inkremental menggunakan metode stream. Dibandingkan dengan metode Binlog, metode stream menawarkan performa lebih baik dan tidak menimbulkan biaya penyimpanan tambahan. Jika tabel dasar Anda sebelumnya menggunakan metode Binlog sebelum V3.1, kami menyarankan agar Anda segera menonaktifkan Binlog untuk mencegah konsumsi penyimpanan tambahan. Untuk menonaktifkan Binlog, lihat Subscribe to Hologres Binlog.

  • Di Hologres V3.0, saat membuat Dynamic Table dalam mode incremental refresh, Binlog harus diaktifkan pada tabel dasar. Namun, hal ini tidak diperlukan untuk tabel dimensi. Untuk informasi lebih lanjut tentang cara mengaktifkan Binlog, lihat Subscribe to Hologres Binlog.

• Batasan pada kueri

  • Skenario yang didukung

    • Ekspresi skalar apa pun

    • Kondisi WHERE

    • Subkueri

    • Common Table Expressions (CTEs)

    • GROUP BY

    • CUBE

    • GROUPING SETS

    • Klausa HAVING

    • Filter agregat

    • UNION ALL

    • UNNEST

  • Fungsi jendela: hanya fungsi berikut yang didukung. Semua fungsi jendela lain, seperti dense_rank, first_value, dan last_value, serta jendela agregat seperti SUM dan COUNT, tidak didukung.

    • row_number dan rank: didukung di Hologres V4.2 dan versi lebih baru. Kueri harus menyertakan filter TopN di kueri luar (WHERE rownum <= N) dan menentukan PARTITION BY serta ORDER BY.

    • lead dan lag: didukung di Hologres V5.0 dan versi lebih baru. Anda harus menentukan PARTITION BY dan ORDER BY, serta hanya bentuk satu argumen lead(expr) dan lag(expr) yang didukung.

    • Satu definisi jendela biasanya hanya mendukung satu fungsi jendela. lead dan lag merupakan pengecualian: keduanya dapat digunakan dalam definisi jendela yang sama.

    • Untuk sintaks dan batasan lengkap, lihat Supported functions for incremental refresh.

  • Skenario yang tidak didukung

    • Subkueri IN

    • EXISTS atau NOT EXISTS

    • EXCEPT atau INTERSECT

    • ORDER BY

    • LIMIT atau OFFSET

  • Penggabungan multi-tabel:

    • Hologres V3.0 hanya mendukung equi-join (INNER JOIN atau LEFT JOIN) pada tabel dimensi, dan join tersebut harus menggunakan sintaks FOR SYSTEM_TIME AS OF PROCTIME(). Penggabungan double-stream multi-tabel tidak didukung. Untuk informasi lebih lanjut, lihat Lookup join statements.

      Catatan

      Lookup join mengaitkan setiap record dengan versi terbaru data tabel dimensi pada waktu pemrosesan. Jika data tabel dimensi berubah setelah join dilakukan, data yang telah di-join sebelumnya tidak diperbarui.

    • Mulai dari Hologres V3.0.26, penggabungan double-stream multi-tabel didukung. Ini setara dengan join OLAP standar atau double-stream join di Flink, termasuk INNER JOIN dan LEFT/RIGHT/FULL OUTER JOIN. Untuk informasi lebih lanjut, lihat CREATE DYNAMIC TABLE.

  • Fungsi: fungsi agregat seperti COUNT, SUM, MIN/MAX, dan COUNT DISTINCT didukung. Fungsi yang berjalan di Parallel Query Engine (PQE) tidak didukung. Tabel berikut menjelaskan fungsi lain yang didukung.

    Function	Syntax	Example	Supported version
    RB_BUILD_AGG	RB_BUILD_AGG(<column>) Catatan Parameter column mendukung tipe data INT32 dan INT64. Untuk informasi lebih lanjut, lihat RoaringBitmap functions.	CREATE DYNAMIC TABLE daily_uv PARTITION BY list (day) WITH ( freshness = '5 minutes', refresh_mode = 'incremental') AS SELECT day, game_id, gameversion, RB_BUILD_AGG(user_id) AS user_rb FROM base_table GROUP BY day, game_id, gameversion;	V3.1 dan versi lebih baru
    STRING_AGG	STRING_AGG([DISTINCT] column_expr, const_expr) Catatan Tipe data: column_expr harus bertipe TEXT, CHAR, atau VARCHAR. const_expr harus berupa konstanta TEXT. Klausa ORDER BY tidak didukung. Mulai dari Hologres V3.1.10, STRING_AGG([DISTINCT] didukung.	CREATE DYNAMIC TABLE string_agg_test_dt WITH ( freshness = '3 minutes', refresh_mode = 'incremental') AS SELECT day, STRING_AGG(gameversion, ',') AS gameversion_list FROM base_table GROUP BY day;	V3.1 dan versi lebih baru Mulai dari V3.1.10, STRING_AGG([DISTINCT] didukung.
    ARRAY_AGG	ARRAY_AGG([DISTINCT] expr) Catatan Tipe data: Parameter expr mendukung BOOL, semua tipe numerik, TEXT, dan BYTEA. Klausa ORDER BY tidak didukung. Mulai dari Hologres V3.1.10, ARRAY_AGG([DISTINCT] didukung.	CREATE DYNAMIC TABLE array_agg_test_dt WITH ( freshness = '3 minutes', refresh_mode = 'incremental') AS SELECT day, ARRAY_AGG(gameversion) AS gameversion_list FROM base_table GROUP BY day;	V3.1 dan versi lebih baru Mulai dari Hologres V3.1.10, ARRAY_AGG([DISTINCT] didukung.
    ANY_VALUE	Dalam kueri agregat yang berisi klausa GROUP BY, fungsi ini mengembalikan nilai dari salah satu baris dalam setiap kelompok secara non-deterministik. ANY_VALUE(expr) Fungsi ANY_VALUE hanya menerima tipe data INT dan BINARY.	CREATE DYNAMIC TABLE dt_t0 WITH ( -- Properties of the dynamic table freshness = '1 minutes', auto_refresh_mode = 'auto' ) AS SELECT a, any_value(c), SUM(b) FROM t0 GROUP BY a;	V3.1.5 dan versi lebih baru

  • Mulai dari Hologres V3.1, Anda dapat mengonfigurasi Dynamic Table sebagai partisi logis. Properti partisi terkait dan pengaturan manajemen juga didukung.

Fitur yang didukung

• Tabel dasar: Fungsionalitasnya sama dengan tabel Hologres standar. Anda dapat menggunakan tabel internal Hologres dan tabel eksternal, seperti dari MaxCompute, Data Lake Formation (DLF), dan Paimon, sebagai tabel dasar. Anda harus memiliki izin yang diperlukan pada tabel dasar untuk membuat Dynamic Table. Untuk informasi lebih lanjut, lihat Dynamic Table permissions.

• Kueri: Semua fungsi, ekspresi SQL, dan tipe data yang saat ini didukung oleh Hologres juga didukung dalam mode full refresh.

• Resource refresh: Secara default, tugas refresh menggunakan resource serverless. Anda juga dapat mengonfigurasi tugas agar menggunakan resource instans Anda saat ini.

Batasan

• Anda tidak dapat mengubah mode refresh dari full refresh ke incremental refresh.

• Di Hologres V3.0, jika Anda membuat VIEW pada Dynamic Table yang berada dalam mode full refresh, proses refresh Dynamic Table tersebut gagal. Masalah ini telah diselesaikan di V3.1 dan versi lebih baru. Kami menyarankan agar Anda melakukan upgrade instans Anda.

Batasan pada tabel dinamis

• Instans Hologres Anda harus V3.0 atau lebih baru.

• Batasan pada properti tabel: Anda tidak dapat menetapkan primary key atau nilai field default. Mesin secara otomatis melakukan inferensi indeks tabel, tetapi Anda juga dapat menyetelnya secara manual sesuai kebutuhan bisnis Anda.

• Hanya mode full refresh dan incremental refresh yang didukung. Fitur dan batasan yang didukung berbeda-beda tergantung pada mode. Untuk detailnya, lihat Full refresh dan Incremental refresh.

• Refresh cascading (freshness = 'upstream') memiliki batasan berikut, yang berlaku untuk mode full refresh maupun incremental refresh:

  • Hanya didukung di Hologres V5.0 dan versi lebih baru.

  • Saat Anda menetapkan freshness = 'upstream', minimal satu dari tabel dasar harus berupa dynamic table.

  • Dependensi cascading tidak boleh membentuk siklus.

  • Jika refresh upstream gagal, refresh downstream tidak dipicu. Kegagalan tidak menyebar ke downstream, dan tabel downstream tetap menyimpan data dari refresh terakhir yang berhasil.

  • Jika sebuah dynamic table memiliki dependensi downstream, operasi DROP pada tabel tersebut ditolak. Anda harus terlebih dahulu menghapus tabel downstream atau menghapus dependensinya.

  • Hanya satu refresh cascading yang berjalan dalam satu waktu untuk tabel downstream tertentu. Jika pemicu upstream datang terlalu sering, putaran antara dilewati, dan interval refresh efektif tabel downstream sama dengan nilai terbesar antara durasi refresh satu putaran miliknya sendiri dan interval pemicu upstream.

Batasan pada operasi DDL dan DML