Praktik terbaik untuk Amazon DocumentDB

Pelajari praktik terbaik untuk bekerja dengan Amazon DocumentDB (dengan kompatibilitas MongoDB). Bagian ini terus diperbarui saat praktik terbaik baru diidentifikasi.

Pedoman operasional dasar

Berikut ini adalah panduan operasional dasar yang harus diikuti setiap orang saat bekerja dengan Amazon DocumentDB. Perjanjian Tingkat Layanan Amazon DocumentDB mewajibkan Anda untuk mengikuti panduan berikut ini.

• Men-deploy klaster yang terdiri dari dua atau lebih instans Amazon DocumentDB di dua Availability Zone AWS . Untuk beban kerja produksi, gunakan cluster yang terdiri dari tiga instans Amazon DocumentDB atau lebih di tiga Zona Ketersediaan.

• Gunakan layanan dalam kuota layanan yang dinyatakan. Untuk informasi selengkapnya, lihat Kuota Amazon DocumentDB.

• Memantau memori, CPU, koneksi, dan penggunaan penyimpanan Anda. Untuk membantu Anda mempertahankan kinerja dan ketersediaan sistem, atur Amazon CloudWatch untuk memberi tahu Anda ketika pola penggunaan berubah atau ketika Anda mendekati kapasitas penerapan Anda.

• Menaikkan skala instans Anda saat Anda mendekati batas kapasitas. Instans Anda harus disediakan dengan sumber daya komputasi yang cukup (yaitu, RAM, CPU) untuk mengakomodasi peningkatan permintaan yang tidak terduga dari aplikasi Anda.

• Atur periode retensi cadangan agar selaras dengan tujuan titik pemulihan Anda.

• Tes failover untuk klaster Anda untuk memahami berapa lama proses untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat Failover Amazon DocumentDB.

• Hubungkan ke klaster Amazon DocumentDB Anda dengan titik akhir klaster (lihat Titik akhir Amazon DocumentDB) dan dalam mode set replika (lihat Menghubungkan ke Amazon DocumentDB sebagai kumpulan replika) untuk meminimalkan dampak failover pada aplikasi Anda.

• Pilih pengaturan preferensi baca driver yang memaksimalkan penskalaan baca sekaligus memenuhi persyaratan konsistensi baca aplikasi Anda. Preferensi baca secondaryPreferred mengaktifkan pembacaan replika dan membebaskan instans primer untuk melakukan lebih banyak pekerjaan. Untuk informasi selengkapnya, lihat Baca opsi preferensi.

• Rancang aplikasi Anda agar menjadi tangguh jika terjadi peristiwa kesalahan jaringan dan basis data. Gunakan mekanisme kesalahan driver Anda untuk membedakan antara kesalahan sementara dan kesalahan terus-menerus. Coba lagi kesalahan sementara menggunakan mekanisme backoff eksponensial bila sesuai. Pastikan bahwa aplikasi Anda mempertimbangkan konsistensi data ketika menerapkan logika coba lagi.

• Aktifkan perlindungan penghapusan klaster untuk semua klaster produksi, atau klaster mana pun yang memiliki data berharga. Sebelum menghapus klaster Amazon DocumentDB, ambil snapshot akhir. Jika Anda menyebarkan sumber daya dengan CloudFormation, aktifkan perlindungan penghentian. Untuk informasi selengkapnya, lihat Perlindungan penghentian dan perlindungan penghapusan.

• Saat membuat cluster Amazon DocumentDB, ini --engine-version adalah parameter opsional yang default ke versi engine utama terbaru. Versi mesin default saat ini adalah 5.0.0 (catatan: Amazon DocumentDB 8.0 tersedia tetapi harus ditentukan secara eksplisit). Ketika versi mesin utama baru dirilis, versi mesin default untuk --engine-version akan diperbarui untuk mencerminkan versi mesin utama terakhir. Akibatnya, untuk beban kerja produksi, dan terutama yang bergantung pada scripting, otomatisasi, atau CloudFormation templat, secara eksplisit menentukan --engine-version ke versi utama yang dimaksud.

Ukuran instans

