Saat Anda menambahkan atau memperbarui record di sumber data, perubahan tersebut harus mencapai mesin OpenSearch agar dapat ditemukan dalam hasil pencarian. OpenSearch menyinkronkan data inkremental secara real-time melalui pipeline tiga tahap: dari sumber data ke aplikasi offline, dari aplikasi offline ke tabel lebar, dan dari aplikasi offline ke mesin pencarian. Batas laju pada setiap tahap melindungi mesin dan menjaga latensi tabel utama tetap rendah.
Pilih jalur pengambilan aliran
Data inkremental memasuki pipeline melalui salah satu dari dua jalur berikut:
| Jalur | Cara kerjanya | Kapan menggunakannya |
|---|---|---|
| Berlangganan log biner melalui DTS | Data Transmission Service (DTS) berlangganan log biner dari sumber data Anda dan mengalirkan perubahan ke aplikasi offline OpenSearch. | Sumber data Anda adalah database relasional, dan Anda menginginkan penangkapan perubahan otomatis dengan latensi rendah tanpa mengubah kode aplikasi Anda. |
| Dorong data menggunakan API | Aplikasi Anda mengirim data langsung ke aplikasi offline OpenSearch melalui panggilan API. | Anda menghasilkan data di luar database, memproses data sebelum diindeks, atau membutuhkan kontrol detail halus atas record mana yang diindeks. |
Kedua jalur tersebut mengalir ke pipeline tiga tahap yang sama.
Cara kerja pipeline
Tahap 1: Sumber data ke aplikasi offline
DTS berlangganan log biner dari sumber data Anda dan mengalirkan perubahan ke aplikasi offline. Jika Anda menggunakan jalur API, aplikasi Anda mendorong data langsung ke aplikasi offline. Dalam kedua kasus tersebut, total transaksi per detik (TPS) gabungan dari tabel utama dan semua tabel secondary tidak boleh melebihi 1.500 TPS.
Tahap 2: Aplikasi offline ke tabel lebar
Aplikasi offline menggabungkan perubahan masuk ke dalam tabel lebar yang sudah ada. Saat pembaruan tabel secondary memicu pembaruan pada tabel utama dan pembaruan yang dipicu tersebut mencapai atau melebihi 1.000 TPS, sistem melakukan pengendalian aliran terhadap pembaruan tabel secondary. Hal ini menjaga latensi sinkronisasi tabel utama tetap rendah.
Untuk detail tentang bagaimana penggabungan tabel ganda memengaruhi latensi, lihat Latensi sinkronisasi data yang disebabkan oleh penggabungan tabel ganda.
Tahap 3: Aplikasi offline ke mesin
Aplikasi offline menulis data gabungan ke mesin OpenSearch. Karena metadata ditambahkan selama tahap ini, volume data yang mencapai mesin bisa mencapai dua hingga tiga kali lipat dari data sumber aslinya. Untuk melindungi mesin, kecepatan penulisan dibatasi maksimal 10 MB/s.
Batasan
| Metrik | Batas | Alasan batasan ini ada |
|---|---|---|
| Total TPS dari sumber data ke aplikasi offline (gabungan tabel utama dan tabel secondary, tanpa hubungan pemicu yang dikonfigurasi) | 1.500 TPS | Kapasitas pengambilan aliran hulu dari aplikasi offline |
| Kecepatan penulisan dari aplikasi offline ke mesin | 10 MB/s | Penambahan metadata memperluas data menjadi 2–3x ukuran aslinya; batas ini melindungi mesin dari kelebihan beban |
| Pembaruan tabel utama yang dipicu oleh pembaruan tabel secondary | 1.000 TPS | Di atas ambang batas ini, kecepatan pembaruan tabel secondary dikurangi untuk menjaga latensi tabel utama tetap rendah |
Jika Anda memperkirakan workload akan mendekati batasan ini, pantau TPS dan volume data sebelum peluncuran. Hubungi dukungan Alibaba Cloud untuk membahas opsi jika kebutuhan Anda melebihi nilai default.
Atasi kegagalan sinkronisasi
Jika sumber data Anda gagal menyinkronkan dengan OpenSearch, ikuti langkah-langkah berikut untuk mengidentifikasi penyebab dan memulihkan sinkronisasi:
Pemeriksaan Konsol
Periksa latensi sinkronisasi: Di Konsol Cloud Monitor, buka metrik dan Pusat Insiden. Temukan metrik Application Real-time Processing Latency (
app_realtime_write_latency) untuk OpenSearch (opensearch), diukur dalam milidetik, dan gunakan untuk menilai keterlambatan sinkronisasi tabel utama.Periksa status tugas DTS: Di Konsol DTS, lihat daftar tugas sinkronisasi data untuk memastikan status berjalan dan tahap saat ini (sinkronisasi skema, sinkronisasi penuh, atau sinkronisasi inkremental).
Periksa penggunaan penyimpanan: Di halaman Instance Management di Konsol OpenSearch, periksa kolom Storage Used (GB). Saat penyimpanan penuh, sinkronisasi otomatis berhenti.
Validasi data
Bandingkan data kunci utama: Lakukan kueri nilai kunci utama yang sama di database dan OpenSearch, lalu bandingkan hasilnya untuk memastikan konsistensi.
Konfirmasi konsistensi konfigurasi: Di halaman Langkah 3: Data Source pada wizard konfigurasi instans, pastikan ID instans RDS, database, dan nama tabel sesuai dengan konfigurasi langganan DTS.
Periksa set karakter: DTS tidak mendukung set karakter utf8mb3. Gunakan utf8mb4 sebagai gantinya.
Pemulihan
Buat ulang indeks: Jika penyimpanan penuh, buat ulang indeks dan jalankan impor data penuh. Untuk informasi lebih lanjut, lihat dokumentasi sinkronisasi real-time DTS dan dokumentasi konfigurasi sumber data.