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.

• Menerapkan cluster yang terdiri dari dua atau lebih instans AWS Amazon DocumentDB di dua Availability Zone. Untuk beban kerja produksi, kami merekomendasikan men-deploy klaster yang terdiri dari tiga atau lebih instans Amazon DocumentDB di tiga Availability Zone.

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

• Pantau memoriCPU, koneksi, dan penggunaan penyimpanan Anda. Untuk membantu Anda mempertahankan performa dan ketersediaan sistem, siapkan Amazon CloudWatch untuk memberi tahu Anda saat pola penggunaan berubah atau saat Anda mendekati kapasitas penerapan.

• 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 set 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 menggunakan sumber daya dengan AWS CloudFormation, aktifkan perlindungan penghentian. Untuk informasi selengkapnya, lihat Perlindungan penghentian dan perlindungan penghapusan.

• Ketika membuat klaster Amazon DocumentDB, --engine-version adalah parameter opsional yang ditetapkan secara default ke versi mesin utama terbaru. Versi mesin utama saat ini adalah 4.0.0. Ketika versi mesin utama baru dirilis, versi mesin default untuk --engine-version akan diperbarui untuk mencerminkan versi mesin utama yang terakhir. Akibatnya, untuk beban kerja produksi, dan terutama yang bergantung pada skrip, otomatisasi, atau AWS CloudFormation templat, kami menyarankan Anda secara eksplisit menentukan --engine-version ke versi utama yang dimaksud.

Ukuran instans

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

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

BufferCacheHitRatio CloudWatch Metrik 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 yang setinggi mungkinBufferCacheHitRatio, disarankan agar instance di klaster Anda disediakan dengan cukup RAM untuk dapat menyesuaikan indeks dan kumpulan data kerja Anda dalam memori.

Jika indeks Anda tidak sesuai dengan memori, Anda akan melihat BufferCacheHitRatio yang lebih rendah. Membaca terus menerus dari disk menimbulkan biaya I/O tambahan dan tidak lebih baik daripada membaca dari memori. Jika BufferCacheHitRatio rasio Anda lebih rendah dari yang diharapkan, tingkatkan ukuran instans untuk klaster Anda RAM agar lebih sesuai dengan 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. Kami menyarankan Anda menguji 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

Membangun Indeks

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 ke Amazon DocumentDB.

Selektivitas indeks

Kami merekomendasikan Anda membatasi 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 mengonsumsi sumber daya seperti ruang disk dan I/O. 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 performa dan menghasilkan biaya I/O 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

Mengidentifikasi indeks yang hilang adalah praktik terbaik yang kami rekomendasikan untuk dilakukan secara teratur. Untuk informasi selengkapnya, lihat Bagaimana cara mengidentifikasi indeks yang hilang?.

Mengidentifikasi indeks yang tidak digunakan

Mengidentifikasi dan menghapus indeks yang tidak terpakai adalah praktik terbaik yang kami rekomendasikan untuk dilakukan secara teratur. Untuk informasi selengkapnya, lihat Bagaimana cara menganalisis penggunaan indeks dan mengidentifikasi indeks yang tidak digunakan?.

Praktik terbaik keamanan

Untuk praktik terbaik keamanan, Anda harus menggunakan AWS Identity and Access Management (IAM) akun untuk mengontrol akses ke operasi Amazon API DocumentDB, terutama operasi yang membuat, memodifikasi, atau menghapus sumber daya Amazon DocumentDB. Sumber daya tersebut termasuk klaster, grup keamanan, dan grup parameter. Anda juga harus menggunakan IAM untuk mengontrol tindakan yang melakukan tindakan administratif umum seperti mencadangkan pemulihan cluster. Saat membuat IAM peran, gunakan prinsip hak istimewa paling sedikit.

• Terapkan hak istimewa terendah dengan kontrol akses berbasis peran.

• Tetapkan IAM akun individual untuk setiap orang yang mengelola sumber daya Amazon DocumentDB. Jangan gunakan pengguna Akun AWS root untuk mengelola sumber daya Amazon DocumentDB. Buat IAM pengguna untuk semua orang, termasuk Anda sendiri.

• Berikan setiap IAM pengguna set izin minimum yang diperlukan untuk melakukan tugas mereka.

• Gunakan IAM grup untuk mengelola izin secara efektif untuk beberapa pengguna. Untuk informasi selengkapnyaIAM, lihat Panduan IAM Pengguna. Untuk informasi tentang praktik IAM terbaik, lihat Praktik IAM Terbaik.

• Putar IAM kredensil Anda secara teratur.

• Konfigurasikan AWS Secrets Manager untuk secara otomatis memutar rahasia untuk Amazon DocumentDB. Untuk informasi selengkapnya, lihat Memutar AWS Rahasia Secrets Manager Anda dan Rotating Secrets untuk Amazon DocumentDB di Panduan Pengguna AWS Secrets Manager.

• Berikan setiap pengguna Amazon DocumentDB set izin minimum yang diperlukan untuk melakukan tugas mereka. Untuk informasi selengkapnya, lihat Akses database menggunakan Kontrol Akses Berbasis Peran.

• Gunakan Transport Layer Security (TLS) untuk mengenkripsi data Anda dalam perjalanan dan AWS KMS mengenkripsi data Anda saat istirahat.

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 Amazon DocumentDB (dengan kompatibilitas MongoDB). FAQs

• 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.

• Baik TTL dan aliran perubahan menimbulkan I/O saat data 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

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 metrik tertentu sehingga Anda diberi tahu jika mereka 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 AWS Management Console atau AWS CLI. Untuk informasi selengkapnya, lihat Melihat CloudWatch data.

Mengatur CloudWatch alarm

Untuk menyetel CloudWatch 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

• CPUPemanfaatan — Persentase kapasitas pemrosesan komputer yang digunakan.

Memori

• Freeable Memory — Berapa banyak yang RAM tersedia pada instance.

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

Operasi input/output

• Baca IOPS, Tulis IOPS — 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 Antrean Disk — Jumlah operasi I/O yang menunggu untuk ditulis ke 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:

• CPUKonsumsi tinggi — Nilai CPU konsumsi yang tinggi mungkin sesuai, asalkan sesuai dengan tujuan Anda untuk aplikasi Anda (seperti throughput atau konkurensi) dan diharapkan. Jika CPU konsumsi Anda secara konsisten lebih dari 80 persen, pertimbangkan untuk meningkatkan instans Anda.

• RAMKonsumsi 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 instans 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 tetap ada, pertimbangkan untuk memutakhirkan kelas instans Amazon DocumentDB Anda ke kelas dengan lebih banyak sumber daya (CPU,, ruang disk, bandwidth jaringanRAM, kapasitas I/O) yang terkait dengan masalah yang Anda alami.

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).

TTLdan beban kerja time series

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

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

Untuk beban kerja deret waktu, Anda dapat mempertimbangkan untuk membuat koleksi bergulir alih-alih TTL indeks 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 TTL penghapusan biaya I/O menjadi perhatian, kami sarankan Anda mempartisi dokumen ke dalam koleksi berdasarkan waktu, dan menjatuhkan 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. Menjatuhkan koleksi ini tidak menimbulkan biaya I/O, dan bisa lebih cepat dan lebih hemat biaya daripada menggunakan indeks. TTL

Migrasi

Sebagai praktik terbaik, kami merekomendasikan bahwa ketika memigrasikan data ke Amazon DocumentDB, Anda terlebih dahulu membuat indeks Anda di Amazon DocumentDB sebelum memigrasikan data. 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 Panduan migrasi 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 kelompok parameter cluster

Kami menyarankan agar Anda mencoba perubahan grup parameter klaster pada klaster uji sebelum menerapkan perubahan ke klaster produksi Anda. Untuk informasi tentang pencadangan kluster Anda, lihat Mencadangkan 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 batchUpdate

Saat melakukan tingkat konkuren batchInsert dan/atau batchUpdate operasi yang 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, tingkatkan ukuran instans untuk menambah jumlah. FreeableMemory