AutoETL menyediakan sejumlah variabel sesi untuk mengonfigurasi perilaku sinkronisasi lanjutan saat membuat search view, seperti konversi field JSON, routing pencarian, dan mode penulisan. Topik ini menjelaskan cara menggunakan parameter tersebut beserta contoh kasus penggunaannya.
Parameter
Sebelum membuat search view, gunakan pernyataan SET untuk mengatur variabel sesi berikut guna mengonfigurasi perilaku sinkronisasi. Pengaturan ini berlaku untuk semua search view yang dibuat dalam sesi saat ini.
Parameter | Deskripsi |
| Menentukan parameter ETL SQL yang mengontrol perilaku runtime pipeline sinkronisasi search view. |
| Menentukan parameter sinkronisasi untuk tabel sumber MySQL yang mengontrol cara data dibaca. |
| Menentukan parameter sinkronisasi untuk tabel sink PolarSearch yang mengontrol cara data ditulis ke indeks. |
Variabel sesi hanya berlaku selama sesi berlangsung. Namun, setiap search view yang dibuat dengan variabel tersebut akan menyimpan konfigurasinya secara permanen, bahkan setelah sesi ditutup.
Kasus penggunaan
Konversi field JSON
Jika tabel sumber berisi field JSON, AutoETL secara default menyimpannya sebagai string di PolarSearch. Anda dapat menggunakan parameter esl_sink_options untuk mengonfigurasi cara field JSON tersebut dikonversi.
Persiapkan Data
CREATE DATABASE IF NOT EXISTS db3; USE db3; CREATE TABLE IF NOT EXISTS t1 ( id INT PRIMARY KEY, c1 JSON ); INSERT INTO t1 VALUES (1, '{"name": "Alice", "age": 30}'); INSERT INTO t1 VALUES (2, '{"name": "Bob", "age": 25}');Perilaku Default (Disimpan sebagai String)
Jika tidak mengatur parameter apa pun, field JSON akan disimpan sebagai string di PolarSearch.
CREATE SEARCH VIEW view_json_default AS SELECT * FROM db3.t1;Verifikasi data (hasil sebagian):
{ "hits": [ { "_index": "view_json_default", "_id": "2", "_score": 1, "_source": { "id": 2, "c1": "{\"age\":25,\"name\":\"Bob\"}" } }, { "_index": "view_json_default", "_id": "1", "_score": 1, "_source": { "id": 1, "c1": "{\"age\":30,\"name\":\"Alice\"}" } } ] }Simpan sebagai tipe bersarang
Gunakan parameter
sink.json-flatten.fieldsuntuk menentukan field JSON yang akan dikonversi ke tipe nested. Pisahkan beberapa nama field dengan titik koma (;).SET esl_sink_options = "'sink.json-flatten.fields' = 'c1'"; CREATE SEARCH VIEW view_json_nested AS SELECT * FROM db3.t1;Verifikasi data (hasil sebagian):
{ "hits": [ { "_index": "view_json_nested", "_id": "1", "_score": 1, "_source": { "id": 1, "c1": { "age": 30, "name": "Alice" } } }, { "_index": "view_json_nested", "_id": "2", "_score": 1, "_source": { "id": 2, "c1": { "age": 25, "name": "Bob" } } } ] }Simpan dalam Mode Flatten
Atur parameter
sink.json-flatten.modekeflattenuntuk meratakan field JSON menjadi field tingkat atas yang terpisah.SET esl_sink_options = "'sink.json-flatten.fields' = 'c1', 'sink.json-flatten.mode' = 'flatten'"; CREATE SEARCH VIEW view_json_flatten AS SELECT * FROM db3.t1;Verifikasi data (hasil sebagian): Dalam mode flatten, kunci
namedanagedari objek JSON diratakan menjadi field tingkat atas yang independen dalam indeks PolarSearch.{ "hits": [ { "_index": "view_json_flatten", "_id": "2", "_score": 1, "_source": { "id": 2, "name": "Bob", "age": 25 } }, { "_index": "view_json_flatten", "_id": "1", "_score": 1, "_source": { "id": 1, "name": "Alice", "age": 30 } } ] }
Bidang routing pencarian
Gunakan parameter routing-fields untuk menentukan satu atau beberapa bidang routing untuk indeks PolarSearch. Sebuah dokumen disimpan pada shard yang ditentukan oleh nilai bidang routing tersebut. Praktik ini mengoptimalkan performa kueri saat melakukan filter berdasarkan bidang tersebut. Pisahkan beberapa bidang dengan titik koma (;).
Persiapkan Data
CREATE DATABASE IF NOT EXISTS db4;
USE db4;
CREATE TABLE IF NOT EXISTS t1 (
id INT PRIMARY KEY,
c1 VARCHAR(100),
c2 VARCHAR(100)
);
INSERT INTO t1(id, c1, c2) VALUES
(1, 'apple', 'red'),
(2, 'banana', 'yellow'),
(3, 'grape', 'purple');Contoh
Buat search view yang menggunakan field c1 sebagai bidang routing:
SET esl_sink_options = "'routing-fields' = 'c1'";
CREATE SEARCH VIEW view_routing AS SELECT * FROM db4.t1;Abaikan operasi delete
Dalam skenario penggabungan tabel multipel, search view menggunakan strategi delete-then-insert untuk memperbarui indeks PolarSearch. Untuk mencegah kueri gagal menemukan data selama pembaruan singkat ini, Anda dapat mengatur parameter ignore-delete ke true agar melewatkan operasi delete.
Mengabaikan operasi delete dapat menyebabkan pembengkakan data di indeks PolarSearch. Praktik terbaik adalah menggunakan flag soft delete di tabel sumber, seperti field is_deleted, dan menerapkan strategi pembersihan berkala.
Contoh
SET esl_sink_options = "'ignore-delete' = 'true'";
CREATE SEARCH VIEW view_no_delete AS SELECT t1.id, t1.c1, t2.c2 FROM db3.t1 AS t1 JOIN db2.t2 AS t2 ON t1.id = t2.id;Mode penulisan replacement
Secara default, search view menggunakan mode update untuk menulis data ke PolarSearch, hanya memperbarui field yang dimodifikasi. Untuk menggunakan mode replacement (juga dikenal sebagai mode index), yang mengganti seluruh dokumen pada setiap penulisan, atur parameter sink.force-index-request ke true.
Perbandingan Kedua Mode
Fitur | Update mode (default) | Mode replacement |
Metode penulisan | Hanya memperbarui field yang dimodifikasi. | Mengganti seluruh dokumen. |
Kasus penggunaan | Ideal saat menyinkronkan subset field dari tabel sumber, karena mempertahankan nilai field yang tidak disinkronkan di indeks. | Ideal saat menyinkronkan semua field dari tabel sumber atau ketika Anda harus memastikan dokumen di PolarSearch persis sesuai dengan data sumber. |
Contoh
SET esl_sink_options = "'sink.force-index-request' = 'true'";
CREATE SEARCH VIEW view_replace AS SELECT * FROM db3.t1;