Salah satu aspek terpenting dalam memilih ukuran instans di Amazon DocumentDB adalah jumlah RAM untuk cache Anda. Amazon DocumentDB mencadangkan sepertiga RAM untuk layanannya sendiri, artinya hanya dua pertiga dari RAM instans yang tersedia untuk cache. Dengan demikian, itu adalah praktik terbaik Amazon DocumentDB untuk memilih tipe instans dengan RAM yang cukup agar sesuai dengan set kerja Anda (yaitu, data dan indeks) dalam memori. Memiliki instans berukuran tepat akan membantu mengoptimalkan kinerja keseluruhan dan berpotensi meminimalkan I/O biaya. Anda dapat menggunakan kalkulator ukuran Amazon DocumentDB pihak ketiga untuk memperkirakan ukuran instance untuk beban kerja tertentu.

Untuk menentukan apakah set kerja aplikasi Anda cocok dengan memori, pantau BufferCacheHitRatio penggunaan Amazon CloudWatch untuk setiap instans dalam cluster yang sedang dimuat.

Met BufferCacheHitRatio CloudWatch rik mengukur persentase data dan indeks yang disajikan dari cache memori instance (versus volume penyimpanan). Secara umum, nilai BufferCacheHitRatio harus setinggi mungkin, karena membaca data dari memori set kerja lebih cepat dan lebih hemat biaya daripada membaca dari volume penyimpanan. Selagi itu diinginkan untuk menjaga BufferCacheHitRatio sedekat mungkin dengan 100%, nilai terbaik yang dapat dicapai akan tergantung pada pola akses dan persyaratan performa aplikasi Anda. Untuk mempertahankan BufferCacheHitRatio setinggi mungkin, dianjurkan agar instans di klaster Anda disediakan dengan RAM yang cukup untuk dapat menyesuaikan indeks dan set data kerja dalam memori.

Jika indeks Anda tidak sesuai dengan memori, Anda akan melihat BufferCacheHitRatio yang lebih rendah. Terus membaca dari disk menimbulkan I/O biaya tambahan dan tidak lebih baik daripada membaca dari memori. Jika rasio BufferCacheHitRatio Anda lebih rendah dari yang diharapkan, tingkatkan ukuran instans untuk klaster Anda guna menyediakan lebih banyak RAM untuk menyesuaikan data set kerja dalam memori. Jika menskalakan ke atas kelas instans menghasilkan peningkatan dramatis dalam BufferCacheHitRatio, maka set kerja aplikasi anda tidak sesuai di memori. Lanjutkan untuk menaikkan skala sampai BufferCacheHitRatio tidak lagi meningkat secara dramatis setelah operasi penskalaan. Untuk informasi tentang pemantauan metrik instans, lihat Metrik Amazon DocumentDB.

Tergantung pada beban kerja dan persyaratan latensi Anda, itu mungkin dapat diterima untuk aplikasi Anda untuk memiliki nilai BufferCacheHitRatio yang lebih tinggi selama penggunaan kondisi stabil, tetapi memiliki penurunan BufferCacheHitRatio secara berkala arena kueri analitik yang perlu memindai seluruh koleksi dijalankan pada instans. Penurunan periodik dalam BufferCacheHitRatio dapat bermanifestasi sebagai latensi yang lebih tinggi untuk kueri berikutnya yang perlu untuk mengisi ulang data set kerja dari volume penyimpanan kembali ke cache buffer. Uji beban kerja Anda di lingkungan pra-produksi dengan beban kerja produksi yang representatif terlebih dahulu untuk memahami karakteristik kinerja dan BufferCacheHitRatio sebelum menerapkan beban kerja ke produksi.

BufferCacheHitRatio adalah metrik khusus instans, jadi instans yang berbeda dalam klaster yang sama mungkin memiliki nilai-nilai BufferCacheHitRatio yang berbeda tergantung pada cara pembacaan didistribusikan di antara instans primer dan replika. Jika beban kerja operasional Anda tidak dapat menangani peningkatan periodik latensi dari mengisi ulang cache set kerja setelah menjalankan kueri analitik, Anda harus mencoba untuk mengisolasi cache buffer beban kerja reguler dari kueri analitik. Anda dapat mencapai isolasi BufferCacheHitRatio lengkap dengan mengarahkan kueri operasional ke instans primer dan kueri analitik hanya ke instans replika. Anda juga dapat mencapai isolasi parsial dengan mengarahkan kueri analitik ke instans replika tertentu dengan pemahaman bahwa beberapa persentase kueri reguler juga akan berjalan pada replika tersebut dan berpotensi terpengaruh.

