All Products
Search
Document Center

PolarDB:Konfigurasi parameter AutoETL dan kasus penggunaan

Last Updated:Mar 26, 2026

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

esl_sql_options

Menentukan parameter ETL SQL yang mengontrol perilaku runtime pipeline sinkronisasi search view.

esl_source_options

Menentukan parameter sinkronisasi untuk tabel sumber MySQL yang mengontrol cara data dibaca.

esl_sink_options

Menentukan parameter sinkronisasi untuk tabel sink PolarSearch yang mengontrol cara data ditulis ke indeks.

Catatan

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.

  1. 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}');
  2. 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\"}"
                }
            }
        ]
    }
  3. Simpan sebagai tipe bersarang

    Gunakan parameter sink.json-flatten.fields untuk 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"
                    }
                }
            }
        ]
    }
  4. Simpan dalam Mode Flatten

    Atur parameter sink.json-flatten.mode ke flatten untuk 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 name dan age dari 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.

Penting

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;