All Products
Search
Document Center

AnalyticDB:Refresh materialized views

Last Updated:Jul 03, 2026

Tampilan yang di-materialisasi sering digunakan untuk mempercepat kueri kompleks atau menyederhanakan proses ETL dengan cara menghitung terlebih dahulu kueri yang ditentukan pengguna dan menyimpan hasilnya. Anda dapat menentukan kebijakan refresh berdasarkan pola penulisan pada tabel dasar, kompleksitas komputasi kueri (query_body), serta kebutuhan tingkat kesegaran data.

Memilih kebijakan refresh

Tampilan yang di-materialisasi mendukung dua kebijakan refresh: refresh lengkap (COMPLETE) dan refresh cepat (FAST).

  • Refresh lengkap menjalankan kueri SQL asli untuk memindai seluruh data pada semua partisi target di tabel dasar dan sepenuhnya menimpa data lama dengan hasil perhitungan baru.

  • Refresh cepat menulis ulang kueri tampilan (query_body) agar hanya memindai data yang berubah (melalui operasi INSERT, DELETE, dan UPDATE) di tabel dasar, lalu menerapkan perubahan tersebut ke tampilan yang di-materialisasi. Pendekatan ini menghindari pemindaian seluruh tabel dasar pada setiap siklus refresh sehingga mengurangi biaya komputasi.

Tabel berikut membandingkan kasus penggunaan, keunggulan, dan keterbatasan dari kedua kebijakan tersebut.

Refresh policy

Use cases

Characteristics

Complete refresh

Skenario offline:

  • Pembaruan batch harian (T+1)

  • Pembaruan data per jam

  • Set data kecil dengan kompleksitas komputasi rendah, di mana latensi tingkat menit masih dapat diterima.

Keunggulan: query_body mendukung kueri SQL apa pun.

Keterbatasan: Hanya mendukung pembaruan batch penuh.

Fast refresh

Skenario Real-Time:

  • Ingesti Data real-time.

  • Laporan atau pipeline ETL yang memerlukan pembaruan real-time.

  • Kasus penggunaan yang memerlukan kesegaran data tingkat detik.

Keunggulan:

  • Umumnya memproses volume data yang lebih kecil, sehingga menghasilkan overhead lebih rendah.

  • Dapat menggantikan stream processing, yang mengurangi biaya pengembangan dan maintenance.

Keterbatasan:

  • Tunduk pada keterbatasan versi engine, tabel dasar, dan query_body.

  • Refresh manual dan refresh yang dipicu overwrite tidak didukung.

Memilih pemicu refresh

Saat membuat tampilan yang di-materialisasi, Anda menentukan kebijakan refresh sekaligus pemicu refresh-nya. Tampilan yang di-materialisasi mendukung refresh sesuai permintaan (ON DEMAND) dan refresh yang dipicu overwrite (ON OVERWRITE). Refresh sesuai permintaan mencakup refresh terjadwal dan refresh manual. Jika tidak ditentukan, nilai default pemicu refresh adalah ON DEMAND.

Pertimbangkan kebutuhan tingkat kesegaran data dan beban kluster saat memilih pemicu refresh. Karakteristik dan kasus penggunaan masing-masing pemicu adalah sebagai berikut:

  • Refresh manual: Tampilan yang di-materialisasi tidak merefresh data secara otomatis. Anda harus menjalankan perintah REFRESH MATERIALIZED VIEW secara manual. Cocok untuk skenario di mana konsistensi data bukan prioritas utama atau data jarang berubah.

  • Refresh terjadwal: Tampilan yang di-materialisasi merefresh secara otomatis pada waktu tertentu. Jika refresh masih berjalan saat jadwal berikutnya tiba, sistem akan melewatkan refresh tersebut dan menunggu interval berikutnya. Cocok untuk skenario di mana data tabel dasar berubah secara periodik, seperti catatan transaksi baru yang dihasilkan setiap hari atau minggu.

  • Refresh yang dipicu overwrite: Tampilan yang di-materialisasi merefresh secara otomatis ketika tabel dasar di-overwrite menggunakan perintah INSERT OVERWRITE. Cocok untuk skenario yang memerlukan data real-time dan konsistensi tinggi.

Kebijakan refresh yang berbeda mendukung pemicu refresh yang berbeda, seperti ditunjukkan pada tabel berikut:

Refresh policy

On-demand refresh (ON DEMAND)

Overwrite-triggered refresh (ON OVERWRITE)

Manual refresh

Scheduled refresh

Complete refresh

✔️

✔️

✔️

Fast refresh

✔️