Nilai BufferCacheHitRatio yang sesuai tergantung pada kasus penggunaan dan persyaratan aplikasi Anda. Tidak ada satu nilai terbaik atau minimum untuk metrik ini; hanya Anda yang dapat memutuskan apakah tradeoff dari BufferCacheHitRatio yang sementara lebih rendah dapat diterima dari perspektif biaya dan performa.

Bekerja dengan indeks

Indeks bangunan

Ketika mengimpor data ke Amazon DocumentDB, Anda harus membuat indeks Anda sebelum mengimpor set data besar. Anda dapat menggunakan Alat Indeks Amazon DocumentDB untuk mengekstrak indeks dari instans MongoDB atau direktori mongodump yang sedang berjalan, dan membuat indeks tersebut di klaster Amazon DocumentDB. Untuk panduan lebih lanjut tentang migrasi, lihat Migrasi dan upgrade Amazon DocumentDB.

Selektivitas indeks

Batasi pembuatan indeks ke bidang di mana jumlah nilai duplikat kurang dari 1% dari jumlah total dokumen dalam koleksi. Sebagai contoh, jika pengumpulan Anda berisi 100.000 dokumen, buat indeks hanya pada bidang tempat nilai yang sama muncul 1000 kali atau kurang.

Memilih indeks dengan jumlah nilai unik yang tinggi (yaitu, kardinalitas tinggi) memastikan bahwa operasi filter mengembalikan sejumlah kecil dokumen, sehingga menghasilkan performa yang baik selama pemindaian indeks. Contoh indeks kardinalitas tinggi adalah indeks unik, yang menjamin bahwa predikat kesetaraan mengembalikan paling banyak satu dokumen. Contoh kardinalitas rendah termasuk indeks di atas bidang Boolean dan indeks di atas hari dalam seminggu. Karena performanya yang buruk, indeks kardinalitas rendah tidak mungkin dipilih oleh pengoptimal kueri basis data. Pada saat yang sama, indeks kardinalitas rendah terus mengkonsumsi sumber daya seperti ruang disk dan. I/Os Sebagai aturan praktis, Anda harus menargetkan indeks pada bidang di mana frekuensi nilai khas adalah 1% dari total ukuran koleksi atau kurang.

Selain itu, direkomendasikan untuk hanya membuat indeks pada bidang yang umumnya digunakan sebagai filter dan secara teratur mencari indeks yang tidak terpakai. Untuk informasi selengkapnya, lihat Bagaimana cara menganalisis penggunaan indeks dan mengidentifikasi indeks yang tidak digunakan?.

Dampak indeks pada penulisan data

Meskipun indeks dapat meningkatkan performa kueri dengan menghindari kebutuhan untuk memindai setiap dokumen dalam koleksi, peningkatan ini disertai dengan tradeoff. Untuk setiap indeks pada koleksi, setiap kali dokumen dimasukkan, diperbarui, atau dihapus, basis data harus memperbarui koleksi dan menulis bidang untuk masing-masing indeks untuk koleksi. Sebagai contoh, jika koleksi memiliki sembilan indeks, basis data harus melakukan sepuluh penulisan sebelum mengakui operasi ke klien. Dengan demikian, setiap indeks tambahan menimbulkan latensi tulis tambahan, I/O dan peningkatan penyimpanan yang digunakan secara keseluruhan.

Instans klaster harus berukuran tepat untuk menjaga semua memori set kerja. Ini menghindari kebutuhan untuk terus membaca halaman indeks dari volume penyimpanan, yang berdampak negatif pada kinerja dan menghasilkan I/O biaya yang lebih tinggi. Untuk informasi selengkapnya, lihat Ukuran instans.

Untuk performa terbaik, meminimalkan jumlah indeks dalam koleksi Anda, tambahkan hanya indeks yang diperlukan untuk meningkatkan performa untuk kueri umum. Meskipun beban kerja bervariasi, pedoman yang baik adalah untuk menjaga jumlah indeks per koleksi menjadi lima atau lebih sedikit.

Mengidentifikasi indeks yang hilang

Sebagai praktik terbaik, identifikasi indeks yang hilang secara teratur. Untuk informasi selengkapnya, lihat Bagaimana cara mengidentifikasi indeks yang hilang?.

