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 operasiINSERT,DELETE, danUPDATE) 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:
| Keunggulan: query_body mendukung kueri SQL apa pun. |
Keterbatasan: Hanya mendukung pembaruan batch penuh. | ||
Fast refresh | Skenario Real-Time:
| Keunggulan:
|
Keterbatasan:
|
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 VIEWsecara 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_mv1dengan refresh lengkap. Karena tidak menentukan pemicu refresh atau parameterNEXT, 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_mv2dengan 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_mv3dengan refresh lengkap dan dikonfigurasi untuk refresh yang dipicu overwrite (ON OVERWRITE). Mode ini tidak memerlukan klausaNEXT.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;Operasi
INSERT OVERWRITE INTOdanTRUNCATEdidukung 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;danALTER TABLE <table_name> binlog=false;.
Tampilan yang di-materialisasi satu tabel
Buat tampilan yang di-materialisasi satu tabel
fast_mv1dengan 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_mv2berbasis 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_mv3berbasis 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_mv4dengan 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_mv5dengan 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 OVERWRITEdanTRUNCATEtidak 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_bodytampilan 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 VIEWakan mengembalikan error.Kondisi tidak boleh mengandung ekspresi non-deterministik, seperti
now()ataurand().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 VIEWmv_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
Buat tampilan yang di-materialisasi: Menjelaskan kasus penggunaan, fitur utama, dan keterbatasan tampilan yang di-materialisasi.
CREATE MATERIALIZED VIEW: Menyediakan sintaks lengkap.
Kelola tampilan yang di-materialisasi: Menjelaskan cara menanyakan definisi tampilan yang di-materialisasi, menanyakan catatan refresh, mengubah tampilan yang di-materialisasi, dan menghapus tampilan yang di-materialisasi.