Praktik terbaik untuk bekerja dengan integrasi dan Layanan DynamoDB Zero-ETL OpenSearch - Amazon DynamoDB
KonfigurasiObservabilitasPenskalaan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk bekerja dengan integrasi dan Layanan DynamoDB Zero-ETL OpenSearch

DynamoDB memiliki integrasi DynamoDB Zero-ETL dengan Amazon Service. OpenSearch Untuk informasi selengkapnya, lihat plugin DynamoDB untuk Penyerapan dan praktik terbaik khusus OpenSearch untuk Layanan Amazon. OpenSearch

Konfigurasi

  • Anda hanya perlu melakukan pencarian pada indeks data. Selalu gunakan templat pemetaan (template_type: index_template dan template_content) serta include_keys untuk mengimplementasikan hal ini.

  • Pantau log Anda untuk kesalahan yang terkait dengan konflik tipe. OpenSearch Layanan mengharapkan semua nilai untuk kunci yang diberikan memiliki tipe yang sama. Pengecualian dihasilkan jika ada ketidakcocokan. Jika Anda menemukan salah satu kesalahan ini, Anda dapat menambahkan prosesor untuk mengetahui bahwa kunci yang diberikan selalu memiliki nilai yang sama.

  • Secara umum, gunakan nilai metadata primary_key untuk nilai document_id. Dalam OpenSearch Layanan, ID dokumen setara dengan kunci utama di DynamoDB. Menggunakan kunci primer akan memudahkan dokumen Anda ditemukan dan memastikan bahwa pembaruan secara konsisten direplikasi tanpa konflik.

    Anda dapat menggunakan fungsi pembantu getMetadata untuk mendapatkan kunci primer Anda (misalnya, document_id: "${getMetadata('primary_key')}"). Jika Anda menggunakan kunci primer komposit, fungsi pembantu akan menggabungkannya bersama-sama untuk Anda.

  • Secara umum, gunakan nilai metadata opensearch_action untuk pengaturan action. Ini akan memastikan bahwa pembaruan direplikasi sedemikian rupa sehingga data di OpenSearch Layanan cocok dengan status terbaru di DynamoDB.

    Anda dapat menggunakan fungsi pembantu getMetadata untuk mendapatkan kunci primer Anda (misalnya, action: "${getMetadata('opensearch_action')}"). Anda juga bisa mendapatkan jenis peristiwa streaming dynamodb_event_name untuk kasus penggunaan seperti pemfilteran. Namun, biasanya hal ini tidak digunakan untuk pengaturan action.

Observabilitas

  • Selalu gunakan antrian huruf mati (DLQ) di OpenSearch wastafel Anda untuk menangani peristiwa yang jatuh. DynamoDB umumnya kurang terstruktur OpenSearch daripada Layanan, dan selalu mungkin terjadi sesuatu yang tidak terduga. Dengan antrean surat mati, Anda dapat memulihkan peristiwa individual, dan bahkan mengotomatiskan proses pemulihan. Hal ini akan membantu agar Anda tidak perlu membangun kembali seluruh indeks Anda.

  • Selalu atur peringatan agar penundaan replikasi Anda tidak melebihi jumlah yang diharapkan. Biasanya aman untuk mengasumsikan satu menit tanpa peringatan yang terlalu berisik. Ini dapat bervariasi tergantung pada seberapa runcing lalu lintas tulis Anda dan pengaturan OpenSearch Compute Unit (OCU) Anda di pipeline.

    Jika penundaan replikasi Anda melebihi 24 jam, aliran Anda akan mulai kehilangan peristiwa, dan Anda akan mengalami masalah akurasi kecuali jika Anda melakukan pembangunan ulang indeks Anda dari awal.

Penskalaan

  • Gunakan penskalaan otomatis untuk saluran pipa untuk membantu meningkatkan atau menurunkan skala OCUs agar sesuai dengan beban kerja.

  • Untuk tabel throughput yang disediakan tanpa penskalaan otomatis, kami sarankan pengaturan OCUs berdasarkan unit kapasitas tulis (WCUs) Anda dibagi 1000. Tetapkan minimum ke 1 OCU di bawah jumlah tersebut (tetapi setidaknya 1), dan atur maksimum ke setidaknya 1 OCU di atas jumlah tersebut.

    • Rumus:

      OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
OCU_maximum = (table_WCU / 1000) + 1

    • Contoh: Tabel Anda memiliki 25000 yang WCUs disediakan. Pipa Anda OCUs harus diatur dengan minimal 24 (25000/1000 - 1) dan maksimum minimal 26 (25000/1000 + 1).

  • Untuk tabel throughput yang disediakan dengan penskalaan otomatis, kami merekomendasikan pengaturan OCUs berdasarkan minimum dan maksimum Anda WCUs, dibagi dengan 1000. Atur minimum ke 1 OCU di bawah minimum dari DynamoDB, dan atur maksimum ke setidaknya 1 OCU di atas maksimum dari DynamoDB.

    • Rumus:

      OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1)
OCU_maximum = (table_maximum_WCU / 1000) + 1

    • Contoh: Tabel Anda memiliki kebijakan penskalaan otomatis dengan minimum 8000 dan maksimum 14000. Pipa Anda OCUs harus diatur dengan minimal 7 (8000/1000 - 1) dan maksimum 15 (14000/1000 + 1).

  • Untuk tabel throughput sesuai permintaan, kami merekomendasikan pengaturan OCUs berdasarkan puncak dan lembah khas Anda untuk unit permintaan tulis per detik. Anda mungkin perlu membuat rata-rata dalam jangka waktu yang lebih lama, tergantung pada agregasi yang tersedia untuk Anda. Atur minimum ke 1 OCU di bawah minimum dari DynamoDB, dan atur maksimum ke setidaknya 1 OCU di atas maksimum dari DynamoDB.

    • Rumus:

      # Assuming we have writes aggregated at the minute level
OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1)
OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1

    • Contoh: Tabel Anda memiliki penurunan rata-rata 300 unit permintaan tulis per detik dan puncak rata-rata 4300. Pipa Anda OCUs harus diatur dengan minimal 1 (300/1000 - 1, tetapi setidaknya 1) dan maksimum 5 (4300/1000 + 1).

  • Ikuti praktik terbaik dalam penskalaan indeks OpenSearch Layanan tujuan Anda. Jika penskalaan indeks Anda kurang, ini akan memperlambat konsumsi dari DynamoDB, dan dapat menyebabkan penundaan.

catatan

GREATEST adalah fungsi SQL yang, jika diberikan sekumpulan argumen, mengembalikan argumen dengan nilai terbesar.