Mengidentifikasi indeks yang tidak digunakan

Sebagai praktik terbaik, identifikasi dan hapus indeks yang tidak digunakan secara teratur. Untuk informasi selengkapnya, lihat Bagaimana cara menganalisis penggunaan indeks dan mengidentifikasi indeks yang tidak digunakan?.

Praktik terbaik keamanan

Untuk praktik terbaik keamanan untuk Amazon DocumentDB, lihatPraktik terbaik keamanan untuk Amazon DocumentDB.

Optimalisasi biaya

Praktik terbaik berikut dapat membantu Anda mengelola dan meminimalkan biaya Anda ketika menggunakan Amazon DocumentDB. Untuk informasi harga, lihat Harga Amazon DocumentDB (dengan kompatibilitas MongoDB) dan FAQ Amazon DocumentDB (dengan kompatibilitas MongoDB).

• Buat pemberitahuan penagihan pada ambang batas 50 persen dan 75 persen dari tagihan yang Anda harapkan untuk bulan tersebut. Untuk informasi selengkapnya tentang membuat pemberitahuan penagihan, lihat Membuat Alarm Penagihan.

• Arsitektur Amazon DocumentDB memisahkan penyimpanan dan komputasi, sehingga klaster instans tunggal pun sangat berdaya tahan. Volume penyimpanan klaster mereplikasi data enam cara di tiga Availability Zone, menyediakan daya tahan yang sangat tinggi terlepas dari jumlah instans dalam klaster. Klaster produksi khas memiliki tiga atau lebih instans untuk menyediakan ketersediaan tinggi. Namun, Anda dapat mengoptimalkan biaya dengan menggunakan klaster pengembangan instans tunggal ketika ketersediaan tinggi tidak diperlukan.

• Untuk skenario pengembangan dan pengujian, hentikan klaster ketika tidak lagi diperlukan dan mulai klaster ketika pengembangan dilanjutkan. Untuk informasi selengkapnya, lihat Menghentikan dan memulai cluster Amazon DocumentDB.

• TTL dan aliran perubahan muncul saat data I/O ditulis, dibaca, dan dihapus. Jika Anda telah mengaktifkan fitur ini tetapi tidak memanfaatkannya dalam aplikasi Anda, menonaktifkan fitur tersebut dapat membantu mengurangi biaya.

Menggunakan metrik untuk mengidentifikasi masalah performa

Topik

• Melihat metrik performa

• Mengatur CloudWatch alarm

• Mengevaluasi metrik performa

• Mengevaluasi penggunaan instans Amazon DocumentDB dengan metrik CloudWatch

• Menyetel kueri

Untuk mengidentifikasi masalah performa yang disebabkan sumber daya yang tidak mencukupi dan kemacetan umum lainnya, Anda dapat memantau metrik yang tersedia untuk klaster Amazon DocumentDB.

Melihat metrik performa

Pantau metrik kinerja secara rutin untuk melihat nilai rata-rata, maksimum, dan minimum untuk berbagai rentang waktu. Hal ini membantu Anda mengidentifikasi saat performa menurun. Anda juga dapat mengatur CloudWatch alarm Amazon untuk ambang batas metrik tertentu sehingga Anda akan diberitahu jika tercapai.

Untuk memecahkan masalah kinerja, penting untuk memahami kinerja dasar sistem. Setelah Anda menyiapkan klaster baru dan menjalankannya dengan beban kerja tipikal, tangkap nilai rata-rata, maksimum, dan minimum dari semua metrik kinerja pada interval yang berbeda (misalnya, 1 jam, 24 jam, 1 minggu, 2 minggu). Ini memberi Anda gambaran tentang apa yang normal. Sehingga membantu mendapatkan perbandingan untuk jam sibuk dan tidak sibuk. Kemudian, Anda dapat menggunakan informasi ini untuk mengidentifikasi saat performa turun di bawah tingkat standar.

Anda dapat melihat metrik kinerja menggunakan Konsol Manajemen AWS atau AWS CLI. Untuk informasi selengkapnya, lihat Melihat CloudWatch data.

Mengatur CloudWatch alarm

Untuk menyet CloudWatch el alarm, lihat Menggunakan CloudWatch Alarm Amazon di Panduan CloudWatch Pengguna Amazon.