Menentukan kebijakan dan pemicu refresh

Contoh berikut menggunakan tabel customer, sales, dan product untuk menunjukkan cara menentukan kebijakan dan pemicu refresh pada tampilan yang di-materialisasi baru.

/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- Setel mesin tabel ke XUANWU.
CREATE TABLE customer (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(255),
    is_vip Boolean
);

/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- Setel mesin tabel ke XUANWU.
CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    product_id INT,
    customer_id INT,
    price DECIMAL(10, 2),
    quantity INT,
    sale_date TIMESTAMP
);
/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- Setel mesin tabel ke XUANWU.
CREATE TABLE product (
    product_id INT PRIMARY KEY,
    product_name VARCHAR,
    category_id INT,
    unit_price DECIMAL(10, 2),
    stock_quantity INT
);

Buat tampilan yang di-materialisasi dengan refresh lengkap

Gunakan kata kunci REFRESH COMPLETE saat membuat tampilan yang di-materialisasi untuk menetapkan kebijakan refresh lengkap.

Tampilan yang di-materialisasi dengan refresh lengkap mendukung refresh manual, refresh terjadwal, dan refresh yang dipicu overwrite.

  • Buat tampilan yang di-materialisasi bernama compl_mv1 dengan refresh lengkap. Karena tidak menentukan pemicu refresh atau parameter NEXT, tampilan ini menggunakan refresh sesuai permintaan dan harus dipicu secara manual.

    CREATE MATERIALIZED VIEW compl_mv1
    REFRESH COMPLETE
    AS
    SELECT * FROM customer;
  • Buat tampilan yang di-materialisasi bernama compl_mv2 dengan refresh lengkap, menggunakan refresh sesuai permintaan (ON DEMAND), serta menentukan waktu awal (START WITH) dan waktu refresh berikutnya (NEXT). Pada contoh ini, tampilan merefresh secara otomatis setiap pukul 02.00 pagi.

    CREATE MATERIALIZED VIEW compl_mv2
    REFRESH COMPLETE ON DEMAND
     START WITH DATE_FORMAT(now() + interval 1 day, '%Y-%m-%d 02:00:00')
     NEXT DATE_FORMAT(now() + interval 1 day, '%Y-%m-%d 02:00:00')
    AS
    SELECT * FROM customer;
  • Buat tampilan yang di-materialisasi bernama compl_mv3 dengan refresh lengkap dan dikonfigurasi untuk refresh yang dipicu overwrite (ON OVERWRITE). Mode ini tidak memerlukan klausa NEXT.

    CREATE MATERIALIZED VIEW compl_mv3
    REFRESH COMPLETE ON OVERWRITE
    AS
    SELECT * FROM customer;

Buat tampilan yang di-materialisasi dengan refresh cepat

Gunakan kata kunci REFRESH FAST saat membuat tampilan yang di-materialisasi untuk menetapkan kebijakan refresh cepat. Tampilan yang di-materialisasi dengan refresh cepat hanya mendukung refresh terjadwal.

Aktifkan binary logging

Sebelum membuat tampilan yang di-materialisasi dengan refresh cepat, Anda harus mengaktifkan binary logging untuk kluster dan tabel dasarnya.

SET ADB_CONFIG BINLOG_ENABLE=true; -- Untuk kluster dengan versi engine sebelum 3.2.0.0, jalankan perintah ini untuk mengaktifkan binary logging. Fitur ini diaktifkan secara default pada versi 3.2.0.0 dan yang lebih baru.
ALTER TABLE customer binlog=true;
ALTER TABLE sales binlog=true;
ALTER TABLE product binlog=true;
Penting
  • Operasi INSERT OVERWRITE INTO dan TRUNCATE didukung pada tabel dengan binary logging yang diaktifkan hanya pada versi engine 3.2.0.0 dan yang lebih baru.

  • Setelah membuat tampilan yang di-materialisasi dengan refresh cepat, Anda tidak dapat menonaktifkan binary logging pada tabel dasar.

  • Setelah menghapus tampilan yang di-materialisasi dengan refresh cepat, Anda dapat secara manual menonaktifkan binary logging untuk kluster dan tabel dasar dengan menjalankan perintah SET ADB_CONFIG BINLOG_ENABLE=false; dan ALTER TABLE <table_name> binlog=false;.

