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 DynamoDB zero ETL - integrasi dan Layanan OpenSearch
DynamoDB memiliki DynamoDB nol- integrasi dengan Amazon Service. ETL 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
dantemplate_content
) sertainclude_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 nilaidocument_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 pengaturanaction
. 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 streamingdynamodb_event_name
untuk kasus penggunaan seperti pemfilteran. Namun, biasanya hal ini tidak digunakan untuk pengaturanaction
.
Observabilitas
-
Selalu gunakan antrian huruf mati (DLQ) di OpenSearch wastafel Anda untuk menangani peristiwa yang dijatuhkan. 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 pada 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, sebaiknya setelan OCUs berdasarkan unit kapasitas tulis (WCUs) Anda dibagi 1000. Tetapkan minimum ke 1 OCU di bawah jumlah itu (tetapi setidaknya 1), dan atur maksimum ke setidaknya 1 OCU di atas jumlah itu.
-
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 AndaWCUs, dibagi dengan 1000. Tetapkan minimum ke 1 OCU di bawah minimum dari DynamoDB, dan atur maksimum ke minimal OCU 1 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. Tetapkan minimum ke 1 OCU di bawah minimum dari DynamoDB, dan atur maksimum ke minimal OCU 1 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 SQL fungsi yang, diberikan satu set argumen, mengembalikan argumen dengan nilai terbesar.