Mengevaluasi metrik performa

Instans memiliki beberapa kategori metrik yang berbeda. Cara Anda menentukan nilai yang dapat diterima tergantung pada metrik.

CPU

• Pemanfaatan CPU — Persentase kapasitas pemrosesan komputer yang digunakan.

Memori

• Memori yang Bisa Dibebaskan — Berapa banyak RAM yang tersedia pada instans.

• Penggunaan Swap — Berapa banyak ruang tukar yang digunakan oleh instans, dalam megabyte.

Input/output operasi

• IOPS Baca, IOPS Tulis — Jumlah rata-rata operasi baca atau tulis disk per detik.

• Latensi Baca, Latensi Tulis — Waktu rata-rata untuk operasi baca atau tulis dalam milidetik.

• Throughput Baca, Throughput Tulis — Rata-rata jumlah megabyte yang dibaca dari atau ditulis ke disk per detik.

• Kedalaman Antrian Disk — Jumlah I/O operasi yang menunggu untuk ditulis atau dibaca dari disk.

Lalu lintas jaringan

• Throughput Penerimaan Jaringan, Throughput Pengiriman Jaringan — Tingkat lalu lintas jaringan ke dan dari instans dalam megabyte per detik.

Koneksi basis data

• Koneksi DB — Jumlah sesi klien yang terhubung ke instans.

Secara umum, nilai yang dapat diterima untuk metrik performa bergantung pada seperti apa garis dasar Anda dan apa yang dilakukan aplikasi Anda. Periksa varian yang konsisten atau sedang tren dari garis dasar Anda.

Berikut ini adalah rekomendasi dan saran tentang jenis metrik tertentu:

• Konsumsi CPU tinggi — Nilai tinggi untuk konsumsi CPU mungkin sesuai, jika mereka menjaga tujuan untuk aplikasi Anda (seperti throughput atau konkurensi) dan diharapkan. Jika konsumsi CPU Anda secara konsisten lebih dari 80 persen, pertimbangkan untuk menskalakan ke atas instans Anda.

• Konsumsi RAM tinggi — Jika FreeableMemory metrik Anda sering turun di bawah 10% dari total memori instans, pertimbangkan untuk meningkatkan instans Anda. Untuk informasi selengkapnya tentang apa yang terjadi ketika instance DocumentDB Anda mengalami tekanan memori tinggi, lihat Tata Kelola Sumber Daya Amazon DocumentDB.

• Penggunaan swap — Metrik ini harus tetap pada atau mendekati nol. Jika penggunaan swap Anda signifikan, pertimbangkan untuk menskalakan ke atas instans Anda.

• Lalu lintas jaringan — Untuk lalu lintas jaringan, bicarakan dengan administrator sistem Anda untuk memahami throughput yang diharapkan untuk jaringan domain dan koneksi internet Anda. Selidiki lalu lintas jaringan jika throughput selalu di bawah yang diharapkan.

• Koneksi basis data — Pertimbangkan untuk membatasi koneksi basis data jika Anda melihat jumlah koneksi pengguna yang tinggi bersamaan dengan penurunan performa instans dan waktu respons. Jumlah koneksi pengguna terbaik untuk instans Anda bervariasi berdasarkan kelas instans Anda dan kerumitan operasi yang sedang dilakukan. Untuk masalah dengan metrik kinerja apa pun, salah satu hal pertama yang dapat Anda lakukan untuk meningkatkan perfroma adalah menyesuaikan kueri yang paling banyak digunakan dan paling mahal untuk melihat apakah hal tersebut menurunkan tekanan pada sumber daya sistem.

Jika kueri Anda disetel dan masalah berlanjut, pertimbangkan untuk meningkatkan kelas instance Amazon DocumentDB Anda ke kelas dengan lebih banyak sumber daya (CPU, RAM, ruang disk, bandwidth jaringan, I/O kapasitas) yang terkait dengan masalah yang Anda alami.

Mengevaluasi penggunaan instans Amazon DocumentDB dengan metrik CloudWatch

Anda dapat menggunakan CloudWatch metrik untuk memantau throughput instans dan menemukan apakah kelas instans menyediakan sumber daya yang cukup untuk aplikasi Anda. Untuk informasi tentang kuota kelas instans Anda, lihat Kuota instans dan cari spesifikasi untuk kelas instance Anda untuk menemukan kinerja jaringan Anda.

Jika penggunaan instans mendekati batas kelas instance, maka kinerja mungkin mulai melambat. Met CloudWatch rik dapat mengonfirmasi situasi ini sehingga Anda dapat merencanakan peningkatan skala secara manual ke kelas instance yang lebih besar.

Gabungkan nilai CloudWatch metrik berikut untuk mengetahui apakah Anda mendekati batas kelas instance:

• NetworkThroughput—Jumlah throughput jaringan yang diterima dan ditransmisikan oleh klien untuk setiap instance di cluster Amazon DocumentDB. Nilai throughput ini tidak menyertakan lalu lintas jaringan antara instance di cluster dan volume penyimpanan cluster.

• StorageNetworkThroughput—Jumlah throughput jaringan yang diterima dan dikirim ke volume penyimpanan cluster Amazon DocumentDB oleh setiap instans di cluster Amazon DocumentDB.

Tambahkan NetworkThroughput ke untuk menemukan throughput jaringan yang diterima dari dan dikirim ke volume penyimpanan cluster Amazon DocumentDB oleh setiap instans di cluster Amazon DocumentDB Anda. StorageNetworkThroughput Batas kelas instans untuk instans Anda harus lebih besar dari jumlah kedua metrik gabungan ini.

Anda dapat menggunakan metrik berikut untuk meninjau detail tambahan lalu lintas jaringan dari aplikasi klien Anda saat mengirim dan menerima:

• NetworkReceiveThroughput—Jumlah throughput jaringan yang diterima dari klien oleh setiap instans di cluster Amazon DocumentDB. Throughput ini tidak menyertakan lalu lintas jaringan antara instance di cluster dan volume penyimpanan cluster.

• NetworkTransmitThroughput—Jumlah throughput jaringan yang dikirim ke klien oleh setiap instans di cluster Amazon DocumentDB. Throughput ini tidak menyertakan lalu lintas jaringan antara instance di cluster dan volume penyimpanan cluster.

• StorageNetworkReceiveThroughput—Jumlah throughput jaringan yang diterima dari volume penyimpanan cluster Amazon DocumentDB oleh setiap instans di cluster.

• StorageNetworkTransmitThroughput—Jumlah throughput jaringan yang dikirim ke volume penyimpanan cluster Amazon DocumentDB oleh setiap instans di cluster.

Tambahkan semua metrik ini bersama-sama untuk mengevaluasi bagaimana penggunaan jaringan Anda dibandingkan dengan batas kelas instans. Batas kelas instans harus lebih besar dari jumlah metrik gabungan ini.

Batas jaringan dan pemanfaatan CPU oleh sebuah instance saling menguntungkan. Ketika throughput jaringan meningkat, maka pemanfaatan CPU juga meningkat. Pemantauan penggunaan CPU dan jaringan memberikan informasi tentang bagaimana dan mengapa sumber daya habis.

Untuk membantu meminimalkan penggunaan jaringan, Anda dapat mempertimbangkan:

• Menggunakan kelas instans yang lebih besar.

• Membagi permintaan tulis dalam batch untuk mengurangi keseluruhan transaksi.

• Mengarahkan beban kerja hanya-baca ke instans hanya-baca.

• Menghapus indeks yang tidak digunakan.

Menyetel kueri

Salah satu cara terbaik untuk meningkatkan kinerja klaster adalah dengan menyetel kueri yang paling sering digunakan dan paling intensif sumber daya untuk membuatnya lebih murah untuk dijalankan.

Anda dapat menggunakan profiler (lihat Membuat profil operasi Amazon DocumentDB) untuk mencatat waktu eksekusi dan detail operasi yang dilakukan di klaster Anda. Profiler berguna untuk memantau operasi paling lambat di klaster Anda untuk membantu Anda meningkatkan performa kueri individual dan performa klaster secara keseluruhan.

Anda juga dapat menggunakan perintah explain untuk mempelajari cara menganalisis rencana kueri untuk kueri tertentu. Gunakan informasi ini untuk memodifikasi kueri atau koleksi yang mendasari untuk meningkatkan kinerja kueri Anda (misalnya, menambahkan indeks).

TTL dan beban kerja deret waktu

Penghapusan dokumen yang dihasilkan dari kedaluwarsanya indeks TTL merupakan proses upaya terbaik. Dokumen tidak dijamin akan dihapus dalam periode tertentu. Faktor-faktor seperti ukuran instans, pemanfaatan sumber daya instans, ukuran dokumen, throughput keseluruhan, jumlah indeks, dan apakah indeks dan set kerja sesuai dalam memori, semuanya dapat memengaruhi waktu ketika dokumen yang kedaluwarsa dihapus oleh proses TTL.

Saat monitor TTL menghapus dokumen Anda, setiap penghapusan menimbulkan I/O biaya, yang meningkatkan tagihan Anda. Jika throughput dan tingkat penghapusan TTL meningkat, Anda harus mengharapkan tagihan yang lebih tinggi karena peningkatan I/O penggunaan. Namun, jika Anda tidak membuat indeks TTL untuk menghapus dokumen, melainkan mengelompokkan dokumen ke dalam koleksi berdasarkan waktu, dan cukup membuang koleksi tersebut saat tidak lagi diperlukan, Anda tidak akan dikenakan biaya IO apa pun. Ini dapat secara signifikan menghemat biaya daripada menggunakan indeks TTL.

Untuk beban kerja deret waktu, Anda dapat mempertimbangkan untuk membuat koleksi bergulir alih-alih indeks TTL karena koleksi bergulir dapat menjadi cara yang lebih baik untuk menghapus data dan kurang intensif. I/O Jika Anda memiliki koleksi besar (terutama koleksi di atas 1TB) atau I/O biaya penghapusan TTL menjadi perhatian, partisi dokumen menjadi koleksi berdasarkan waktu, dan hapus koleksi ketika dokumen tidak lagi diperlukan. Anda dapat membuat satu koleksi per hari atau satu per minggu, tergantung pada tingkat menyerap data Anda. Meskipun persyaratan akan bervariasi tergantung pada aplikasi Anda, aturan praktis yang baik adalah memiliki lebih banyak koleksi yang lebih kecil daripada beberapa koleksi besar. Menghilangkan koleksi ini tidak menimbulkan I/O biaya, dan bisa lebih cepat dan lebih hemat biaya daripada menggunakan indeks TTL.

Migrasi

Sebagai praktik terbaik untuk memigrasikan data ke Amazon DocumentDB, pertama-tama buat indeks Anda di Amazon DocumentDB, lalu migrasikan data Anda. Membuat indeks terlebih dahulu dapat mengurangi waktu keseluruhan dan meningkatkan kecepatan migrasi. Untuk melakukannya, Anda dapat menggunakan Alat Indeks Amazon DocumentDB. Untuk informasi lebih lanjut tentang migrasi, lihat. Migrasi dan upgrade Amazon DocumentDB

Kami juga merekomendasikan bahwa sebelum Anda memigrasikan basis data produksi Anda, praktik terbaik adalah untuk sepenuhnya menguji aplikasi Anda di Amazon DocumentDB, dengan mempertimbangkan fungsionalitas, kinerja, operasi, dan biaya.

Bekerja dengan grup parameter cluster

Cobalah perubahan grup parameter cluster pada cluster uji sebelum menerapkan perubahan ke cluster produksi Anda. Untuk informasi tentang pencadangan kluster Anda, lihat Membuat cadangan dan memulihkan di Amazon DocumentDB.

Kueri pipa agregasi

Ketika membuat kueri alur agregasi dengan beberapa tahap dan mengevaluasi hanya sebagian dari data dalam kueri, gunakan tahap $match sebagai tahap pertama atau di awal alur. Menggunakan $match terlebih dahulu akan mengurangi jumlah dokumen yang perlu diproses pada tahap selanjutnya dalam kueri alur agregasi, sehingga meningkatkan kinerja kueri Anda.

BatchInsert dan Bat chUpdate

Saat melakukan batchInsert and/or batchUpdate operasi serentak tingkat tinggi, dan jumlah FreeableMemory (CloudWatch Metrik) menjadi nol pada instans utama Anda, Anda dapat mengurangi konkurensi penyisipan batch atau memperbarui beban kerja atau, jika konkurensi beban kerja tidak dapat dikurangi, menambah ukuran instans untuk menambah jumlah. FreeableMemory