Tampilan yang di-materialisasi satu tabel

  • Buat tampilan yang di-materialisasi satu tabel fast_mv1 dengan refresh cepat tanpa agregasi, yang merefresh setiap 10 detik.

    CREATE MATERIALIZED VIEW fast_mv1
    REFRESH FAST NEXT now() + INTERVAL 10 second
    AS
    SELECT sale_id, sale_date, price
    FROM sales
    WHERE price > 10;
  • Buat tampilan yang dimaterialisasi fast_mv2 berbasis satu tabel, yang menggunakan penyegaran cepat dengan agregasi GROUP BY dan diperbarui setiap 5 detik.

    CREATE MATERIALIZED VIEW fast_mv2
    REFRESH FAST NEXT now() + INTERVAL 5 second
    AS
    SELECT
       customer_id, sale_date,                 -- Sistem menggunakan kolom GROUP BY sebagai primary key tampilan yang di-materialisasi.
       COUNT(sale_id) AS cnt_sale_id,          -- Kolom output agregasi.
       SUM(price * quantity) AS total_revenue, -- Kolom output agregasi.
       customer_id / 100 AS new_customer_id    -- Kolom output non-agregasi dapat menggunakan ekspresi apa pun.
    FROM sales
    WHERE ifnull(price, 1) > 0                 -- Kondisi dapat menggunakan ekspresi apa pun.
    GROUP BY customer_id, sale_date;
  • Buat tampilan yang dimaterialisasi fast_mv3 berbasis satu tabel dengan refresh cepat tanpa agregasi GROUP BY, yang diperbarui setiap menit.

    CREATE MATERIALIZED VIEW fast_mv3
    REFRESH FAST NEXT now() + INTERVAL 1 minute
    AS
    SELECT count(*) AS cnt   -- Sistem menghasilkan primary key konstan untuk memastikan tampilan yang di-materialisasi hanya berisi satu catatan.
    FROM sales;

Tampilan yang di-materialisasi multi-tabel

  • Buat tampilan yang di-materialisasi multi-tabel fast_mv4 dengan refresh cepat tanpa agregasi, yang merefresh setiap 5 detik.

    CREATE MATERIALIZED VIEW fast_mv4
    REFRESH FAST NEXT now() + INTERVAL 5 second
    AS
    SELECT 
        c.customer_id,
        c.customer_name,
        p.product_id,
        s.sale_id,
        (s.price * s.quantity) AS revenue
    FROM 
        sales s
    JOIN 
        customer c ON s.customer_id = c.customer_id
    JOIN 
        product p ON s.product_id = p.product_id;
  • Buat tampilan yang dimaterialisasi multi-tabel fast_mv5 dengan refresh cepat menggunakan agregasi GROUP BY, yang diperbarui setiap 10 detik.

    CREATE MATERIALIZED VIEW fast_mv5
    REFRESH FAST NEXT now() + INTERVAL 10 second
    AS
    SELECT 
        s.sale_id,
        c.customer_name,
        p.product_name,
        COUNT(*) AS cnt,           
        SUM(s.price * s.quantity) AS revenue,         
        SUM(p.unit_price) AS sum_p          
    FROM 
        sales s
    JOIN 
        (SELECT customer_id, customer_name FROM customer) c ON c.customer_id = s.customer_id
    JOIN 
        (SELECT * FROM product WHERE stock_quantity > 0) p ON p.product_id = s.product_id
    GROUP BY 
        s.sale_id, c.customer_name, p.product_name;

Catatan

Jika tabel dasar mengalami operasi TRUNCATE atau INSERT OVERWRITE, atau terjadi anomali internal yang memengaruhi kebenaran data, tampilan yang di-materialisasi inkremental secara otomatis beralih ke refresh lengkap satu kali. Setelah refresh lengkap berhasil, refresh berikutnya dilanjutkan secara otomatis dalam mode inkremental.

Keterbatasan

