Tingkat Konsistensi di Azure Cosmos DB
BERLAKU UNTUK: 
Nosql MongoDB Cassandra Gremlin Meja
Database terdistribusi yang mengandalkan replikasi untuk ketersediaan tinggi, latensi rendah, atau keduanya, harus melakukan tradeoff mendasar antara konsistensi baca, ketersediaan, latensi, dan throughput sebagaimana didefinisikan oleh theorem PACELC. Linearizability dari model konsistensi yang kuat adalah standar emas dari programmability data. Tetapi menambahkan harga yang curam dari latensi tulis yang lebih tinggi karena data harus mereplikasi dan menerapkan dalam jarak besar. Konsistensi yang kuat juga dapat menderita berkurangnya ketersediaan (selama kegagalan) karena data tidak dapat mereplikasi dan berkomitmen di setiap wilayah. Konsistensi akhir menawarkan ketersediaan yang lebih tinggi dan performa yang lebih baik, tetapi lebih sulit untuk memprogram aplikasi karena data mungkin tidak konsisten di semua wilayah.
Sebagian besar database NoSQL terdistribusi yang tersedia secara komersial yang tersedia di pasar saat ini hanya memberikan konsistensi yang kuat dan berkaitan dengan peristiwa. Azure Cosmos DB menawarkan lima level yang terdefinisi dengan baik. Dari yang terkuat hingga terlemah, levelnya adalah:
Untuk informasi selengkapnya tentang tingkat konsistensi default, lihat mengonfigurasi tingkat konsistensi default atau mengambil alih tingkat konsistensi default.
Setiap level menyediakan ketersediaan dan tradeoff performa. Gambar berikut menunjukkan tingkat konsistensi yang berbeda sebagai spektrum.
Tingkat konsistensi dan API Azure Cosmos DB
Azure Cosmos DB menyediakan dukungan native untuk API yang kompatibel dengan protokol kawat untuk database populer. Ini termasuk MongoDB, Apache Cassandra, Apache Gremlin, dan Azure Table Storage. Di API untuk Gremlin atau Tabel, tingkat konsistensi default yang dikonfigurasi pada akun Azure Cosmos DB digunakan. Untuk detail tentang pemetaan tingkat konsistensi antara Apache Cassandra dan Azure Cosmos DB, lihat API untuk pemetaan konsistensi Cassandra. Untuk detail tentang pemetaan tingkat konsistensi antara MongoDB dan Azure Cosmos DB, lihat API untuk pemetaan konsistensi MongoDB.
Cakupan konsistensi baca
Konsistensi baca berlaku untuk satu operasi baca yang tercakup dalam partisi logika. Klien jarak jauh atau prosedur tersimpan dapat mengeluarkan operasi baca.
Mengonfigurasi tingkat konsistensi default
Anda dapat mengonfigurasi tingkat konsistensi default di akun Azure Cosmos DB Anda kapan saja. Tingkat konsistensi default yang dikonfigurasi pada akun Anda berlaku untuk semua database dan kontainer Azure Cosmos DB di bawah akun tersebut. Semua baca dan kueri yang dikeluarkan terhadap kontainer atau database menggunakan tingkat konsistensi yang ditentukan secara default. Saat Anda mengubah konsistensi tingkat akun, pastikan Anda menyebarkan ulang aplikasi dan membuat modifikasi kode yang diperlukan untuk menerapkan perubahan ini. Untuk mempelajari selengkapnya, lihat cara mengonfigurasi tingkat konsistensi default. Anda juga dapat mengganti tingkat konsistensi default untuk permintaan tertentu, untuk mempelajari selengkapnya, lihat artikel cara Mengganti tingkat konsistensi default.
Tip
Mengambil alih tingkat konsistensi default hanya berlaku untuk membaca dalam klien SDK. Akun yang dikonfigurasi untuk konsistensi yang kuat secara default masih akan menulis dan mereplikasi data secara sinkron ke setiap wilayah akun. Ketika instans klien SDK atau permintaan mengambil alih ini dengan Sesi atau konsistensi yang lebih lemah, pembacaan akan dilakukan menggunakan satu replika. Untuk informasi selengkapnya, lihat Tingkat konsistensi dan throughput.
Penting
Diperlukan untuk membuat ulang instans SDK apa pun setelah mengubah tingkat konsistensi default. Ini dapat dilakukan dengan memulai ulang aplikasi. Ini memastikan SDK menggunakan tingkat konsistensi default baru.
Jaminan yang terkait dengan tingkat konsistensi
Azure Cosmos DB menjamin bahwa 100 persen permintaan baca memenuhi jaminan konsistensi untuk tingkat konsistensi yang dipilih. Definisi yang tepat dari lima tingkat konsistensi di Azure Cosmos DB menggunakan bahasa spesifikasi TLA + disediakan dalam repo azure-cosmos-tla GitHub.
Semantik dari lima tingkat konsistensi dijelaskan di bagian berikut.
Konsistensi kuat
Konsistensi yang kuat menawarkan jaminan linearizability. Linearizability mengacu pada permintaan penyajian secara bersamaan. Bacaan dijamin akan mengembalikan versi terapan item yang terbaru. Klien tidak pernah melihat tulisan yang belum diterapkan atau sebagian. Pengguna selalu dijamin membaca tulisan terbaru yang diterapkan.
Grafik berikut menggambarkan konsistensi kuat dengan not musik. Setelah data ditulis ke wilayah "WEST US 2", ketika Anda membaca data dari wilayah lain, Anda mendapatkan nilai terbaru:
Konsistensi keusangan terikat
Untuk akun tulis wilayah tunggal dengan dua wilayah atau lebih, data direplikasi dari wilayah utama ke semua wilayah sekunder (baca-saja). Untuk akun tulis multi-wilayah dengan dua wilayah atau lebih, data direplikasi dari wilayah yang awalnya ditulis ke semua wilayah bisa-tulis lainnya. Dalam kedua skenario, meskipun tidak umum, terkadang mungkin ada jeda replikasi dari satu wilayah ke wilayah lain.
Dalam konsistensi keusangan terikat, jeda data antara dua wilayah selalu kurang dari jumlah yang ditentukan. Jumlahnya dapat berupa versi "K" (yaitu, "pembaruan") dari item atau dengan interval waktu "T", mana yang tercapai terlebih dahulu. Dengan kata lain, ketika Anda memilih keusangan terikat, "keusangan" maksimum data di wilayah mana pun dapat dikonfigurasi dengan dua cara:
- Jumlah versi (K) item
- Interval waktu (T) berbunyi mungkin tertinggal dari tulisan
Keusangan Terikat bermanfaat terutama untuk akun tulis satu wilayah dengan dua wilayah atau lebih. Jika lag data di suatu wilayah (ditentukan per partisi fisik) melebihi nilai keusangan yang dikonfigurasi, menulis untuk partisi tersebut dibatasi sampai kedaluarsa kembali dalam batas atas yang dikonfigurasi.
Untuk akun satu wilayah, Bounded Staleness memberikan jaminan konsistensi tulis yang sama dengan Sesi dan Konsistensi Akhir. Dengan Keusangan Terikat, data direplikasi ke mayoritas lokal (tiga replika dalam empat set replika) di satu wilayah.
Penting
Dengan konsistensi Keusangan Terikat, pemeriksaan kedaluarsa hanya dilakukan di seluruh wilayah dan tidak dalam suatu wilayah. Dalam wilayah tertentu, data selalu direplikasi ke mayoritas lokal (tiga replika dalam empat set replika) terlepas dari tingkat konsistensi.
Membaca saat menggunakan Bounded Staleness mengembalikan data terbaru yang tersedia di wilayah tersebut dengan membaca dari dua replika yang tersedia di wilayah tersebut. Karena penulisan dalam suatu wilayah selalu mereplikasi ke mayoritas lokal (tiga dari empat replika), berkonsultasi dengan dua replika mengembalikan data yang paling diperbarui yang tersedia di wilayah tersebut.
Penting
Dengan konsistensi Bounded Staleness, bacaan yang dikeluarkan terhadap wilayah non-primer mungkin belum tentu mengembalikan versi terbaru data secara global, tetapi dijamin untuk mengembalikan versi terbaru data di wilayah tersebut, yang akan berada dalam batas keusangan maksimum secara global.
Bounded Staleness berfungsi paling baik untuk aplikasi yang didistribusikan secara global menggunakan akun tulis satu wilayah dengan dua wilayah atau lebih, di mana konsistensi yang mendekati kuat di seluruh wilayah diinginkan. Untuk akun tulis multi-wilayah dengan dua wilayah atau lebih, server aplikasi harus mengarahkan baca dan tulis ke wilayah yang sama tempat server aplikasi dihosting. Keusangan Terikat dalam akun multi-tulis adalah anti-pola. Tingkat ini akan memerlukan dependensi pada lag replikasi antar wilayah, yang seharusnya tidak masalah jika data dibaca dari wilayah yang sama tempat data ditulis.
Grafik berikut mengilustrasikan konsistensi keusangan terikat dengan catatan musik. Setelah data ditulis ke wilayah "WEST US 2", wilayah "East US 2" dan "Australia East" membaca nilai tertulis berdasarkan waktu jeda maksimum yang dikonfigurasi atau operasi maksimum:
Konsistensi sesi
Dalam konsistensi sesi, dalam satu sesi klien, bacaan dijamin untuk menghormati jaminan baca-tulis Anda, dan tulis-ikuti-baca. Jaminan ini mengasumsikan satu sesi "penulis" atau berbagi token sesi untuk beberapa penulis.
Seperti semua tingkat konsistensi yang lebih lemah daripada Kuat, penulisan direplikasi ke minimal tiga replika (dalam empat set replika) di wilayah lokal, dengan replikasi asinkron ke semua wilayah lain.
Setelah setiap operasi tulis, klien menerima Token Sesi yang diperbarui dari server. Klien menyimpan token dan mengirimkannya ke server untuk operasi baca di wilayah tertentu. Jika replika tempat operasi baca dikeluarkan berisi data untuk token yang ditentukan (atau token yang lebih baru), data yang diminta dikembalikan. Jika replika tidak berisi data untuk sesi tersebut, klien mencoba kembali permintaan terhadap replika lain di wilayah tersebut. Jika perlu, klien mencoba kembali baca terhadap wilayah tambahan yang tersedia hingga data untuk token sesi yang ditentukan diambil.
Penting
Dalam Konsistensi Sesi, penggunaan token sesi klien menjamin bahwa data yang sesuai dengan sesi yang lebih lama tidak akan pernah dibaca. Namun, jika klien menggunakan token sesi yang lebih lama dan pembaruan yang lebih baru telah dibuat ke database, versi data yang lebih baru akan dikembalikan meskipun token sesi yang lebih lama digunakan. Token Sesi digunakan sebagai hambatan versi minimum tetapi bukan sebagai versi data tertentu (mungkin historis) yang akan diambil dari database.
Token Sesi di Azure Cosmos DB terikat partisi, yang berarti secara eksklusif dikaitkan dengan satu partisi. Untuk memastikan Anda dapat membaca tulisan Anda, gunakan token sesi yang terakhir dibuat untuk item yang relevan.
Jika klien tidak memulai penulisan ke partisi fisik, klien tidak berisi token sesi dalam cache-nya dan membaca partisi fisik tersebut berulah seperti dibaca dengan Konsistensi Akhir. Demikian pula, jika klien dibuat ulang, cache token sesinya juga dibuat ulang. Di sini juga, operasi baca mengikuti perilaku yang sama dengan Konsistensi Akhir hingga operasi tulis berikutnya membangun kembali cache token sesi klien.
Penting
Jika Token Sesi diteruskan dari satu instans klien ke instans klien lainnya, konten token tidak boleh dimodifikasi.
Konsistensi sesi adalah tingkat konsistensi yang paling banyak digunakan untuk satu wilayah dan aplikasi yang didistribusikan secara global. Ini menyediakan latensi tulis, ketersediaan, dan throughput baca yang sebanding dengan konsistensi akhir. Konsistensi sesi juga memberikan jaminan konsistensi yang sesuai dengan kebutuhan aplikasi yang ditulis untuk beroperasi dalam konteks pengguna. Grafik berikut menggambarkan konsistensi sesi dengan not musik. "Penulis AS Barat 2" dan "pembaca US Timur 2" menggunakan sesi yang sama (Sesi A) sehingga keduanya membaca data yang sama secara bersamaan. Sedangkan wilayah "Australia Timur" menggunakan "Sesi B" sehingga, ia menerima data nanti tetapi dalam urutan yang sama dengan tulisan.
Konsistensi awalan konsisten
Seperti semua tingkat konsistensi yang lebih lemah daripada Kuat, penulisan direplikasi ke minimal tiga replika (dalam set empat replika) di wilayah lokal, dengan replikasi asinkron ke semua wilayah lain.
Dalam awalan yang konsisten, pembaruan yang dibuat sebagai penulisan dokumen tunggal melihat konsistensi akhir.
Pembaruan yang dibuat sebagai batch dalam transaksi, dikembalikan konsisten ke transaksi tempat mereka dilakukan. Operasi tulis dalam transaksi beberapa dokumen selalu terlihat bersama- sama.
Asumsikan dua operasi tulis dilakukan secara transaksional (semua atau tidak ada operasi) pada dokumen Doc1 diikuti oleh dokumen Doc2, dalam transaksi T1 dan T2. Ketika klien melakukan baca di replika apa pun, pengguna melihat "Doc1 v1 dan Doc2 v1" atau "Doc1 v2 dan Doc2 v2" atau tidak ada dokumen jika replika tertinggal, tetapi tidak pernah "Doc1 v1 dan Doc2 v2" atau "Doc1 v2 dan Doc2 v1" untuk operasi baca atau kueri yang sama.
Grafik berikut menggambarkan konsistensi konsisten awalansi dengan not musik. Di semua wilayah, bacaan tidak pernah melihat penulisan yang tidak berurutan untuk batch transaksi yang ditulis:
Konsistensi akhir
Seperti semua tingkat konsistensi yang lebih lemah daripada Kuat, penulisan direplikasi ke minimal tiga replika (dalam empat set replika) di wilayah lokal, dengan replikasi asinkron ke semua wilayah lain.
Dalam Konsistensi akhir, klien mengeluarkan permintaan baca terhadap salah satu dari empat replika di wilayah yang ditentukan. Replika ini mungkin tertinggal dan dapat mengembalikan data kedaluarsa atau tidak.
Konsistensi akhir adalah bentuk konsistensi terlemah karena klien dapat membaca nilai yang lebih lama dari yang dibacanya di masa lalu. Konsistensi akhir sangat ideal ketika aplikasi tidak memerlukan jaminan pemesanan apa pun. Contohnya termasuk jumlah Retweet, Suka, atau komentar non-utas. Grafik berikut menggambarkan konsistensi peristiwa dengan not musik.
Jaminan konsistensi dalam praktik
Dalam praktiknya, Anda mungkin sering mendapatkan jaminan konsistensi yang lebih kuat. Jaminan konsistensi untuk operasi baca sesuai dengan kesegaran dan pemesanan status database yang Anda minta. Konsistensi baca terkait dengan pemesanan dan perambatan operasi tulis/pembaruan.
Jika tidak ada operasi tulis pada database, operasi baca dengan tingkat konsistensi peristiwa, sesi, atau konsisten awalan cenderung menghasilkan hasil yang sama seperti operasi baca dengan tingkat konsistensi yang kuat.
Jika akun Anda dikonfigurasi dengan tingkat konsistensi selain konsistensi yang kuat, Anda dapat mengetahui probabilitas bahwa klien Anda mungkin mendapatkan bacaan yang kuat dan konsisten untuk beban kerja Anda. Anda dapat mengetahui probabilitas ini dengan melihat metrik Probabilistically Bounded Staleness (PBS). Metrik ini terdapat di portal Microsoft Azure, untuk mempelajari selengkapnya, lihat Metrik Monitor Probabilistically Bounded Staleness (PBS).
Probabilistically Bounded Staleness menunjukkan bagaimana akhir dari konsistensi akhir Anda. Metrik ini memberikan wawasan tentang seberapa sering Anda bisa mendapatkan konsistensi yang lebih kuat daripada tingkat konsistensi yang saat ini telah Anda konfigurasi di akun Azure Cosmos DB Anda. Dengan kata lain, Anda dapat melihat probabilitas (diukur dalam milidetik) untuk mendapatkan bacaan yang konsisten untuk kombinasi wilayah tulis dan baca.
Tingkat konsistensi dan latensi
Latensi baca untuk semua tingkat konsistensi selalu dijamin kurang dari 10 milidetik pada persentil ke-99. Latensi baca rata-rata, pada persentil ke-50, biasanya 4 milidetik atau kurang.
Latensi tulis untuk semua tingkat konsistensi selalu dijamin kurang dari 10 milidetik pada persentil ke-99. Latensi tulis rata-rata, pada persentil ke-50, biasanya 5 milidetik atau kurang. Akun Azure Cosmos DB yang mencakup beberapa wilayah dan dikonfigurasi dengan konsistensi yang kuat adalah pengecualian untuk jaminan ini.
Tulis latensi dan Konsistensi yang kuat
Untuk akun Azure Cosmos DB yang dikonfigurasi dengan konsistensi yang kuat dengan lebih dari satu wilayah, latensi tulis sama dengan dua kali waktu pulang pergi (RTT) antara salah satu dari dua wilayah terjauh, ditambah 10 milidetik pada persentil ke-99. RTT jaringan tinggi antara wilayah akan diterjemahkan ke latensi yang lebih tinggi untuk permintaan Azure Cosmos DB karena konsistensi yang kuat menyelesaikan operasi hanya setelah memastikan bahwa itu telah diterapkan ke semua wilayah dalam akun.
Latensi RTT yang tepat adalah fungsi dari jarak kecepatan cahaya dan topologi jaringan Azure. Jaringan Azure tidak menyediakan SLA latensi apa pun untuk RTT di antara dua wilayah Azure, namun itu menerbitkan statistik latensi perjalanan pulang-pergi jaringan Azure. Untuk akun Azure Cosmos DB Anda, latensi replikasi ditampilkan di portal Azure. Anda dapat menggunakan portal Azure dengan masuk ke bagian Metrik lalu memilih opsi Konsistensi. Dengan menggunakan portal Azure, Anda dapat memantau latensi replikasi antara berbagai wilayah yang terkait dengan akun Azure Cosmos DB Anda.
Penting
Konsistensi yang kuat untuk akun dengan wilayah yang membentang lebih dari 5000 mil (8000 kilometer) diblokir secara default karena latensi tulis yang tinggi. Untuk memfungsikan kapabilitas ini, silakan hubungi dukungan.
Tingkat konsistensi dan throughput
Untuk kedaluwarsa yang kuat dan terikat, bacaan dilakukan terhadap dua replika dalam empat set replika (kuorum minoritas) untuk memberikan jaminan konsistensi. Sesi, konsisten awalan dan peristiwa melakukan bacaan replika tunggal. Hasilnya adalah bahwa, untuk jumlah unit permintaan yang sama, baca throughput untuk basi yang kuat dan terikat adalah setengah dari tingkat konsistensi lainnya.
Untuk jenis operasi tulis tertentu, seperti menyisipkan, mengganti, meningkatkan, dan menghapus, throughput tulis untuk unit permintaan identik untuk semua tingkat konsistensi. Untuk konsistensi yang kuat, perubahan perlu dilakukan di setiap wilayah (mayoritas global) sementara untuk semua tingkat konsistensi lainnya, mayoritas lokal (tiga replika dalam empat set replika) sedang digunakan.
| Tingkat konsistensi | Bacaan Kuorum | Penulisan Kuorum |
|---|---|---|
| Kuat | Minoritas Lokal | Mayoritas Global |
| Bounded Staleness | Minoritas Lokal | Mayoritas Lokal |
| Sesi | Replika Tunggal (menggunakan token sesi) | Mayoritas Lokal |
| Awalan Konsisten | Replika Tunggal | Mayoritas Lokal |
| Peristiwa | Replika Tunggal | Mayoritas Lokal |
Catatan
Biaya performa RU/s bacaan untuk pembacaan Minoritas Lokal adalah dua kali lipat dari tingkat konsistensi yang lebih lemah karena bacaan dibuat dari dua replika untuk memberikan jaminan konsistensi untuk Strong dan Bounded Staleness.
Catatan
Biaya performa RU/s baca untuk tingkat konsistensi keusangan yang kuat dan terikat mengonsumsi sekitar dua kali lebih banyak RU saat melakukan operasi baca jika dibandingkan dengan tingkat konsistensi santai lainnya.
Tingkat konsistensi dan durabilitas data
Dalam lingkungan database yang didistribusikan secara global ada hubungan langsung antara tingkat konsistensi dan ketahanan data di hadapan pemadaman di seluruh wilayah. Saat mengembangkan rencana keberlanjutan bisnis, Anda perlu memahami periode maksimum pembaruan data terbaru yang kehilangannya dapat ditoleransi aplikasi saat pulih setelah peristiwa yang mengganggu. Periode waktu pembaruan yang mungkin Anda gunakan dikenal sebagai objektif titik pemulihan (RPO).
Tabel ini menentukan hubungan antara model konsistensi dan durabilitas data di hadapan pemadaman luas wilayah.
| Wilayah | Mode replikasi | Tingkat konsistensi | RPO |
|---|---|---|---|
| 1 | Wilayah tulis tunggal atau Beberapa | Tingkat Konsistensi Apa pun | < 240 Menit |
| >1 | Wilayah tulis tunggal | Sesi, Awalan yang Konsisten, Peristiwa | < 15 menit |
| >1 | Wilayah tulis tunggal | Bounded Staleness | K & T |
| >1 | Wilayah tulis tunggal | Kuat | 0 |
| >1 | Beberapa wilayah tulis | Sesi, Awalan yang Konsisten, Peristiwa | < 15 menit |
| >1 | Beberapa wilayah tulis | Bounded Staleness | K & T |
K = Jumlah versi "K" (yaitu, pembaruan) item.
T = Interval waktu "T" sejak pembaruan terakhir.
Untuk satu akun wilayah, nilai minimum K dan T adalah 10 operasi tulis atau 5 detik. Untuk akun beberapa wilayah nilai minimum K dan T adalah 100.000 operasi tulis atau 300 detik. Nilai ini menentukan RPO minimum untuk data saat menggunakan Bounded Staleness.
Konsistensi yang kuat dan beberapa wilayah tulis
Akun Azure Cosmos DB yang dikonfigurasi dengan beberapa wilayah tulis tidak dapat dikonfigurasi untuk konsistensi yang kuat karena tidak dimungkinkan bagi sistem terdistribusi untuk menyediakan RPO nol dan RTO nol. Selain itu, tidak ada manfaat latensi tulis untuk menggunakan konsistensi yang kuat dengan beberapa wilayah tulis karena tulisan ke wilayah mana pun harus direplikasi dan diterapkan untuk semua wilayah yang dikonfigurasi dalam akun. Skenario ini menghasilkan latensi tulis yang sama dengan satu akun wilayah tulis.
Bacaan lainnya
Untuk mempelajari selengkapnya tentang konsep konsistensi, baca artikel berikut ini:
- Spesifikasi TLA+ tingkat tinggi untuk lima tingkat konsistensi yang ditawarkan oleh Azure Cosmos DB
- Konsistensi Data yang Direplikasi Dijelaskan Melalui Bisbol (video) oleh Doug Terry
- Konsistensi Data yang Direplikasi Dijelaskan Melalui Bisbol (dokumen teknis) oleh Doug Terry
- Jaminan sesi untuk data replikasi yang konsisten lemah
- Konsistensi Tradeoff dalam Desain Sistem Database Terdistribusi Modern: CAP Hanya Bagian dari Cerita
- Probabilistic Bounded Staleness (PBS) untuk Kuorum Parsial Praktis
- Akhirnya Konsisten - Direvisi
Langkah berikutnya
Untuk mempelajari selengkapnya tentang tingkat konsistensi di Azure Cosmos DB, baca artikel berikut ini: