Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Apa itu Amazon DocumentDB (dengan kompatibilitas MongoDB)
Amazon DocumentDB (dengan kompatibilitas MongoDB) adalah layanan basis data terkelola penuh yang cepat dan andal. Amazon DocumentDB memudahkan untuk mengatur, mengoperasikan, dan menskalakan basis data kompatibel MongoDB di cloud. Dengan Amazon DocumentDB, Anda dapat menjalankan kode aplikasi yang sama dan menggunakan driver dan alat-alat yang sama yang Anda gunakan dengan MongoDB.
Sebelum menggunakan Amazon DocumentDB, Anda harus meninjau konsep dan fitur yang dijelaskan dalam [Cara kerjanya](how-it-works.md). Setelah itu, selesaikan langkah-langkah di [Panduan memulai](get-started-guide.md).
**Topics**
+ [Ikhtisar](#overview)
+ [klaster](#what-is-db-clusters)
+ [Contoh](#what-is-db-instances)
+ [Daerah dan AZs](#what-is-regions-and-azs)
+ [Harga](#docdb-pricing)
+ [Memantau](#what-is-monitoring)
+ [Antarmuka](#what-is-interfaces)
+ [Apa selanjutnya?](#what-is-next)
+ [Cara kerjanya](how-it-works.md)
+ [Apa itu database dokumen?](what-is-document-db.md)
## Gambaran umum Amazon DocumentDB
Berikut ini adalah beberapa fitur tingkat tinggi dari Amazon DocumentDB:
+ Amazon DocumentDB mendukung dua jenis cluster: cluster berbasis instance dan cluster elastis. Cluster elastis mendukung beban kerja dengan jutaan reads/writes per detik dan kapasitas penyimpanan petabyte. Untuk informasi lebih lanjut tentang gugus elastis, lihat[Menggunakan cluster elastis Amazon DocumentDB](docdb-using-elastic-clusters.md). Konten di bawah ini mengacu pada cluster berbasis instans Amazon DocumentDB.
+ Amazon DocumentDB secara otomatis meningkatkan ukuran volume penyimpanan Anda seiring kebutuhan penyimpanan basis data Anda semakin besar. Volume penyimpanan Anda bertambah 10 GB, hingga maksimum 128 TiB. Anda tidak perlu menyediakan kelebihan penyimpanan apa pun untuk klaster Anda untuk menangani pertumbuhan masa depan.
+ Dengan Amazon DocumentDB, Anda dapat meningkatkan throughput baca untuk mendukung permintaan aplikasi volume tinggi dengan membuat hingga 15 instans replika. Replika Amazon DocumentDB berbagi penyimpanan yang mendasari sama, menurunkan biaya dan menghindari kebutuhan untuk melakukan penulisan pada simpul replika. Kemampuan ini membebaskan lebih banyak daya pemrosesan untuk melayani permintaan baca dan mengurangi waktu jeda replika—sering kali hingga satu digit milidetik. Anda dapat menambahkan replika dalam hitungan menit terlepas dari ukuran volume penyimpanan. Amazon DocumentDB juga menyediakan reader endpoint, sehingga aplikasi dapat terhubung tanpa harus melacak replika karena mereka ditambahkan dan dihapus.
+ Amazon DocumentDB memungkinkan Anda menskalakan ke atas atau ke bawah sumber daya komputasi dan memori untuk setiap instans Anda. Operasi penskalaan komputasi biasanya selesai dalam beberapa menit.
+ Amazon DocumentDB berjalan di Amazon Virtual Private Cloud (Amazon VPC), sehingga Anda dapat mengisolasi basis data Anda di jaringan virtual Anda sendiri. Anda juga dapat mengonfigurasi pengaturan firewall untuk mengontrol akses jaringan ke klaster Anda.
+ Amazon DocumentDB terus memantau kesehatan klaster Anda. Pada kegagalan instans, Amazon DocumentDB secara otomatis memulai ulang instans dan proses yang berkaitan. Amazon DocumentDB tidak memerlukan pemutaran ulang pemulihan kecelakaan pada log redo basis data, yang sangat mengurangi waktu pemulaian ulang. Amazon DocumentDB juga mengisolasi cache basis data dari proses basis data, mengaktifkan cache untuk mempertahankan pemulaian ulang instans.
+ Pada kegagalan instans, Amazon DocumentDB mengotomatisasi failover ke salah satu hingga 15 replika Amazon DocumentDB yang Anda buat di Availability Zone lainnya. Jika tidak ada replika telah disediakan dan terjadi kegagalan, Amazon DocumentDB mencoba untuk membuat instans Amazon DocumentDB baru secara otomatis.
+ Kemampuan pencadangan di Amazon DocumentDB point-in-time memungkinkan pemulihan untuk klaster Anda. Fitur ini memungkinkan Anda untuk memulihkan klaster ke detik berapa pun selama periode retensi, hingga 5 menit terakhir. Anda dapat mengonfigurasi periode retensi cadangan otomatis hingga 35 hari. Pencadangan otomatis disimpan di Amazon Simple Storage Service (Amazon S3), yang dirancang untuk daya tahan 99,999999999%. Backup Amazon DocumentDB bersifat otomatis, inkremental, dan terus menerus, dan mereka tidak berdampak pada kinerja klaster Anda.
+ Dengan Amazon DocumentDB, Anda dapat mengenkripsi database menggunakan kunci yang Anda buat dan kontrol melalui (). AWS Key Management Service AWS KMS Pada klaster basis data yang berjalan dengan enkripsi Amazon DocumentDB, data yang disimpan di rest dalam penyimpanan yang mendasari dienkripsi. Backup otomatis, snapshot, dan replika di klaster yang sama juga dienkripsi.
+ Amazon DocumentDB disahkan berdasarkan Federal Risk and Authorization Management Program (FedRAMP). Ini memiliki otorisasi FedRAMP High AWS GovCloud untuk wilayah (AS) dan otorisasi FedRAMP Moderate untuk Wilayah AS. AWS East/West Untuk detail tentang AWS dan upaya kepatuhan, lihat [AWS Layanan dalam Lingkup oleh Program Kepatuhan](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/).
Jika Anda baru mengenal AWS layanan, gunakan sumber daya berikut untuk mempelajari lebih lanjut:
+ AWS menawarkan layanan untuk komputasi, database, penyimpanan, analitik, dan fungsionalitas lainnya. Untuk ikhtisar semua AWS layanan, lihat [Komputasi Awan dengan Amazon Web Services](https://aws.amazon.com/what-is-aws/).
+ AWS menyediakan sejumlah layanan database. Untuk panduan tentang layanan terbaik untuk lingkungan Anda, lihat [Basis data pada AWS](https://aws.amazon.com/products/databases/).
## klaster
*Klaster* terdiri dari 0 sampai 16 instans dan volume penyimpanan klaster yang mengelola data untuk instans tersebut. Semua penulisan dilakukan melalui instans primer. Semua instans (primer dan replika) mendukung pembacaan. Data klaster disimpan dalam volume klaster dengan salinan dalam tiga Availability Zone yang berbeda.
![\[Cluster Amazon DocumentDB yang berisi instans utama di Availability Zone 1, menulis ke volume cluster untuk replika di zona 2 dan 3.\]](http://docs.aws.amazon.com/id_id/documentdb/latest/developerguide/images/how-it-works-01c.png)
Cluster berbasis instans Amazon DocumentDB 5.0 mendukung dua konfigurasi penyimpanan untuk kluster database: standar Amazon DocumentDB dan Amazon DocumentDB I/O yang dioptimalkan. Untuk mengetahui informasi selengkapnya, lihat [Konfigurasi penyimpanan klaster Amazon DocumentDB](db-cluster-storage-configs.md).
## Contoh
Instans Amazon DocumentDB adalah lingkungan basis data terisolasi di cloud. Instans Anda dapat berisi beberapa basis data yang dibuat pengguna. Anda dapat membuat dan memodifikasi instance menggunakan Konsol Manajemen AWS atau AWS CLI.
Komputasi dan kapasitas memori dari instans ditentukan oleh *kelas instans*-nya. Anda dapat memilih instans yang paling sesuai dengan kebutuhan Anda. Jika kebutuhan Anda berubah seiring waktu, Anda dapat memilih kelas instans yang berbeda. Untuk spesifikasi kelas instans, lihat [Spesifikasi kelas instans](db-instance-classes.md#db-instance-class-specs).
Instans Amazon DocumentDB berjalan hanya di lingkungan Amazon VPC. Amazon VPC memberi Anda kendali atas lingkungan jaringan virtual Anda: Anda dapat memilih rentang alamat IP Anda sendiri, membuat subnet, dan mengonfigurasi daftar kontrol perutean dan akses (). ACLs
Sebelum Anda dapat membuat instans Amazon DocumentDB, Anda harus membuat klaster yang akan berisi instans.
Tidak semua kelas instans didukung di setiap wilayah. Tabel berikut ini menunjukkan kelas instans mana yang didukung di setiap wilayah.
**catatan**
Untuk daftar lengkap jenis instans yang didukung oleh Amazon DocumentDB di setiap kelas instance, lihat. [Spesifikasi kelas instans](db-instance-classes.md#db-instance-class-specs)
**Kelas instans yang didukung berdasarkan Wilayah**
| | Kelas Instans | Region | R8G | R6GD | R6G | R5 | R4 | T4G | T3 | Nirserver |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| AS Timur (Ohio) | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung |
| US East (N. Virginia) | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung |
| US West (Oregon) | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung |
| Africa (Cape Town) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Amerika Selatan (Sao Paulo) | | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pasifik (Hong Kong) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pasifik (Hyderabad) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pasifik (Malaysia) | | | Didukung | | | Didukung | Didukung | |
| Asia Pasifik (Mumbai) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pasifik (Osaka) | | Didukung | Didukung | Didukung | | Didukung | Didukung | |
| Asia Pasifik (Seoul) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pacific (Sydney) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pasifik (Jakarta) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | |
| Asia Pacific (Melbourne) | | | Didukung | Didukung | | Didukung | Didukung | |
| Asia Pacific (Singapore) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Asia Pasifik (Thailand) | | | Didukung | | | Didukung | Didukung | |
| Asia Pacific (Tokyo) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Kanada (Pusat) | | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Eropa (Frankfurt) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Europe (Zurich) | | Didukung | Didukung | Didukung | | Didukung | Didukung | |
| Eropa (Irlandia) | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung | Didukung |
| Eropa (London) | | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Europe (Milan) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Eropa (Paris) | | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Eropa (Spanyol) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Eropa (Stockholm) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | |
| Meksiko (Tengah) | | | Didukung | | | Didukung | Didukung | |
| Timur Tengah (UAE) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Tiongkok (Beijing) | | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Tiongkok (Ningxia) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| Israel (Tel Aviv) | | | Didukung | Didukung | | Didukung | Didukung | Didukung |
| AWS GovCloud (AS-Barat) | Didukung | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
| AWS GovCloud (AS-Timur) | | Didukung | Didukung | Didukung | | Didukung | Didukung | Didukung |
## Wilayah dan zona ketersediaan
Wilayah dan Availability Zone menentukan lokasi fisik klaster dan instans Anda.
### Wilayah
AWS Sumber daya komputasi awan ditempatkan di fasilitas pusat data yang sangat tersedia di berbagai wilayah di dunia (misalnya, Amerika Utara, Eropa, atau Asia). Setiap lokasi pusat data disebut *Wilayah*.
Setiap AWS Wilayah dirancang untuk sepenuhnya terisolasi dari AWS Wilayah lain. Di dalam setiap wilayah terdapat beberapa Zona Ketersediaan. Dengan meluncurkan simpul Anda di Zona Ketersediaan yang berbeda, Anda dapat mencapai toleransi kesalahan sebesar mungkin. Diagram berikut menunjukkan tampilan tingkat tinggi tentang cara kerja AWS Wilayah dan Zona Ketersediaan.
![\[Amazon DocumentDB tampilan tingkat tinggi Wilayah dan Availability Zone AWS .\]](http://docs.aws.amazon.com/id_id/documentdb/latest/developerguide/images/docdb-regions-and-azs.png)
### Zona ketersediaan
Setiap AWS Wilayah berisi beberapa lokasi berbeda yang disebut *Availability Zone*. Setiap Availability Zone direkayasa untuk diisolasi dari kegagalan di Availability Zone lainnya, dan untuk menyediakan konektivitas jaringan latensi rendah yang murah ke Availability Zone lainnya di Wilayah yang sama. Dengan meluncurkan instans untuk klaster tertentu di beberapa Availability Zone, Anda dapat melindungi aplikasi Anda dari peristiwa kegagalan Availability Zone yang tidak diinginkan.
Arsitektur Amazon DocumentDB memisahkan penyimpanan dan komputasi. Untuk lapisan penyimpanan, Amazon DocumentDB mereplikasi enam salinan data Anda di tiga Availability Zone. AWS Sebagai contoh, jika Anda meluncurkan klaster Amazon DocumentDB di Wilayah yang hanya mendukung dua Availability Zone, penyimpanan data Anda akan direplikasi enam cara di tiga Availability Zone tetapi instans komputasi Anda hanya akan tersedia di dua Availability Zone.
Tabel berikut mencantumkan jumlah Availability Zone yang dapat Anda gunakan dalam instance komputasi yang diberikan Wilayah AWS untuk menyediakan untuk klaster Anda.
| Nama Wilayah | Region | Availability Zone (penghitungan) |
| --- | --- | --- |
| AS Timur (Ohio) | `us-east-2` | 3 |
| AS Timur (Virginia Utara) | `us-east-1` | 6 |
| AS Barat (Oregon) | `us-west-2` | 4 |
| Africa (Cape Town) | `af-south-1` | 3 |
| Amerika Selatan (Sao Paulo) | `sa-east-1` | 3 |
| Asia Pasifik (Hong Kong) | `ap-east-1` | 3 |
| Asia Pasifik (Hyderabad) | `ap-south-2` | 3 |
| Asia Pasifik (Malaysia) | `ap-southeast-5` | 3 |
| Asia Pasifik (Mumbai) | `ap-south-1` | 3 |
| Asia Pasifik (Osaka) | `ap-northeast-3` | 3 |
| Asia Pasifik (Seoul) | `ap-northeast-2` | 4 |
| Asia Pasifik (Singapura) | `ap-southeast-1` | 3 |
| Asia Pasifik (Sydney) | `ap-southeast-2` | 3 |
| Asia Pasifik (Jakarta) | `ap-southeast-3` | 3 |
| Asia Pacific (Melbourne) | `ap-southeast-4` | 3 |
| Asia Pasifik (Thailand) | `ap-southeast-7` | 3 |
| Asia Pasifik (Tokyo) | `ap-northeast-1` | 3 |
| Kanada (Pusat) | `ca-central-1` | 3 |
| Wilayah Tiongkok (Beijing) | `cn-north-1` | 3 |
| Tiongkok (Ningxia) | `cn-northwest-1` | 3 |
| Eropa (Frankfurt) | `eu-central-1` | 3 |
| Europe (Zurich) | `eu-central-2` | 3 |
| Eropa (Irlandia) | `eu-west-1` | 3 |
| Eropa (London) | `eu-west-2` | 3 |
| Europe (Milan) | `eu-south-1` | 3 |
| Eropa (Paris) | `eu-west-3` | 3 |
| Eropa (Spanyol) | `eu-south-2` | 3 |
| Eropa (Stockholm) | `eu-north-1` | 3 |
| Meksiko (Tengah) | `mx-central-1` | 3 |
| Timur Tengah (UAE) | `me-central-1` | 3 |
| Israel (Tel Aviv) | `il-central-1` | 3 |
| AWS GovCloud (AS-Barat) | `us-gov-west-1` | 3 |
| AWS GovCloud (AS-Timur) | `us-gov-east-1` | 3 |
## Harga Amazon DocumentDB
Cluster Amazon DocumentDB ditagih berdasarkan komponen berikut:
+ **Jam instans (per jam)**—Berdasarkan kelas instans dari instans (sebagai contoh, `db.r5.xlarge`). Harga dicantumkan per jam, tetapi tagihan dihitung turun menjadi detik dan menunjukkan waktu dalam bentuk desimal. Penggunaan Amazon DocumentDB ditagihkan dalam kenaikan satu detik, dengan minimum 10 menit. Untuk informasi selengkapnya, lihat [Mengelola kelas instance](db-instance-classes.md).
+ **Permintaan I/O (per 1 juta permintaan per bulan)** - Jumlah total I/O permintaan penyimpanan yang Anda buat dalam siklus penagihan.
+ **Penyimpanan backup (per GiB per bulan)** — Penyimpanan backup adalah penyimpanan yang berkaitan dengan backup basis data otomatis dan setiap snapshot basis data aktif yang telah Anda ambil. Meningkatkan periode retensi cadangan atau mengambil snapshot basis data tambahan akan meningkatkan penyimpanan cadangan yang digunakan oleh basis data Anda. Penyimpanan Backup diukur dalam GB-bulan dan per detik tidak berlaku. Untuk informasi selengkapnya, lihat [Mencadangkan dan memulihkan di Amazon DocumentDB](backup_restore.md).
+ **Transfer data (per GB)** — Transfer data masuk dan keluar dari instans Anda dari atau ke internet atau AWS Wilayah lain.
Untuk informasi lebih lanjut, lihat [harga Amazon DocumentDB](https://aws.amazon.com/documentdb/pricing/).
### Uji coba gratis
Anda dapat mencoba Amazon DocumentDB secara gratis menggunakan uji coba gratis 1 bulan. Untuk informasi selengkapnya, lihat Uji coba gratis di harga [Amazon DocumentDB](https://aws.amazon.com/documentdb/pricing/) atau lihat FAQ uji coba gratis Amazon [DocumentDB](https://aws.amazon.com/documentdb/free-trial/).
## Memantau
Terdapat beberapa cara untuk melacak performa dan kesehatan instans. Anda dapat menggunakan CloudWatch layanan Amazon gratis untuk memantau kinerja dan kesehatan suatu instans. Anda dapat menemukan grafik performa di konsol Amazon DocumentDB. Anda dapat berlangganan peristiwa Amazon DocumentDB untuk mendapatkan notifikasi tentang perubahan yang terjadi pada instans, snapshot, grup parameter, atau grup keamanan.
Untuk informasi selengkapnya, lihat berikut ini:
+ [Memantau Amazon DocumentDB dengan CloudWatch](cloud_watch.md)
+ [Mencatat panggilan API Amazon DocumentDB dengan AWS CloudTrail](logging-with-cloudtrail.md)
## Antarmuka
Ada beberapa cara bagi Anda untuk berinteraksi dengan Amazon DocumentDB, termasuk Konsol Manajemen AWS dan. AWS CLI
### Konsol Manajemen AWS
Konsol Manajemen AWS Ini adalah antarmuka pengguna berbasis web yang sederhana. Anda dapat mengelola klaster dan instans Anda dari konsol tanpa perlu pemrograman. [Untuk mengakses konsol Amazon DocumentDB, masuk ke Konsol Manajemen AWS dan buka konsol Amazon DocumentDB di /docdb. https://console.aws.amazon.com](https://console.aws.amazon.com/docdb)
### AWS CLI
Anda dapat menggunakan AWS Command Line Interface (AWS CLI) untuk mengelola klaster dan instans Amazon DocumentDB Anda. Dengan konfigurasi minimal, Anda dapat mulai menggunakan semua fungsionalitas yang disediakan oleh konsol Amazon DocumentDB dari program terminal favorit Anda.
+ Untuk menginstal AWS CLI, lihat [Menginstal Antarmuka Baris AWS Perintah](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
+ Untuk mulai menggunakan Amazon DocumentDB AWS CLI untuk Amazon, [AWS lihat Referensi Antarmuka Baris Perintah untuk Amazon](https://docs.aws.amazon.com/cli/latest/reference/docdb/index.html) DocumentDB.
### Driver MongoDB
Untuk mengembangkan dan menulis aplikasi terhadap klaster Amazon DocumentDB, Anda juga dapat menggunakan driver MongoDB dengan Amazon DocumentDB. Untuk informasi selengkapnya, lihat tab shell MongoDB di atau. [Menghubungkan dengan TLS diaktifkan](connect_programmatically.md#connect_programmatically-tls_enabled) [Menghubungkan dengan TLS dinonaktifkan](connect_programmatically.md#connect_programmatically-tls_disabled)
## Apa selanjutnya?
Bagian sebelumnya memperkenalkan Anda pada komponen infrastruktur dasar yang ditawarkan Amazon DocumentDB. Apa yang harus Anda lakukan selanjutnya? Tergantung pada keadaan Anda, lihat salah satu topik berikut untuk memulai:
+ Memulai Amazon DocumentDB dengan membuat cluster dan instance menggunakan. CloudFormation [Amazon DocumentDB mulai cepat menggunakan CloudFormation](quick_start_cfn.md)
+ Memulai dengan Amazon DocumentDB dengan membuat klaster dan instans menggunakan petunjuk di [Panduan memulai](get-started-guide.md) kami.
+ Mulailah dengan Amazon DocumentDB dengan membuat cluster elastis menggunakan instruksi di. [Memulai dengan cluster elastis Amazon DocumentDB](elastic-get-started.md)
+ Migrasikan implementasi MongoDB Anda ke Amazon DocumentDB menggunakan panduan di [Migrasi ke Amazon DocumentDB](docdb-migration.md)
# Amazon DocumentDB: cara kerjanya
Amazon DocumentDB (dengan kompatibilitas MongoDB) adalah layanan basis data yang kompatibel dengan MongoDB yang terkelola penuh. Dengan Amazon DocumentDB, Anda dapat menjalankan kode aplikasi yang sama dan menggunakan driver dan alat yang sama yang Anda gunakan dengan MongoDB. Amazon DocumentDB kompatibel dengan MongoDB 3.6, 4.0, 5.0, dan 8.0.
**Topics**
+ [Titik akhir Amazon DocumentDB](#how-it-works.endpoints)
+ [Dukungan TLS](#how-it-works.ssl)
+ [Penyimpanan Amazon DocumentDB](#how-it-works.storage)
+ [Replikasi Amazon DocumentDB](#how-it-works.replication)
+ [Keandalan Amazon DocumentDB](#how-it-works.reliability)
+ [Baca opsi preferensi](#durability-consistency-isolation)
+ [TTL menghapus](#how-it-works.ttl-deletes)
+ [Sumber daya yang dapat ditagih](#billing)
Saat Anda menggunakan Amazon DocumentDB, Anda mulai dengan membuat *klaster*. Sebuah klaster terdiri dari nol atau lebih instans basis data dan volume klaster yang mengelola data untuk instans tersebut. *Volume klaster* Amazon DocumentDB adalah volume penyimpanan basis data virtual yang mencakup beberapa Availability Zone. Setiap Availability Zone memiliki salinan data klaster.
Klaster Amazon DocumentDB terdiri dari dua komponen:
+ **Volume klaster**—Menggunakan layanan penyimpanan cloud-native untuk mereplikasi data dengan enam cara di tiga Availability Zone, menyediakan penyimpanan yang sangat berdaya tahan dan tersedia. Cluster Amazon DocumentDB memiliki tepat satu volume cluster, yang dapat menyimpan hingga 128 TiB data.
+ **Instans**—Menyediakan kekuatan pemrosesan untuk basis data, menulis data ke, dan membaca data dari, volume penyimpanan klaster. Klaster Amazon DocumentDB dapat memiliki 0–16 instans.
Instans melayani salah satu dari dua peran:
+ **Instans primer**—Mendukung operasi baca dan tulis, dan melakukan semua modifikasi data ke volume klaster. Setiap klaster Amazon DocumentDB memiliki satu instans primer.
+ **Instans replika**—Mendukung hanya operasi baca. Setiap klaster Amazon DocumentDB dapat memiliki hingga 15 instans replika selain instans primer. Memiliki beberapa replika memungkinkan Anda untuk mendistribusikan beban kerja baca. Selain itu, dengan menempatkan replika di Availability Zone terpisah, Anda juga meningkatkan ketersediaan klaster.
Diagram berikut mengilustrasikan hubungan antara volume klaster, instans primer, dan replika di klaster Amazon DocumentDB:
![\[Titik akhir Amazon DocumentDB termasuk titik akhir cluster, pembaca, dan instance.\]](http://docs.aws.amazon.com/id_id/documentdb/latest/developerguide/images/docdb-endpoint-types.png)
Instans klaster tidak harus dari kelas instans yang sama, dan mereka dapat disediakan dan diakhiri sesuai yang diinginkan. Arsitektur ini memungkinkan Anda menskalakan kapasitas komputasi klaster Anda secara independen dari penyimpanannya.
Saat aplikasi Anda menulis data ke instans primer, yang primer mengeksekusi penulisan yang tahan lama ke volume klaster. Itu kemudian mereplikasi status penulisan itu (bukan data) ke setiap replika aktif. Replika Amazon DocumentDB tidak berpartisipasi dalam pemrosesan tulis, dan dengan demikian replika Amazon DocumentDB menguntungkan untuk penskalaan baca. Pembacaan dari replika Amazon DocumentDB pada akhirnya konsisten dengan jeda replika minimal—biasanya kurang dari 100 milidetik setelah instans primer menulis data. Bacaan dari replika dijamin akan dibaca sesuai urutan penulisannya ke yang primer. Jeda replika bervariasi tergantung pada kecepatan perubahan data, dan periode aktivitas tulis yang tinggi dapat meningkatkan jeda replika. Untuk informasi lebih, lihat metrik `ReplicationLag` di [Metrik Amazon DocumentDB](cloud_watch.md#cloud_watch-metrics_list).
## Titik akhir Amazon DocumentDB
Amazon DocumentDB menyediakan beberapa opsi koneksi untuk melayani berbagai kasus penggunaan. Untuk terhubung ke instans di klaster Amazon DocumentDB, Anda menentukan titik akhir instans. Sebuah *titik akhir* adalah alamat host dan nomor port, dipisahkan oleh titik dua.
Kami merekomendasikan Anda terhubung ke klaster menggunakan titik akhir klaster dan dalam mode set replika (lihat [Menghubungkan ke Amazon DocumentDB sebagai set replika](connect-to-replica-set.md)) kecuali jika Anda memiliki kasus penggunaan khusus untuk menghubungkan ke reader endpoint atau titik akhir instans. Untuk merutekan permintaan ke replika 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.
Titik akhir berikut tersedia dari klaster Amazon DocumentDB.
### Titik Akhir klaster
*Titik akhir klaster* terhubung ke instans primer klaster Anda saat ini. Titik akhir klaster dapat digunakan untuk operasi baca dan tulis. Sebuah klaster Amazon DocumentDB memiliki tepat satu titik akhir klaster.
Titik akhir klaster menyediakan dukungan failover untuk koneksi baca dan tulis ke klaster. Jika instans primer klaster Anda saat ini gagal, dan klaster Anda memiliki setidaknya satu replika baca aktif, titik akhir klaster secara otomatis mengalihkan permintaan koneksi ke instans primer baru. Saat menghubungkan ke klaster Amazon DocumentDB Anda, kami merekomendasikan Anda menghubungkan ke klaster Anda menggunakan titik akhir klaster dan dalam mode set replika (lihat [Menghubungkan ke Amazon DocumentDB sebagai set replika](connect-to-replica-set.md)).
Berikut ini adalah contoh titik akhir klaster Amazon DocumentDB:
```
sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017
```
Berikut ini adalah contoh koneksi string menggunakan titik akhir klaster ini:
```
mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017
```
Untuk informasi tentang menemukan titik akhir klaster, lihat [Menemukan titik akhir klaster](db-cluster-endpoints-find.md).
### Titik akhir pembaca
Beban *reader endpoint* menyeimbangkan koneksi baca-saja di semua replika yang tersedia di klaster Anda. Titik akhir pembaca cluster akan tampil sebagai titik akhir cluster jika Anda terhubung melalui `replicaSet` mode, artinya dalam string koneksi, parameter set replika adalah. `&replicaSet=rs0` Dalam hal ini, Anda akan dapat melakukan operasi penulisan pada primer. Namun, jika Anda terhubung ke klaster yang menentukan`directConnection=true`, maka mencoba melakukan operasi penulisan melalui koneksi ke titik akhir pembaca menghasilkan kesalahan. Sebuah klaster Amazon DocumentDB memiliki tepat satu reader endpoint.
Jika klaster hanya berisi satu instans (primer), reader endpoint terhubung ke instans primer. Saat Anda menambahkan instans replika ke klaster Amazon DocumentDB, reader endpoint membuka koneksi baca saja ke replika baru setelah itu aktif.
Berikut ini adalah contoh reader endpoint untuk klaster Amazon DocumentDB:
```
sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017
```
Berikut ini adalah contoh string koneksi menggunakan reader endpoint:
```
mongodb://username:password@sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017
```
Beban reader endpoint menyeimbangkan koneksi baca-saja, bukan permintaan baca. Jika beberapa koneksi reader endpoint lebih banyak digunakan daripada yang lain, permintaan baca Anda mungkin tidak seimbang di antara instans di dalam klaster. Direkomendasikan untuk mendistribusikan permintaan dengan menghubungkan ke titik akhir klaster sebagai set replika dan menggunakan opsi preferensi baca secondaryPreferred.
Untuk informasi tentang menemukan titik akhir klaster, lihat [Menemukan titik akhir klaster](db-cluster-endpoints-find.md).
### Titik akhir instans
*Titik akhir instans* terhubung ke instans tertentu dalam klaster Anda. Titik akhir instans untuk instans primer saat ini dapat digunakan untuk operasi baca dan tulis. Namun, mencoba melakukan operasi tulis ke titik akhir instans untuk replika baca akan menghasilkan kesalahan. Klaster Amazon DocumentDB memiliki satu titik akhir instans per instans aktif.
Titik akhir instans memberikan kontrol langsung atas koneksi ke instans tertentu untuk skenario di mana titik akhir klaster atau reader endpoint mungkin tidak sesuai. Contoh kasus penggunaan adalah penyediaan beban kerja analitik baca-saja secara berkala. Anda dapat menyediakan instance larger-than-normal replika, terhubung langsung ke instans baru yang lebih besar dengan titik akhir instansnya, menjalankan kueri analitik, dan kemudian menghentikan instance. Menggunakan titik akhir instans menjaga lalu lintas analitik agar tidak memengaruhi instans klaster lainnya.
Berikut ini adalah contoh titik akhir instans untuk instans tunggal di klaster Amazon DocumentDB:
```
sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017
```
Berikut ini adalah contoh string koneksi menggunakan titik akhir instans ini:
```
mongodb://username:password@sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017
```
**catatan**
Peran instans sebagai primer atau replika dapat berubah karena peristiwa failover. Aplikasi Anda tidak boleh berasumsi bahwa titik akhir instans tertentu adalah instans primer. Kami tidak menyarankan menghubungkan ke titik akhir instans untuk aplikasi produksi. Sebagai gantinya, kami merekomendasikan Anda menyambungkan ke klaster menggunakan titik akhir klaster dan dalam mode set replika (lihat [Menghubungkan ke Amazon DocumentDB sebagai set replika](connect-to-replica-set.md)). Untuk kendali lebih lanjut dari prioritas failover instans, lihat [Memahami toleransi kesalahan klaster Amazon DocumentDB](db-cluster-fault-tolerance.md).
Untuk informasi tentang menemukan titik akhir klaster, lihat [Menemukan titik akhir instance](db-instance-endpoint-find.md).
### Mode set replika
Anda dapat terhubung ke titik akhir klaster Amazon DocumentDB Anda dalam mode set replika dengan menentukan nama set replika `rs0`. Menghubungkan dalam mode set replika menyediakan kemampuan untuk menentukan opsi Perhatian Baca, Perhatian Tulis, dan Preferensi Baca. Untuk informasi selengkapnya, lihat [Konsistensi baca](#durability-consistency-isolation.read-consistency).
Berikut ini adalah contoh koneksi string yang menghubungkan dalam mode set replika:
```
mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017/?replicaSet=rs0
```
Saat Anda terhubung dalam mode set replika, klaster Amazon DocumentDB Anda muncul ke driver dan klien Anda sebagai set replika. Instans yang ditambahkan dan dihapus dari klaster Amazon DocumentDB Anda direfleksikan secara otomatis dalam konfigurasi set replika.
Setiap klaster Amazon DocumentDB terdiri dari set replika tunggal dengan nama default `rs0`. Nama set replika tidak dapat diubah.
Menghubungkan ke titik akhir klaster dalam mode set replika adalah metode yang disarankan untuk penggunaan umum.
**catatan**
Semua instans dalam klaster Amazon DocumentDB mendengarkan pada port TCP yang sama untuk koneksi.
## Dukungan TLS
Untuk detail selengkapnya tentang menghubungkan ke Amazon DocumentDB menggunakan Transport Layer Security (TLS), lihat [Mengenkripsi data dalam perjalanan](security.encryption.ssl.md).
## Penyimpanan Amazon DocumentDB
Data Amazon DocumentDB disimpan dalam volume *cluster*, yang merupakan volume virtual tunggal yang menggunakan solid state drive (). SSDs Volume klaster terdiri dari enam salinan data Anda, yang direplikasi secara otomatis di beberapa Availability Zone dalam satu Wilayah AWS. Replikasi ini membantu memastikan bahwa data Anda sangat berdaya tahan, dengan kemungkinan kehilangan data yang lebih kecil. Ini juga membantu memastikan bahwa klaster Anda lebih tersedia selama failover karena salinan data Anda sudah ada di Availability Zone lainnya. Salinan ini dapat terus melayani permintaan data ke instans di klaster Amazon DocumentDB Anda.
### Bagaimana penyimpanan data ditagih
Amazon DocumentDB secara otomatis meningkatkan ukuran volume klaster saat jumlah data meningkat. Volume cluster Amazon DocumentDB dapat tumbuh hingga ukuran maksimum 128 TiB; Namun, Anda hanya dikenakan biaya untuk ruang yang Anda gunakan dalam volume cluster Amazon DocumentDB. Dimulai dengan Amazon DocumentDB 4.0, ketika data dihapus, seperti dengan menjatuhkan koleksi atau indeks, keseluruhan ruang yang dialokasikan berkurang dengan jumlah yang sebanding. Dengan demikian, Anda dapat mengurangi biaya penyimpanan dengan menghapus koleksi, indeks, dan database yang tidak lagi Anda perlukan. Di Amazon DocumentDB versi 3.6, volume cluster dapat menggunakan kembali ruang yang dibebaskan saat Anda menghapus data, tetapi volume itu sendiri tidak pernah berkurang ukurannya. Akibatnya di versi 3.6, Anda mungkin tidak menyaksikan perubahan apa pun dalam penyimpanan saat Anda menjatuhkan koleksi atau indeks, meskipun ruang kosong digunakan kembali.
**catatan**
Dengan Amazon DocumentDB 3.6, biaya penyimpanan didasarkan pada penyimpanan “tanda air tinggi” (jumlah maksimum yang dialokasikan untuk cluster Amazon DocumentDB kapan saja). Anda dapat mengelola biaya dengan menghindari praktik ETL yang membuat volume besar informasi sementara, atau yang memuat volume besar data baru sebelum menghapus data lama yang tidak dibutuhkan. Jika menghapus data dari klaster Amazon DocumentDB menghasilkan sejumlah besar ruang yang dialokasikan tetapi tidak digunakan, mengatur ulang tanda air yang tinggi memerlukan pembuangan data logis dan memulihkan ke klaster baru, menggunakan alat seperti `mongodump` atau `mongorestore`. Membuat dan memulihkan snapshot tidak mengurangi penyimpanan yang dialokasikan karena tata letak fisik penyimpanan yang mendasarinya tetap sama di snapshot yang dipulihkan.
**catatan**
Menggunakan utilitas seperti `mongodump` dan `mongorestore` dikenakan I/O biaya berdasarkan ukuran data yang sedang dibaca dan ditulis ke volume penyimpanan.
[Untuk informasi tentang penyimpanan I/O dan harga data Amazon DocumentDB, lihat harga dan Harga Amazon [DocumentDB (dengan kompatibilitas MongoDB)](https://aws.amazon.com/documentdb/pricing). FAQs](https://aws.amazon.com/documentdb/faqs/#Pricing)
## Replikasi Amazon DocumentDB
Dalam klaster Amazon DocumentDB, setiap instans replika menampilkan titik akhir independen. Titik akhir replika ini menyediakan akses baca-saja ke data dalam volume klaster. Mereka memungkinkan Anda untuk menskalakan beban kerja baca untuk data Anda melalui beberapa instans yang direplikasi. Mereka juga membantu meningkatkan performa pembacaan data dan meningkatkan ketersediaan data di klaster Amazon DocumentDB Anda. Replika Amazon DocumentDB juga merupakan target failover dan dengan cepat dipromosikan jika instans primer untuk klaster Amazon DocumentDB Anda gagal.
## Keandalan Amazon DocumentDB
Amazon DocumentDB dirancang agar andal, tahan lama, dan toleran terhadap kesalahan. (Untuk meningkatkan ketersediaan, Anda harus mengonfigurasi klaster Amazon DocumentDB Anda sehingga memiliki beberapa instans replika di Availability Zone yang berbeda.) Amazon DocumentDB menyertakan beberapa fitur otomatis yang menjadikannya solusi basis data yang andal.
### Perbaikan penyimpanan otomatis
Amazon DocumentDB menyimpan banyak salinan data Anda di tiga Availability Zone, sangat mengurangi kemungkinan kehilangan data karena kegagalan penyimpanan. Amazon DocumentDB secara otomatis mendeteksi kegagalan di dalam volume klaster. Saat segmen dari sebuah volume klaster gagal, Amazon DocumentDB segera memperbaiki segmen tersebut. Ini menggunakan data dari volume lain yang membentuk volume klaster untuk membantu memastikan bahwa data di segmen yang diperbaiki adalah yang terkini. Akibatnya, Amazon DocumentDB menghindari kehilangan data dan mengurangi kebutuhan untuk melakukan pemulihan untuk memulihkan dari point-in-time kegagalan instans.
### Pemanasan cache yang bisa bertahan
Amazon DocumentDB mengelola cache halamannya dalam proses terpisah dari basis data sehingga cache halaman dapat bertahan secara independen dari basis data. Jika terjadi kegagalan basis data yang tidak terduga, cache halaman tetap berada di memori. Ini memastikan bahwa kumpulan buffer dihangatkan dengan status terkini saat basis data dimulai ulang.
### Pemulihan setelah crash
Amazon DocumentDB dirancang untuk pulih dari crash hampir seketika, dan untuk terus menyajikan data aplikasi Anda. Amazon DocumentDB melakukan pemulihan crash secara asinkron pada utas paralel sehingga basis data Anda terbuka dan tersedia segera setelah kerusakan.
### Tata kelola sumber daya
Amazon DocumentDB melindungi sumber daya yang diperlukan untuk menjalankan proses penting dalam layanan, seperti pemeriksaan kondisi. Untuk melakukan ini, dan ketika instans mengalami tekanan memori tinggi, Amazon DocumentDB akan membatasi permintaan. Akibatnya, beberapa operasi mungkin diantrekan untuk menunggu tekanan memori mereda. Jika tekanan memori berlanjut, operasi yang diantrekan mungkin habis. Anda dapat memantau apakah operasi pelambatan layanan karena memori rendah atau tidak dengan CloudWatch metrik berikut:`LowMemThrottleQueueDepth`,,,`LowMemThrottleMaxQueueDepth`. `LowMemNumOperationsThrottled` `LowMemNumOperationsTimedOut` Untuk informasi selengkapnya, lihat Memantau Amazon CloudWatch DocumentDB dengan. Jika Anda melihat tekanan memori berkelanjutan pada instans Anda sebagai akibat dari LowMem CloudWatch metrik, kami menyarankan Anda meningkatkan skala instance Anda untuk menyediakan memori tambahan untuk beban kerja Anda.
## Baca opsi preferensi
Amazon DocumentDB menggunakan layanan penyimpanan bersama cloud-native yang mereplikasi data enam kali di tiga Availability Zone untuk memberikan tingkat ketahanan yang tinggi. Amazon DocumentDB tidak bergantung pada replikasi data ke beberapa instans untuk mencapai ketahanan. Data klaster Anda tahan lama baik berisi satu instans atau 15 instans.
**Topics**
+ [Tulis daya tahan](#durability-consistency-isolation.write-durability)
+ [Baca isolasi](#durability-consistency-isolation.read-isolation)
+ [Konsistensi baca](#durability-consistency-isolation.read-consistency)
+ [Ketersediaan tinggi](#durability-consistency-isolation.high-availability)
+ [Penskalaan dibaca](#durability-consistency-isolation.scaling-reads)
### Tulis daya tahan
Amazon DocumentDB menggunakan sistem penyimpanan self-healing yang unik, terdistribusi, toleran terhadap kesalahan. Sistem ini mereplikasi enam salinan (V=6) data Anda di tiga AWS Availability Zone untuk memberikan ketersediaan dan daya tahan tinggi. Ketika menulis data, Amazon DocumentDB memastikan bahwa semua penulisan dicatat secara tahan lama di sebagian besar node sebelum menyatakan penulisan ke klien. Jika Anda menjalankan set replika MongoDB tiga simpul, menggunakan perhatian tulis `{w:3, j:true}` akan menghasilkan konfigurasi terbaik saat dibandingkan dengan Amazon DocumentDB.
Penulisan ke klaster Amazon DocumentDB harus diproses oleh instans tulis klaster. Mencoba menulis ke pembaca menghasilkan kesalahan. Tulisan yang diakui dari instance utama Amazon DocumentDB tahan lama, dan tidak dapat diputar kembali. Amazon DocumentDB sangat berdaya tahan secara default dan tidak mendukung opsi tulis yang tidak tahan lama. Anda tidak dapat mengubah tingkat daya tahan (yaitu, perhatian tulis). Amazon DocumentDB mengabaikan w=anything dan secara efektif w: 3 dan j: true. Anda tidak dapat menguranginya.
Karena penyimpanan dan komputasi dipisahkan di dalam arsitektur Amazon DocumentDB, klaster dengan satu instans sangat berdaya tahan. Daya tahan ditangani di lapisan penyimpanan. Hasilnya, klaster Amazon DocumentDB dengan satu instans dan satu dengan tiga instans mencapai tingkat ketahanan yang sama. Anda dapat mengonfigurasi klaster Anda ke kasus penggunaan spesifik Anda sambil tetap memberikan daya tahan tinggi untuk data Anda.
Penulisan ke klaster Amazon DocumentDB bersifat atomik dalam satu dokumen.
Amazon DocumentDB tidak mendukung opsi `wtimeout` dan tidak akan mengembalikan kesalahan jika nilai ditentukan. Penulisan ke instans Amazon DocumentDB primer dijamin tidak akan diblokir tanpa batas waktu.
### Baca isolasi
Pembacaan dari instans Amazon DocumentDB hanya mengembalikan data yang tahan lama sebelum kueri dimulai. Pembacaan tidak pernah mengembalikan data yang dimodifikasi setelah kueri memulai eksekusi, juga bacaan kotor tidak mungkin dilakukan dalam keadaan apa pun.
### Konsistensi baca
Data yang dibaca dari klaster Amazon DocumentDB tahan lama dan tidak akan dibatalkan. Anda dapat mengubah konsistensi baca untuk pembacaan Amazon DocumentDB dengan menentukan preferensi baca untuk permintaan atau koneksi. Amazon DocumentDB tidak mendukung opsi baca yang tidak tahan lama.
Pembacaan dari instans utama cluster Amazon DocumentDB sangat konsisten dalam kondisi operasi normal dan memiliki konsistensi. read-after-write Jika peristiwa failover terjadi antara penulisan dan pembacaan berikutnya, sistem dapat secara singkat mengembalikan pembacaan yang tidak sangat konsisten. Semua pembacaan dari replika baca pada akhirnya konsisten dan mengembalikan data dalam urutan yang sama, dan seringkali dengan jeda replika kurang dari 100 mili detik.
#### Preferensi baca Amazon DocumentDB
Amazon DocumentDB mendukung pengaturan opsi preferensi baca hanya saat membaca data dari titik akhir klaster dalam mode set replika. Mengatur opsi preferensi baca memengaruhi cara klien atau driver MongoDB Anda merutekan permintaan baca ke instans di klaster Amazon DocumentDB Anda. Anda dapat mengatur opsi preferensi baca untuk kueri tertentu, atau sebagai opsi umum di driver MongoDB Anda. (Konsultasikan dokumentasi klien atau driver Anda untuk petunjuk tentang bagaimana cara mengatur opsi preferensi baca.)
Jika klien atau driver Anda tidak terhubung ke titik akhir klaster Amazon DocumentDB dalam mode set replika, hasil penentuan preferensi baca tidak ditentukan.
Amazon DocumentDB tidak mendukung pengaturan *set tag* sebagai preferensi baca.
**Opsi Preferensi Baca Yang Didukung**
+ **`primary`**—Menentukan preferensi baca `primary` membantu memastikan bahwa semua pembacaan dirutekan ke instans primer klaster. Jika instans primer tidak tersedia, operasi baca gagal. Preferensi `primary` baca menghasilkan read-after-write konsistensi dan sesuai untuk kasus penggunaan yang memprioritaskan read-after-write konsistensi daripada ketersediaan tinggi dan penskalaan baca.
Contoh berikut menentukan preferensi baca `primary`:
```
db.example.find().readPref('primary')
```
+ **`primaryPreferred`**—Menentukan rute preferensi baca `primaryPreferred` membaca ke instans primer dalam operasi normal. Jika ada failover primer, klien merutekan permintaan ke replika. Preferensi `primaryPreferred` baca menghasilkan read-after-write konsistensi selama operasi normal, dan akhirnya pembacaan yang konsisten selama peristiwa failover. Preferensi `primaryPreferred` baca sesuai untuk kasus penggunaan yang memprioritaskan read-after-write konsistensi daripada penskalaan baca, tetapi masih membutuhkan ketersediaan tinggi.
Contoh berikut menentukan preferensi baca `primaryPreferred`:
```
db.example.find().readPref('primaryPreferred')
```
+ **`secondary`**—Menentukan preferensi baca `secondary` memastikan bahwa pembacaan hanya dirutekan ke replika, tidak pernah ke instans primer. Jika tidak ada instans replika dalam sebuah klaster, permintaan baca akan gagal. Preferensi `secondary` baca pada akhirnya menghasilkan pembacaan yang konsisten dan sesuai untuk kasus penggunaan yang memprioritaskan throughput penulisan instance utama daripada ketersediaan dan konsistensi yang tinggi. read-after-write
Contoh berikut menentukan preferensi baca `secondary`:
```
db.example.find().readPref('secondary')
```
+ **`secondaryPreferred`**—Menentukan preferensi baca `secondaryPreferred` memastikan bahwa pembacaan dirutekan ke replika baca saat satu atau beberapa replika aktif. Jika tidak ada instans replika aktif dalam sebuah klaster, permintaan baca akan dirutekan ke instans primer. Preferensi baca `secondaryPreferred` menghasilkan bacaan akhir konsisten saat pembacaan dilayani oleh replika baca. Ini menghasilkan read-after-write konsistensi ketika pembacaan dilayani oleh instance utama (kecuali peristiwa failover). Preferensi `secondaryPreferred` baca sesuai untuk kasus penggunaan yang memprioritaskan penskalaan baca dan ketersediaan tinggi daripada konsistensi. read-after-write
Contoh berikut menentukan preferensi baca `secondaryPreferred`:
```
db.example.find().readPref('secondaryPreferred')
```
+ **`nearest`**—Menentukan rute preferensi baca `nearest` membaca hanya berdasarkan latensi terukur antara klien dan semua instans di klaster Amazon DocumentDB. Preferensi baca `nearest` menghasilkan bacaan akhir konsisten saat pembacaan dilayani oleh replika baca. Ini menghasilkan read-after-write konsistensi ketika pembacaan dilayani oleh instance utama (kecuali peristiwa failover). Preferensi `nearest` baca sesuai untuk kasus penggunaan yang memprioritaskan pencapaian latensi baca serendah mungkin dan ketersediaan tinggi daripada read-after-write konsistensi dan penskalaan baca.
Contoh berikut menentukan preferensi baca `nearest`:
```
db.example.find().readPref('nearest')
```
### Ketersediaan tinggi
Amazon DocumentDB mendukung konfigurasi klaster yang sangat tersedia dengan menggunakan replika sebagai target failover untuk instans primer. Jika instans primer gagal, replika Amazon DocumentDB dipromosikan sebagai primer baru, dengan gangguan singkat selama permintaan baca dan tulis yang dibuat ke instans primer gagal dengan pengecualian.
Jika klaster Amazon DocumentDB Anda tidak menyertakan replika apa pun, instans primer akan dibuat ulang selama kegagalan. Namun, mempromosikan replika Amazon DocumentDB jauh lebih cepat daripada membuat ulang instans primer. Jadi kami merekomendasikan Anda membuat satu atau beberapa replika Amazon DocumentDB sebagai target failover.
Replika yang dimaksudkan untuk digunakan sebagai target failover harus dari kelas instans yang sama dengan instans primer. Mereka harus disediakan di Availability Zone yang berbeda dari yang primer. Anda dapat mengontrol replika mana yang lebih disukai sebagai target failover. Untuk praktik terbaik dalam mengonfigurasi Amazon DocumentDB untuk ketersediaan tinggi, lihat [Memahami toleransi kesalahan klaster Amazon DocumentDB](db-cluster-fault-tolerance.md).
### Penskalaan dibaca
Replika Amazon DocumentDB ideal untuk penskalaan baca. Mereka sepenuhnya didedikasikan untuk membaca operasi pada volume klaster Anda, yaitu, replika tidak memproses penulisan. Replikasi data terjadi dalam volume klaster dan bukan di antara instans. Jadi setiap sumber daya replika didedikasikan untuk memproses kueri Anda, bukan mereplikasi dan menulis data.
Jika aplikasi Anda membutuhkan lebih banyak kapasitas baca, Anda dapat menambahkan replika ke klaster Anda dengan cepat (biasanya dalam waktu kurang dari sepuluh menit). Jika persyaratan kapasitas baca Anda berkurang, Anda dapat menghapus replika yang tidak dibutuhkan. Dengan replika Amazon DocumentDB, Anda hanya membayar untuk kapasitas baca yang Anda butuhkan.
Amazon DocumentDB mendukung penskalaan baca sisi klien melalui penggunaan opsi Preferensi Baca. Untuk informasi selengkapnya, lihat [Preferensi baca Amazon DocumentDB](#durability-consistency-isolation.read-preferences).
## TTL menghapus
Penghapusan dari area indeks TTL yang dicapai melalui proses latar belakang adalah upaya terbaik dan tidak dijamin dalam jangka waktu tertentu. Faktor-faktor seperti ukuran instans, pemanfaatan sumber daya instans, ukuran dokumen, dan throughput keseluruhan dapat memengaruhi waktu penghapusan TTL.
Saat monitor TTL menghapus dokumen Anda, setiap penghapusan dikenakan biaya IO, yang akan menambah tagihan Anda. Jika throughput dan tingkat penghapusan TTL meningkat, Anda harus mengharapkan kenaikan tagihan Anda karena peningkatan penggunaan IO.
Saat Anda membuat indeks TTL pada koleksi yang ada, Anda harus menghapus semua dokumen yang kedaluwarsa sebelum membuat indeks. Implementasi TTL saat ini dioptimalkan untuk menghapus sebagian kecil dokumen dalam koleksi, yang biasa terjadi jika TTL diaktifkan pada koleksi dari awal, dan dapat menghasilkan IOPS yang lebih tinggi daripada yang diperlukan jika sejumlah besar dokumen perlu dihapus dalam sekali jalan.
Jika Anda tidak ingin membuat indeks TTL untuk menghapus dokumen, Anda dapat mengelompokkan dokumen ke dalam koleksi berdasarkan waktu, dan cukup membuang koleksi tersebut saat dokumen tidak lagi diperlukan. Misalnya: Anda dapat membuat satu koleksi per minggu dan membuangnya tanpa mengeluarkan biaya IO. Ini dapat secara signifikan menghemat biaya daripada menggunakan indeks TTL.
## Sumber daya yang dapat ditagih
### Mengidentifikasi sumber daya Amazon DocumentDB yang dapat ditagih
Sebagai layanan basis data terkelola penuh, Amazon DocumentDB membebankan biaya untuk instans, penyimpanan, I/O, pencadangan, dan transfer data. Untuk informasi selengkapnya, lihat [Harga Amazon DocumentDB (dengan kompatibilitas MongoDB)](https://aws.amazon.com/documentdb/pricing/).
Untuk menemukan sumber daya yang dapat ditagih di akun Anda dan berpotensi menghapus sumber daya, Anda dapat menggunakan atau. Konsol Manajemen AWS AWS CLI
#### Menggunakan Konsol Manajemen AWS
Dengan menggunakan Konsol Manajemen AWS, Anda dapat menemukan klaster Amazon DocumentDB, instance, dan snapshot yang telah Anda sediakan untuk diberikan. Wilayah AWS
**Untuk menemukan klaster, instans, dan snapshot**
1. [Masuk ke Konsol Manajemen AWS, dan buka konsol Amazon DocumentDB di /docdb. https://console.aws.amazon.com](https://console.aws.amazon.com/docdb)
1. Untuk menemukan sumber daya yang dapat ditagih di Wilayah selain Wilayah default Anda, di sudut kanan atas layar, pilih yang ingin Anda cari. Wilayah AWS
![\[Wilayah Virginia Utara di pemilih wilayah.\]](http://docs.aws.amazon.com/id_id/documentdb/latest/developerguide/images/db-cluster-console-region.png)
1. Di panel navigasi, pilih tipe sumber daya yang dapat ditagih yang Anda minati: **Klaster**, **Instans**, atau **Snapshot**.
![\[Cluster, instance, dan snapshot di panel navigasi.\]](http://docs.aws.amazon.com/id_id/documentdb/latest/developerguide/images/db-navigation-pane-clusters-instances-snapshots.png)
1. Semua klaster, instans, atau snapshot yang Anda sediakan untuk Wilayah terdaftar di panel kanan. Anda akan dikenakan biaya untuk klaster, instans, dan snapshot.
#### Menggunakan AWS CLI
Dengan menggunakan AWS CLI, Anda dapat menemukan klaster Amazon DocumentDB, instance, dan snapshot yang telah Anda sediakan untuk diberikan. Wilayah AWS
**Untuk menemukan klaster dan instans**
Kode berikut mencantumkan semua klaster dan instans Anda untuk Wilayah yang ditentukan. Jika Anda ingin mencari klaster dan instans di Wilayah default, Anda dapat menghilangkan parameter `--region`.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws docdb describe-db-clusters \
--region us-east-1 \
--query 'DBClusters[?Engine==`docdb`]' | \
grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier"
```
Untuk Windows:
```
aws docdb describe-db-clusters ^
--region us-east-1 ^
--query 'DBClusters[?Engine==`docdb`]' | ^
grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier"
```
Output dari operasi ini terlihat seperti berikut ini.
```
"DBClusterIdentifier": "docdb-2019-01-09-23-55-38",
"DBInstanceIdentifier": "docdb-2019-01-09-23-55-38",
"DBInstanceIdentifier": "docdb-2019-01-09-23-55-382",
"DBClusterIdentifier": "sample-cluster",
"DBClusterIdentifier": "sample-cluster2",
```
**Untuk menemukan snapshot**
Kode berikut mencantumkan semua snapshot Anda untuk Wilayah yang ditentukan. Jika Anda ingin mencari snapshot di Wilayah default Anda, Anda dapat menghilangkan parameter `--region`.
Untuk Linux, macOS, atau Unix:
```
aws docdb describe-db-cluster-snapshots \
--region us-east-1 \
--query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]'
```
Untuk Windows:
```
aws docdb describe-db-cluster-snapshots ^
--region us-east-1 ^
--query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]'
```
Output dari operasi ini terlihat seperti berikut ini.
```
[
[
"rds:docdb-2019-01-09-23-55-38-2019-02-13-00-06",
"automated"
],
[
"test-snap",
"manual"
]
]
```
Anda hanya perlu menghapus snapshot `manual`. Snapshot `Automated` dihapus saat Anda menghapus klaster.
### Menghapus sumber daya yang tidak dapat ditagih
Untuk menghapus klaster, Anda harus menghapus semua instans di klaster terlebih dahulu.
+ Untuk menghapus instans, lihat [Menghapus instans Amazon DocumentDB](db-instance-delete.md).
**penting**
Meskipun Anda menghapus instans dalam sebuah klaster, Anda masih ditagih untuk penggunaan penyimpanan dan pencadangan yang terkait dengan klaster tersebut. Untuk menghentikan semua tagihan, Anda juga harus menghapus klaster dan snapshot manual.
+ Untuk menghapus klaster, lihat [Menghapus cluster Amazon DocumentDB](db-cluster-delete.md).
+ Untuk menghapus snapshot manual, lihat [Menghapus snapshot cluster](backup_restore-delete_cluster_snapshot.md).
# Apa itu database dokumen?
Beberapa developer tidak memikirkan model data mereka dalam hal baris dan kolom normal. Biasanya, di tingkat aplikasi, data direpresentasikan sebagai dokumen JSON karena lebih intuitif bagi developer untuk memikirkan model data mereka sebagai dokumen.
Popularitas basis data dokumen telah berkembang karena basis data dokumen ini membuat Anda dapat mempertahanan data dalam basis data dengan menggunakan format model dokumen yang sama yang Anda gunakan dalam kode aplikasi Anda. Database dokumen memberikan yang kuat dan intuitif APIs untuk pengembangan yang fleksibel dan gesit.
**Topics**
+ [Kasus penggunaan](document-database-use-cases.md)
+ [Memahami dokumen](document-database-documents-understanding.md)
+ [Bekerja dengan dokumen](document-database-working-with-documents.md)
# Kasus penggunaan basis data dokumen
Drive kasus penggunaan Anda apakah Anda memerlukan basis data dokumen atau beberapa jenis basis data lain untuk mengelola data Anda. Basis data dokumen berguna untuk beban kerja yang memerlukan skema fleksibel untuk pengembangan yang cepat dan berulang. Berikut ini adalah beberapa contoh kasus penggunaan di mana basis data dokumen dapat memberikan keuntungan yang signifikan:
**Topics**
+ [Profil pengguna](#document-databases-use-cases.user-profiles)
+ [Data besar waktu nyata](#document-databases-use-cases.big-data)
+ [Manajemen konten](#document-databases-use-cases.content-management)
## Profil pengguna
Karena basis data dokumen memiliki skema yang fleksibel, mereka dapat menyimpan dokumen yang memiliki atribut dan nilai data yang berbeda. Basis data dokumen adalah solusi praktis untuk profil online di mana pengguna yang berbeda menyediakan berbagai jenis informasi. Dengan menggunakan basis data dokumen, Anda dapat menyimpan profil setiap pengguna efisien dengan menyimpan hanya atribut yang spesifik untuk setiap pengguna.
Misalkan pengguna memilih untuk menambahkan atau menghapus informasi dari profil mereka. Dalam kasus ini, dokumen mereka dapat dengan mudah diganti dengan versi terbaru yang berisi atribut dan data baru apa pun yang baru ditambahkan atau menghilangkan atribut dan data baru apa pun yang dihilangkan. Basis data dokumen dengan mudah mengelola tingkat individualitas dan fluiditas ini.
## Data besar waktu nyata
Secara historis, kemampuan untuk mengekstrak informasi dari data operasional terhambat oleh fakta bahwa database operasional dan database analitis dipertahankan di lingkungan yang berbeda—operasional dan masing-masing. business/reporting Mampu mengekstrak informasi operasional secara langsung sangat penting dalam lingkungan bisnis yang sangat kompetitif. Dengan menggunakan basis data dokumen, bisnis dapat menyimpan dan mengelola data operasional dari sumber mana pun dan secara bersamaan mengumpankan data ke mesin BI pilihan untuk analisis. Tidak ada persyaratan untuk memiliki dua lingkungan.
## Manajemen konten
Untuk mengelola konten secara efektif, Anda harus dapat mengumpulkan dan mengagregasikan konten dari berbagai sumber, dan kemudian mengirimkannya ke pelanggan. Akibat skema fleksibel mereka, basis data dokumen sempurna untuk mengumpulkan dan menyimpan jenis data apa pun. Anda dapat menggunakannya untuk membuat dan menggabungkan jenis konten baru, termasuk konten buatan pengguna, seperti gambar, komentar, dan video.
# Memahami dokumen
Basis data dokumen digunakan untuk menyimpan data semistruktur sebagai dokumen—alih-alih menormalkan data di beberapa tabel, masing-masing dengan struktur yang unik dan tetap, seperti dalam basis data relasional. Dokumen yang disimpan dalam basis data dokumen menggunakan pasangan nilai kunci nest untuk menyediakan struktur atau skema dokumen. Namun demikian, jenis dokumen yang berbeda dapat disimpan dalam basis data dokumen yang sama, sehingga memenuhi persyaratan untuk memproses data serupa yang dalam format yang berbeda. Sebagai contoh, karena setiap dokumen dijelaskan sendiri, dokumen yang dienkodekan JSON untuk toko online yang dijelaskan dalam topik [Contoh dokumen dalam database dokumen](#document-database-documents) dapat disimpan dalam basis data dokumen yang sama.
**Topics**
+ [SQL vs. terminologi non-relasional](#document-database-sql-vs-nosql-terms)
+ [Dokumen sederhana](#document-database-documents-simple)
+ [Dokumen yang disematkan](#document-database-documents-embeded)
+ [Contoh dokumen dalam database dokumen](#document-database-documents)
+ [Memahami normalisasi dalam database dokumen](#document-database-normalization)
## SQL vs. terminologi non-relasional
Tabel berikut ini membandingkan terminologi yang digunakan oleh basis data dokumen (MongoDB) dengan terminologi yang digunakan oleh basis data SQL.
| SQL | MongoDB |
| --- | --- |
| Tabel | Koleksi |
| Baris | Dokumen |
| Kolom | Bidang |
| Kunci Primer | ObjectId |
| Indeks | Indeks |
| Lihat | Lihat |
| Tabel atau objek nest | Dokumen tersemat |
| Array | Array |
## Dokumen sederhana
Semua dokumen dalam basis data dokumen adalah dijelaskan sendiri. Dokumentasi ini menggunakan dokumen berformat seperti JSON, meskipun Anda dapat menggunakan cara pengenkodean lain.
Dokumen sederhana memiliki satu atau lebih bidang yang semuanya pada tingkat yang sama di dalam dokumen. Dalam contoh berikut ini, bidang `SSN`, `LName`, `FName`, `DOB`, `Street`, `City`, `State-Province`, `PostalCode`, dan`Country` semuanya adalah saudara kandung di dalam dokumen.
```
{
"SSN": "123-45-6789",
"LName": "Rivera",
"FName": "Martha",
"DOB": "1992-11-16",
"Street": "125 Main St.",
"City": "Anytown",
"State-Province": "WA",
"PostalCode": "98117",
"Country": "USA"
}
```
Ketika informasi diatur dalam dokumen sederhana, setiap bidang terkelola secara individual. Untuk mengambil alamat seseorang, Anda harus mengambil `Street`, `City`,`State-Province`, `PostalCode`, dan `Country` sebagai item data individu.
## Dokumen yang disematkan
Dokumen kompleks mengatur datanya dengan membuat dokumen tersemat di dalam dokumen. Dokumen tersemat membantu mengelola data dalam pengelompokan dan sebagai item data individual, mana yang lebih efisien dalam kasus tertentu. Dengan menggunakan contoh sebelumnya, Anda dapat menyematkan dokumen `Address` dalam dokumen utama. Melakukan hal ini akan menghasilkan struktur dokumen berikut ini:
```
{
"SSN": "123-45-6789",
"LName": "Rivera",
"FName": "Martha",
"DOB": "1992-11-16",
"Address":
{
"Street": "125 Main St.",
"City": "Anytown",
"State-Province": "WA",
"PostalCode": "98117",
"Country": "USA"
}
}
```
Anda sekarang dapat mengakses data dalam dokumen sebagai bidang individu ( `"SSN":` ), sebagai dokumen tersemat ( `"Address":` ), atau sebagai anggota dokumen tersemat ( `"Address":{"Street":}` ).
## Contoh dokumen dalam database dokumen
Seperti yang dinyatakan sebelumnya, karena setiap dokumen dalam basis data dokumen adalah dijelaskan sendiri, struktur dokumen di dalam basis data dokumen dapat berbeda satu sama lain. Dua dokumen berikut ini, satu untuk buku dan satu lagi untuk majalah, berbeda secara struktural. Namun keduanya dapat dalam basis data dokumen yang sama.
Berikut ini adalah dokumen buku sampel:
```
{
"_id" : "9876543210123",
"Type": "book",
"ISBN": "987-6-543-21012-3",
"Author":
{
"LName":"Roe",
"MI": "T",
"FName": "Richard"
},
"Title": "Understanding Document Databases"
}
```
Berikut ini adalah dokumen majalah sampel dengan dua artikel:
```
{
"_id" : "0123456789012",
"Publication": "Programming Today",
"Issue":
{
"Volume": "14",
"Number": "09"
},
"Articles" : [
{
"Title": "Is a Document Database Your Best Solution?",
"Author":
{
"LName": "Major",
"FName": "Mary"
}
},
{
"Title": "Databases for Online Solutions",
"Author":
{
"LName": "Stiles",
"FName": "John"
}
}
],
"Type": "periodical"
}
```
Bandingkan struktur kedua dokumen tersebut. Dengan basis data relasional, Anda perlu memisah tabel “majalah” dan “buku”, atau satu tabel dengan bidang yang tidak terpakai, seperti “Publikasi”, “Terbitan”, “Artikel”, dan “MI”, sebagai nilai `null`. Karena basis data dokumen adalah semistruktur, dengan setiap dokumen mendefinisikan strukturnya sendiri, kedua dokumen tersebut dapat hidup berdampingan dalam basis data dokumen yang sama tanpa bidang `null`. Basis data dokumen baik dalam menangani data yang jarang.
Mengembangkan terhadap basis data dokumen memungkinkan pengembangan yang cepat dan berulang. Hal ini karena Anda dapat mengubah struktur data dokumen secara dinamis, tanpa harus mengubah skema untuk seluruh koleksi. Basis data dokumen sangat cocok untuk pengembangan tangkas dan secara dinamis mengubah lingkungan.
## Memahami normalisasi dalam database dokumen
Basis data dokumen tidak dinormalisasi; data yang ditemukan dalam satu dokumen dapat diulang dalam dokumen lainnya. Lebih lanjut, beberapa perbedaan data dapat ada di antara dokumen. Sebagai contoh, pertimbangkan skenario di mana Anda melakukan pembelian di toko online dan semua detail pembelian Anda disimpan dalam dokumen tunggal. Dokumen mungkin terlihat seperti dokumen JSON berikut ini:
```
{
"DateTime": "2018-08-15T12:13:10Z",
"LName" : "Santos",
"FName" : "Paul",
"Cart" : [
{
"ItemId" : "9876543210123",
"Description" : "Understanding Document Databases",
"Price" : "29.95"
},
{
"ItemId" : "0123456789012",
"Description" : "Programming Today",
"Issue": {
"Volume": "14",
"Number": "09"
},
"Price" : "8.95"
},
{
"ItemId": "234567890-K",
"Description": "Gel Pen (black)",
"Price": "2.49"
}
],
"PaymentMethod" :
{
"Issuer" : "MasterCard",
"Number" : "1234-5678-9012-3456"
},
"ShopperId" : "1234567890"
}
```
Semua informasi ini disimpan sebagai dokumen dalam koleksi transaksi. Kemudian, Anda menyadari bahwa Anda lupa membeli satu item. Sehingga Anda kembali masuk ke toko yang sama dan melakukan pembelian lainnya, yang juga disimpan sebagai dokumen lainnya dalam koleksi transaksi.
```
{
"DateTime": "2018-08-15T14:49:00Z",
"LName" : "Santos",
"FName" : "Paul",
"Cart" : [
{
"ItemId" : "2109876543210",
"Description" : "Document Databases for Fun and Profit",
"Price" : "45.95"
}
],
"PaymentMethod" :
{
"Issuer" : "Visa",
"Number" : "0987-6543-2109-8765"
},
"ShopperId" : "1234567890"
}
```
Perhatikan redundansi antara kedua dokumen tersebut—nama dan ID pembelanja Anda (dan, jika Anda menggunakan kartu kredit yang sama, informasi kartu kredit Anda). Tapi hal ini tidak apa-apa karena penyimpanan murah, dan setiap dokumen benar-benar mencatat transaksi tunggal yang dapat diambil dengan cepat dengan kueri nilai kunci sederhana tanpa harus bergabung.
Terdapat juga perbedaan yang jelas antara kedua dokumen—informasi kartu kredit Anda. Ini hanya perbedaan yang jelas karena kemungkinan Anda akan menggunakan kartu kredit yang berbeda untuk setiap pembelian. Setiap dokumen akurat untuk transaksi yang didokumentasikan.
# Bekerja dengan dokumen
Sebagai basis data dokumen, Amazon DocumentDB membuatnya mudah untuk menyimpan, membuat kueri, dan membuat indeks data JSON. Di Amazon DocumentDB, koleksi analog dengan tabel dalam basis data relasional, kecuali tidak ada skema tunggal ditegakkan pada semua dokumen. Koleksi memungkinkan Anda mengelompokkan dokumen yang serupa bersama-sama sembari menjaga mereka semua dalam basis data yang sama, tanpa mengharuskan bahwa mereka identik dalam struktur.
Dengan menggunakan contoh dokumen dari bagian sebelumnya, kemungkinan bahwa Anda akan memiliki koleksi untuk `reading_material` dan `office_supplies`. Merupakan tanggung jawab perangkat lunak Anda untuk menegakkan koleksi yang memiliki dokumen tersebut.
Contoh berikut ini menggunakan MongoDB API untuk menunjukkan bagaimana untuk menambahkan, kueri, pembaruan, dan menghapus dokumen.
**Topics**
+ [Menambahkan dokumen](#document-database-adding-documents)
+ [Menanyakan dokumen](#document-database-queries)
+ [Memperbarui dokumen](#document-database-updating)
+ [Menghapus dokumen](#document-database-deleting)
## Menambahkan dokumen
Di Amazon DocumentDB, basis data dibuat saat pertama kali Anda menambahkan dokumen ke koleksi. Dalam contoh ini, Anda membuat koleksi yang diberi nama `example` di basis data `test`, yang merupakan basis data default ketika Anda terhubung ke klaster. Karena koleksi secara implisit dibuat ketika dokumen pertama dimasukkan, tidak ada pemeriksaan kesalahan nama koleksi. Oleh karena itu, salah ketik dalam nama koleksi, seperti `eexample` alih-alih `example`, akan membuat dan menambahkan dokumen ke koleksi `eexample` alih-alih ke koleksi yang dimaksudkan. Pemeriksaan kesalahan harus ditangani oleh aplikasi Anda.
Contoh berikut ini menggunakan API MongoDB untuk menambahkan dokumen.
**Topics**
+ [Menambahkan satu dokumen](#document-database-adding-documents-single)
+ [Menambahkan beberapa dokumen](#document-database-adding-documents-multiple)
### Menambahkan satu dokumen
Untuk menambahkan dokumen tunggal ke koleksi, gunakan operasi `insertOne( {} )` dengan dokumen yang ingin Anda tambahkan ke koleksi.
```
db.example.insertOne(
{
"Item": "Ruler",
"Colors": ["Red","Green","Blue","Clear","Yellow"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 40
},
"UnitPrice": 0.89
}
)
```
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"acknowledged" : true,
"insertedId" : ObjectId("5bedafbcf65ff161707de24f")
}
```
### Menambahkan beberapa dokumen
Untuk menambahkan beberapa dokumen ke koleksi, gunakan operasi `insertMany( [{},...,{}] )` dengan daftar dokumen yang ingin Anda tambahkan ke koleksi. Meskipun dokumen dalam daftar khusus ini memiliki skema yang berbeda, mereka semua dapat ditambahkan ke koleksi yang sama.
```
db.example.insertMany(
[
{
"Item": "Pen",
"Colors": ["Red","Green","Blue","Black"],
"Inventory": {
"OnHand": 244,
"MinOnHand": 72
}
},
{
"Item": "Poster Paint",
"Colors": ["Red","Green","Blue","Black","White"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50
}
},
{
"Item": "Spray Paint",
"Colors": ["Black","Red","Green","Blue"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50,
"OrderQnty": 36
}
}
]
)
```
Keluaran dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"acknowledged" : true,
"insertedIds" : [
ObjectId("5bedb07941ca8d9198f5934c"),
ObjectId("5bedb07941ca8d9198f5934d"),
ObjectId("5bedb07941ca8d9198f5934e")
]
}
```
## Menanyakan dokumen
Terkadang, Anda mungkin perlu mencari inventaris toko online Anda sehingga pelanggan dapat melihat dan membeli apa yang Anda jual. Melakukan kueri sebuah koleksi relatif mudah, apakah Anda ingin semua dokumen dalam koleksi atau hanya dokumen yang memenuhi kriteria tertentu.
Untuk melakukan kueri dokumen, gunakan operasi `find()`. Perintah `find()` memiliki parameter dokumen tunggal yang mendefinisikan kriteria yang akan digunakan dalam memilih dokumen yang akan dikembalikan. Output dari `find()` adalah dokumen yang diformat sebagai satu baris teks tanpa jeda baris. Untuk memformat dokumen output agar lebih mudah dibaca, gunakan `find().pretty()`. Semua contoh dalam topik ini menggunakan `.pretty()` untuk memformat keluaran.
Gunakan empat dokumen yang Anda masukkan ke dalam koleksi `example` dalam dua latihan sebelumnya — `insertOne()` dan `insertMany()`.
**Topics**
+ [Mengambil semua dokumen dalam koleksi](#document-database-queries-all-documents)
+ [Mengambil dokumen yang cocok dengan nilai bidang](#document-database-queries-match-criteria)
+ [Mengambil dokumen yang cocok dengan dokumen yang disematkan](#document-database-queries-entire-embedded-document)
+ [Mengambil dokumen yang cocok dengan nilai bidang dalam dokumen yang disematkan](#document-database-queries-embeded-document-field)
+ [Mengambil dokumen yang cocok dengan array](#document-database-queries-array-match)
+ [Mengambil dokumen yang cocok dengan nilai dalam array](#document-database-queries-array-value-match)
+ [Mengambil dokumen menggunakan operator](#document-database-query-operators)
### Mengambil semua dokumen dalam koleksi
Untuk mengambil semua dokumen dalam koleksi Anda, gunakan operasi `find()` dengan dokumen kueri yang kosong.
Kueri berikut mengembalikan semua dokumen di dalam koleksi `example`.
```
db.example.find( {} ).pretty()
```
### Mengambil dokumen yang cocok dengan nilai bidang
Untuk mengambil semua dokumen yang cocok dengan bidang dan nilai, gunakan operasi `find()` dengan dokumen kueri yang mengidentifikasi bidang dan nilai untuk mencocokkan.
Menggunakan dokumen sebelumnya, kueri ini mengembalikan semua dokumen di mana bidang "Item" sama dengan "Pena".
```
db.example.find( { "Item": "Pen" } ).pretty()
```
### Mengambil dokumen yang cocok dengan dokumen yang disematkan
Untuk menemukan semua dokumen yang cocok dengan dokumen tersemat, gunakan operasi `find()` dengan dokumen kueri yang menentukan nama dokumen tersemat dan semua bidang dan nilai untuk dokumen tersemat.
Saat mencocokkan dokumen yang ditanamkan, dokumen yang ditanamkan tersebut harus memiliki nama yang sama seperti dalam kueri. Selain itu, bidang dan nilai dalam dokumen yang ditanamkan harus cocok dengan kueri.
Kueri berikut hanya mengembalikan dokumen "Cat Poster". Ini karena "Pena" memiliki nilai yang berbeda untuk "`OnHand`" dan "`MinOnHand`", dan "Cat Semprot" memiliki satu bidang (`OrderQnty`) lebih banyak daripada dokumen kueri.
```
db.example.find({"Inventory": {
"OnHand": 47,
"MinOnHand": 50 } } ).pretty()
```
### Mengambil dokumen yang cocok dengan nilai bidang dalam dokumen yang disematkan
Untuk menemukan semua dokumen yang cocok dengan dokumen tersemat, gunakan operasi `find()` dengan dokumen kueri yang menentukan nama dokumen tersemat dan semua bidang dan nilai untuk dokumen tersemat.
Mengingat dokumen sebelumnya, kueri berikut menggunakan "notasi titik" untuk menentukan dokumen yang ditanamkan dan bidang yang diminati. Setiap dokumen yang cocok dengan ini dikembalikan, terlepas dari apa bidang lain mungkin hadir dalam dokumen tertanam. Kueri mengembalikan "Cat Poster" dan "Cat Semprot" karena keduanya cocok dengan bidang dan nilai yang ditentukan.
```
db.example.find({"Inventory.OnHand": 47, "Inventory.MinOnHand": 50 }).pretty()
```
### Mengambil dokumen yang cocok dengan array
Untuk menemukan semua dokumen yang cocok dengan susunan, gunakan operasi `find()` dengan nama susunan yang menjadi perhatian Anda dan semua nilai dalam susunan tersebut. Kueri mengembalikan semua dokumen yang memiliki array dengan nama itu di mana nilai arraynya identik dengan dan dalam urutan yang sama seperti dalam kueri.
Kueri berikut hanya mengembalikan "Pena" karena "Cat Poster" memiliki warna tambahan (Putih), dan "Cat Semprot" memiliki warna dalam urutan yang berbeda.
```
db.example.find( { "Colors": ["Red","Green","Blue","Black"] } ).pretty()
```
### Mengambil dokumen yang cocok dengan nilai dalam array
Untuk menemukan semua dokumen yang memiliki nilai susunan tertentu, gunakan operasi `find()` dengan nama susunan dan nilai yang menjadi perhatian Anda.
```
db.example.find( { "Colors": "Red" } ).pretty()
```
Operasi sebelumnya mengembalikan ketiga dokumen karena masing-masing memiliki array bernama `Colors` dan nilai "`Red`" di suatu tempat dalam array. Jika Anda menentukan nilai "`White`", kueri hanya akan mengembalikan "Cat Poster."
### Mengambil dokumen menggunakan operator
Kueri berikut ini mengembalikan semua dokumen di mana nilai "`Inventory.OnHand`" adalah kurang dari 50.
```
db.example.find(
{ "Inventory.OnHand": { $lt: 50 } } )
```
Untuk daftar operator kueri yang didukung, lihat [Operator kueri dan proyeksi](mongo-apis.md#mongo-apis-query).
## Memperbarui dokumen
Biasanya, dokumen Anda tidak statis dan diperbarui sebagai bagian dari alur kerja aplikasi Anda. Contoh berikut ini menunjukkan beberapa cara yang dapat lakukan Anda untuk memperbarui dokumen.
Untuk memperbarui dokumen yang ada, gunakan operasi `update()`. Operasi `update()` memiliki dua parameter dokumen. Dokumen pertama mengidentifikasi dokumen atau dokumen-dokumen mana yang akan diperbarui. Dokumen kedua menentukan pembaruan yang akan dilakukan.
Ketika Anda memperbarui bidang yang ada — apakah bidang itu adalah bidang sederhana, susunan, atau dokumen tersemat -— Anda harus menentukan nama bidang dan nilainya. Pada akhir operasi, seolah-olah bidang dalam dokumen lama telah digantikan oleh bidang dan nilai baru.
**Topics**
+ [Memperbarui nilai bidang yang ada](#document-database-updating-existing-fields)
+ [Menambahkan bidang baru](#document-database-updating-adding-field)
+ [Mengganti dokumen yang disematkan](#document-database-replacing-embedded-document)
+ [Memasukkan bidang baru ke dalam dokumen yang disematkan](#document-database-updating-adding-field-embedded)
+ [Menghapus bidang dari dokumen](#document-database-remove-field)
+ [Menghapus bidang dari beberapa dokumen](#document-database-remove-field-all)
### Memperbarui nilai bidang yang ada
Gunakan empat dokumen berikut ini yang Anda tambahkan sebelumnya untuk operasi pembaruan berikut ini.
```
{
"Item": "Ruler",
"Colors": ["Red","Green","Blue","Clear","Yellow"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 40
},
"UnitPrice": 0.89
},
{
"Item": "Pen",
"Colors": ["Red","Green","Blue","Black"],
"Inventory": {
"OnHand": 244,
"MinOnHand": 72
}
},
{
"Item": "Poster Paint",
"Colors": ["Red","Green","Blue","Black","White"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50
}
},
{
"Item": "Spray Paint",
"Colors": ["Black","Red","Green","Blue"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50,
"OrderQnty": 36
}
}
```
**Untuk memperbarui bidang sederhana**
Untuk memperbarui bidang sederhana, gunakan `update()` dengan `$set` untuk menentukan nama bidang dan nilai baru. Contoh berikut ini mengubah `Item` dari “Pen” ke “Gel Pen”.
```
db.example.update(
{ "Item" : "Pen" },
{ $set: { "Item": "Gel Pen" } }
)
```
Hasil dari operasi ini terlihat seperti berikut ini.
```
{
"Item": "Gel Pen",
"Colors": ["Red","Green","Blue","Black"],
"Inventory": {
"OnHand": 244,
"MinOnHand": 72
}
}
```
**Untuk memperbarui susunan**
Contoh berikut ini menggantikan susunan warna yang ada dengan susunan baru yang mencakup `Orange` dan menghapus `White` dari daftar warna. Daftar warna baru adalah dalam urutan yang ditentukan dalam operasi `update()`.
```
db.example.update(
{ "Item" : "Poster Paint" },
{ $set: { "Colors": ["Red","Green","Blue","Orange","Black"] } }
)
```
Hasil dari operasi ini terlihat seperti berikut ini.
```
{
"Item": "Poster Paint",
"Colors": ["Red","Green","Blue","Orange","Black"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50
}
}
```
### Menambahkan bidang baru
Untuk mengubah dokumen dengan menambahkan satu atau lebih bidang baru, gunakan operasi `update()` dengan dokumen kueri yang mengidentifikasi dokumen yang akan dimasukkan dan bidang dan nilai baru yang akan dimasukkan menggunakan operator `$set`.
Contoh berikut ini menambahkan bidang `UnitPrice` dengan nilai `3.99` ke dokumen Spray Paints. Perhatikan bahwa nilai `3.99` adalah numerik dan bukan string.
```
db.example.update(
{ "Item": "Spray Paint" },
{ $set: { "UnitPrice": 3.99 } }
)
```
Hasil dari operasi ini terlihat seperti berikut ini (format JSON).
```
{
"Item": "Spray Paint",
"Colors": ["Black","Red","Green","Blue"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50,
"OrderQnty": 36
},
"UnitPrice": 3.99
}
```
### Mengganti dokumen yang disematkan
Untuk mengubah dokumen dengan mengganti dokumen tersemat, gunakan operasi `update()` dengan dokumen yang mengidentifikasi dokumen tersemat dan bidang dan nilai barunya menggunakan operator `$set`.
Mengingat dokumen berikut.
```
db.example.insert({
"DocName": "Document 1",
"Date": {
"Year": 1987,
"Month": 4,
"Day": 18
}
})
```
**Untuk mengganti dokumen tersemat**
Contoh berikut ini menggantikan dokumen Tanggal saat ini dengan yang dokumen baru yang hanya memiliki bidang `Month` dan `Day`; `Year` telah dihilangkan.
```
db.example.update(
{ "DocName" : "Document 1" },
{ $set: { "Date": { "Month": 4, "Day": 18 } } }
)
```
Hasil dari operasi ini terlihat seperti berikut ini.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18
}
}
```
### Memasukkan bidang baru ke dalam dokumen yang disematkan
**Untuk menambahkan bidang ke dokumen tersemat**
Untuk mengubah dokumen dengan menambahkan satu atau lebih bidang baru ke dokumen tersemat, gunakan operasi `update()` dengan dokumen yang mengidentifikasi dokumen tersemat dan “notasi dot” untuk menentukan dokumen tersemat dan bidang dan nilai baru yang akan dimasukkan menggunakan operator `$set`.
Mengingat dokumen berikut ini, kode berikut ini menggunakan “notasi dot” untuk memasukkan bidang `Year` dan `DoW` ke dokumen `Date`yang disematkan, dan `Words` ke dalam dokumen induk.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18
}
}
```
```
db.example.update(
{ "DocName" : "Document 1" },
{ $set: { "Date.Year": 1987,
"Date.DoW": "Saturday",
"Words": 2482 } }
)
```
Hasil dari operasi ini terlihat seperti berikut ini.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18,
"Year": 1987,
"DoW": "Saturday"
},
"Words": 2482
}
```
### Menghapus bidang dari dokumen
Untuk mengubah dokumen dengan menghapus bidang dari dokumen, gunakan operasi `update()` dengan dokumen kueri yang mengidentifikasi dokumen yang akan dihapus bidangnya, dan operator `$unset` untuk menentukan bidang yang akan dihapus.
Contoh berikut ini akan menghapus bidang `Words`dari dokumen sebelumnya.
```
db.example.update(
{ "DocName" : "Document 1" },
{ $unset: { Words:1 } }
)
```
Hasil dari operasi ini terlihat seperti berikut ini.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18,
"Year": 1987,
"DoW": "Saturday"
}
}
```
### Menghapus bidang dari beberapa dokumen
Untuk mengubah dokumen dengan menghapus bidang dari beberapa dokumen, gunakan operasi `update()` dengan operator `$unset` dan `multi` diatur ke `true`.
Contoh berikut ini akan menghapus bidang `Inventory` dari semua dokumen dalam koleksi contoh. Jika dokumen tidak memiliki bidang `Inventory`, tidak ada tindakan yang dilakukan pada dokumen tersebut. Jika `multi: true` dihilangkan, tindakan dilakukan hanya pada dokumen pertama yang memenuhi kriteria.
```
db.example.update(
{},
{ $unset: { Inventory:1 } },
{ multi: true }
)
```
## Menghapus dokumen
Untuk menghapus dokumen dari basis data Anda, gunakan operasi `remove()`, yang menentukan dokumen yang akan dihapus. Kode berikut ini menghapus “Gel Pen” dari koleksi `example` Anda.
```
db.example.remove( { "Item": "Gel Pen" } )
```
Untuk menghapus semua dokumen dari database Anda, gunakan `remove()` operasi dengan kueri kosong.
```
db.example.remove( { } )
```