Keterbatasan berikut berlaku untuk tampilan yang di-materialisasi dengan refresh cepat:

  • Untuk kluster dengan versi engine sebelum 3.2.3.0, tabel partisi tidak dapat menjadi tabel dasar tampilan yang di-materialisasi dengan refresh cepat.

  • Untuk kluster dengan versi engine sebelum 3.2.3.1, operasi INSERT OVERWRITE dan TRUNCATE tidak didukung pada tabel dasar tampilan yang di-materialisasi dengan refresh cepat. Menjalankan operasi ini akan menyebabkan error.

  • Refresh cepat hanya mendukung refresh terjadwal dengan interval antara 5 detik hingga 5 menit.

  • query_body tampilan yang di-materialisasi dengan refresh cepat memiliki keterbatasan berikut:

    • Tampilan yang di-materialisasi harus menghasilkan data identik dengan kueri langsung pada tabel dasar dan mendukung semua perubahan DML. Jika query_body tidak mendukung refresh cepat, pernyataan CREATE MATERIALIZED VIEW akan mengembalikan error.

    • Kondisi tidak boleh mengandung ekspresi non-deterministik, seperti now() atau rand().

    • Hanya fungsi agregat berikut yang didukung: COUNT, SUM, MAX, MIN, AVG, APPROX_DISTINCT, dan COUNT(DISTINCT).

    • Ketika query_body menggunakan fungsi agregat MAX, MIN, APPROX_DISTINCT, atau COUNT(DISTINCT), hanya operasi INSERT yang diizinkan pada tabel dasar. Operasi penghapusan data seperti DELETE, UPDATE, REPLACE, dan INSERT ON DUPLICATE KEY UPDATE dilarang.

    • Kata kunci DISTINCT tidak didukung untuk fungsi agregat selain COUNT(DISTINCT).

    • COUNT(DISTINCT) hanya mendukung tipe INTEGER.

    • AVG tidak mendukung tipe DECIMAL.

    • Kata kunci HAVING tidak didukung untuk operasi agregasi.

    • Fungsi window tidak didukung.

    • Operasi pengurutan tidak didukung.

    • Operasi himpunan seperti UNION, EXCEPT, dan INTERSECT tidak didukung.

  • Tampilan yang di-materialisasi multi-tabel dengan refresh cepat memiliki keterbatasan tambahan berikut:

    • Tampilan yang di-materialisasi multi-tabel saat ini hanya mendukung INNER JOIN.

    • Secara default, tampilan yang di-materialisasi multi-tabel dapat menggabungkan maksimal lima tabel.

    • Kolom join dalam tampilan yang di-materialisasi multi-tabel harus merupakan kolom asli dari tabel, memiliki tipe data yang sama, dan setiap kolom join harus memiliki indeks.

Refresh manual tampilan yang di-materialisasi

Jika tampilan yang di-materialisasi dibuat dengan kebijakan refresh ON DEMAND dan tidak ada klausa NEXT, tampilan tersebut tidak merefresh secara otomatis. Anda harus melakukan refresh secara manual.

REFRESH MATERIALIZED VIEW <mv_name>;

Setelah mengirim permintaan refresh, sistem menambahkan pekerjaan refresh ke antrian latar belakang. Anda dapat melanjutkan operasi lain tanpa menunggu refresh selesai.

Pesan balasan berupa Query OK atau Success menunjukkan bahwa pekerjaan refresh berhasil dikirim ke antrian.

Menanyakan catatan refresh

Menanyakan catatan refresh otomatis

Jalankan pernyataan SQL berikut untuk menanyakan catatan refresh otomatis pada tampilan yang di-materialisasi tertentu, termasuk waktu mulai (start_time), waktu selesai (end_time), status (state), dan ID proses (process_id). Untuk informasi lebih lanjut tentang bidang dalam hasil yang dikembalikan, lihat Kelola tampilan yang di-materialisasi.

SELECT * FROM information_schema.mv_auto_refresh_jobs where mv_name = '<mv_name>';

Menanyakan catatan refresh manual

  • Untuk menanyakan catatan refresh manual dari 30 hari terakhir, Anda dapat menggunakan fitur audit SQL. Saat menanyakan, masukkan kata kunci REFRESH MATERIALIZED VIEW mv_name untuk menemukan informasi seperti waktu, durasi, alamat IP, dan akun database untuk setiap refresh manual.

    Fitur audit SQL harus diaktifkan secara terpisah. Operasi SQL yang terjadi sebelum fitur ini diaktifkan tidak dicatat dalam log audit.
  • Untuk menanyakan catatan refresh manual dan otomatis dari 14 hari terakhir, Anda dapat menggunakan fitur diagnostik dan optimasi SQL. Saat menanyakan, masukkan nama tampilan yang di-materialisasi, seperti compl_mv1, untuk menemukan informasi semua kueri SQL terkait (termasuk pembuatan, refresh manual, refresh otomatis, dan pengubahan), seperti waktu mulai, akun database, durasi, dan ID proses.

Menghentikan pekerjaan refresh yang sedang berjalan

Jika pekerjaan refresh memakan waktu terlalu lama, Anda dapat menghentikannya secara manual menggunakan ID prosesnya. Jika gagal, hubungi dukungan teknis.

Catatan

Jika Anda menghentikan pekerjaan refresh menggunakan perintah KILL PROCESS <process_id>;, perlu diperhatikan bahwa refresh berikutnya tetap dipicu pada waktu terjadwal berikutnya atau pada overwrite tabel dasar berikutnya.

Dokumen terkait