Tingkat Konsistensi di Azure Cosmos DB

Database terdistribusi yang mengandalkan replikasi untuk ketersediaan tinggi, latensi rendah, atau keduanya harus menyeimbangkan konsistensi baca, ketersediaan, latensi, dan throughput seperti yang didefinisikan oleh teori PACELC. Linearizability dari model konsistensi yang kuat adalah standar untuk kemampuan pemrograman data. Namun, ini meningkatkan latensi tulis karena data harus mereplikasi dan berkomitmen di jarak yang besar. Konsistensi yang kuat juga mengurangi ketersediaan selama kegagalan karena data tidak dapat mereplikasi dan berkomitmen di setiap wilayah. Konsistensi akhirnya 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 di pasar saat ini hanya memberikan konsistensi yang kuat dan akhirnya. Azure Cosmos DB menawarkan lima level yang terdefinisi dengan baik. Dari yang terkuat hingga terlemah, levelnya adalah:

• Kuat
• Kedaluwarsa terikat
• Sesi
• Awalan Konsisten
• Peristiwa

Untuk informasi selengkapnya tentang tingkat konsistensi default, lihat mengonfigurasi tingkat konsistensi default atau mengambil alih tingkat konsistensi default.

Setiap tingkat menyeimbangkan ketersediaan dan performa. Gambar berikut menunjukkan tingkat konsistensi sebagai spektrum.

Tingkat konsistensi dan API Azure Cosmos DB

Azure Cosmos DB mendukung API yang kompatibel dengan protokol kawat untuk database populer, termasuk MongoDB, Apache Cassandra, Apache Gremlin, dan Azure Table Storage. Untuk API untuk Gremlin atau Table, Azure Cosmos DB menggunakan tingkat konsistensi default yang dikonfigurasi pada akun. Untuk mempelajari tentang pemetaan tingkat konsistensi, lihat API untuk pemetaan konsistensi Cassandra untuk Apache Cassandra dan API untuk pemetaan konsistensi MongoDB untuk MongoDB.

Cakupan konsistensi baca

Konsistensi baca berlaku untuk satu operasi baca dalam partisi logis. Klien jarak jauh, prosedur tersimpan, atau pemicu dapat mengeluarkan operasi baca.

Mengonfigurasi tingkat konsistensi default

Konfigurasikan 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, sebarkan ulang aplikasi Anda dan buat modifikasi kode yang diperlukan untuk menerapkan perubahan ini. Pelajari selengkapnya tentang cara mengonfigurasi tingkat konsistensi default. Anda juga dapat mengambil alih tingkat konsistensi default untuk permintaan tertentu. Pelajari selengkapnya di artikel mengambil alih tingkat konsistensi default .

Tip

Mengesampingkan tingkat konsistensi default hanya berlaku untuk bacaan dalam klien SDK. Akun yang dikonfigurasi untuk konsistensi yang kuat secara default masih menulis dan mereplikasi data secara sinkron ke setiap wilayah di akun. Ketika instans klien SDK atau permintaan mengambil alih konsistensi ini dengan konsistensi sesi atau lebih lemah, pembacaan dilakukan menggunakan satu replika. Untuk informasi selengkapnya, lihat tingkat konsistensi dan throughput.

Penting

Buat ulang instans SDK apa pun setelah mengubah tingkat konsistensi default dengan memulai ulang aplikasi. Langkah ini memastikan SDK menggunakan tingkat konsistensi default baru.

Jaminan yang terkait dengan tingkat konsistensi

Azure Cosmos DB menjamin bahwa 100% permintaan baca memenuhi jaminan konsistensi untuk tingkat konsistensi yang dipilih. Definisi yang tepat dari lima tingkat konsistensi di Azure Cosmos DB menggunakan TLA - Logika Tindakan Temporal - bahasa spesifikasi disediakan dalam repositori GitHub azure/azure-cosmos-tla .

Semantik dari lima tingkat konsistensi dijelaskan di bagian berikut.

Konsistensi kuat

Konsistensi yang kuat menawarkan jaminan linearizability. Linearizability berarti melayani permintaan 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 menunjukkan konsistensi yang kuat dengan catatan musik. Setelah data ditulis ke wilayah "WEST US 2", ketika Anda membaca data dari wilayah lain, Anda mendapatkan nilai terbaru:

Kuorum dinamis

Dalam keadaan normal, untuk akun dengan konsistensi yang kuat, penulisan dianggap dilakukan ketika semua wilayah mengakui replikasi rekaman. Jika akun Anda memiliki tiga wilayah atau lebih, sistem dapat menurunkan jumlah wilayah yang diperlukan untuk kuorum saat beberapa wilayah lambat atau tidak merespons. Ini membantu menjaga konsistensi yang kuat meskipun beberapa wilayah memiliki masalah. Pada saat itu, wilayah yang tidak responsif diambil dari kumpulan kuorum wilayah untuk mempertahankan konsistensi yang kuat. Mereka hanya ditambahkan kembali ketika mereka menjadi konsisten dengan wilayah lain dan berkinerja seperti yang diharapkan. Jumlah wilayah yang berpotensi diambil dari kumpulan kuorum tergantung pada jumlah total wilayah. Misalnya, dalam akun tiga atau empat wilayah, mayoritas masing-masing adalah dua atau tiga wilayah, sehingga hanya satu wilayah yang dapat dihapus dalam kedua kasus. Untuk lima akun wilayah, mayoritas adalah tiga, sehingga hingga dua wilayah yang tidak responsif dapat dihapus. Kemampuan ini dikenal sebagai "kuorum dinamis" dan dapat meningkatkan ketersediaan tulis dan latensi replikasi untuk akun dengan tiga wilayah atau lebih.

Catatan

Ketika wilayah dihapus dari kumpulan kuorum sebagai bagian dari kuorum dinamis, wilayah tersebut tidak lagi dapat melayani bacaan sampai dibaca ke dalam kuorum.

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, kadang-kadang 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 terutama bermanfaat bagi 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 set empat replika) terlepas dari tingkat konsistensinya.

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 Keusangan Terikat, bacaan dari wilayah nonprimary mungkin tidak menampilkan data terbaru dari semua wilayah. Namun, mereka selalu mengembalikan data terbaru yang tersedia di wilayah tersebut, dalam batas keusangan yang diizinkan.

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, klien menggunakan token sesi untuk menjamin bahwa ia tidak pernah membaca data yang sesuai dengan sesi yang lebih lama. Jika klien menggunakan token sesi lama, tetapi data yang lebih baru tersedia dalam database, sistem mengembalikan versi terbaru. Bahkan dengan token yang sudah ketinggalan jaman, Anda selalu mendapatkan data terbaru. 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 aplikasi satu wilayah dan terdistribusi 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 bisa tertinggal dan dapat mengembalikan kedaluarsa atau tidak ada data.

Konsistensi akhir adalah bentuk konsistensi terlemah karena klien mungkin membaca nilai yang lebih lama dari nilai yang dibacanya di masa lalu. Konsistensi akhir sangat ideal ketika aplikasi tidak memerlukan jaminan pemesanan apa pun. Contohnya termasuk jumlah Retweet, Suka, atau komentar yang tidak dibaca. 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 pengurutan dan penyebaran operasi tulis dan perbarui.

Jika tidak ada operasi tulis pada database, operasi baca dengan tingkat konsistensi akhir, sesi, atau awalan yang konsisten mungkin menghasilkan hasil yang sama dengan 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. Cari tahu probabilitas ini dengan melihat metrik Probabilistically Bounded Staleness (PBS ). Metrik ini diekspos di portal Microsoft Azure. Untuk informasi selengkapnya, lihat Metrik Monitor Probabilistically Bounded Staleness (PBS).

Keusangan yang terikat secara probabilistik menunjukkan bagaimana akhirnya konsistensi Anda akhirnya. Metrik ini memberikan wawasan tentang seberapa sering Anda mendapatkan konsistensi yang lebih kuat daripada tingkat konsistensi yang saat ini dikonfigurasi pada 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 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 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 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 antar wilayah meningkatkan latensi permintaan Azure Cosmos DB karena konsistensi yang kuat menyelesaikan operasi hanya setelah memastikan operasi dilakukan untuk semua wilayah di akun.

Latensi RTT yang tepat tergantung pada jarak kecepatan cahaya dan topologi jaringan Azure. Jaringan Azure tidak menyediakan perjanjian tingkat layanan latensi (SLA) untuk RTT antar wilayah Azure, tetapi menerbitkan statistik latensi pulang pergi jaringan Azure. Untuk akun Azure Cosmos DB Anda, latensi replikasi ditampilkan di portal Azure. Gunakan portal Microsoft Azure dengan masuk ke bagian Metrik dan pilih 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 mencakup lebih dari 5.000 mil (8.000 kilometer) diblokir secara default karena latensi tulis yang tinggi. Untuk mengaktifkan kemampuan ini, hubungi dukungan.

Tingkat konsistensi dan throughput

• Untuk keusangan yang kuat dan terikat, bacaan dilakukan terhadap dua replika dalam set empat replika (kuorum minoritas) untuk memastikan jaminan konsistensi. Sesi, awalan yang konsisten, dan konsistensi akhirnya menggunakan bacaan replika tunggal. Akibatnya, untuk jumlah unit permintaan yang sama, throughput baca untuk keusangan yang kuat dan terikat adalah setengah dari tingkat konsistensi lainnya.

• Untuk jenis operasi tulis tertentu, seperti sisipkan, ganti, upsert, atau hapus, throughput tulis untuk unit permintaan identik di semua tingkat konsistensi. Untuk konsistensi yang kuat, perubahan harus dilakukan di setiap wilayah (mayoritas global), sementara untuk semua tingkat konsistensi lainnya, mayoritas lokal (tiga replika dalam set empat replika) digunakan.

Tingkat konsistensi	Bacaan Kuorum	Penulisan Kuorum
Kuat	Minoritas Lokal	Mayoritas Global
Keusangan Terikat	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 RU baca untuk pembacaan minoritas lokal adalah dua kali lipat dari tingkat konsistensi yang lebih lemah karena bacaan dibuat dari dua replika untuk memastikan jaminan konsistensi untuk tingkat konsistensi keusangan yang kuat dan terikat.

Tingkat konsistensi dan durabilitas data

Dalam lingkungan database yang didistribusikan secara global, tingkat konsistensi secara langsung memengaruhi durabilitas data selama pemadaman di seluruh wilayah. Saat mengembangkan rencana kelangsungan bisnis, pahami periode maksimum pembaruan data terbaru, aplikasi dapat mentolerir kehilangan selama pemulihan dari peristiwa yang mengganggu. Periode waktu pembaruan yang dapat hilang disebut sebagai tujuan titik pemulihan (RPO).

Tabel ini memperlihatkan hubungan antara model konsistensi dan durabilitas data selama pemadaman di seluruh 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	Keusangan Terikat	K & T
>1	Wilayah tulis tunggal	Kuat	0
>1	Beberapa wilayah tulis	Sesi, Awalan yang Konsisten, Peristiwa	< 15 menit
>1	Beberapa wilayah tulis	Keusangan Terikat	K & T

K = Jumlah versi K (pembaruan) item.

T = Interval waktu T sejak pembaruan terakhir.

Untuk akun wilayah tunggal, nilai minimum K dan T adalah 10 operasi tulis atau 5 detik. Untuk akun multi-wilayah, nilai minimum K dan T adalah 100.000 operasi tulis atau 300 detik. Nilai ini mendefinisikan tujuan titik pemulihan minimum (RPO) untuk data saat menggunakan Bounded Staleness.

Konsistensi yang kuat dan beberapa wilayah tulis

Akun Azure Cosmos DB dengan beberapa wilayah tulis tidak dapat menggunakan konsistensi yang kuat karena sistem terdistribusi tidak dapat memberikan tujuan titik pemulihan (RPO) nol dan tujuan waktu pemulihan (RTO) nol. Selain itu, konsistensi yang kuat dengan beberapa wilayah tulis tidak meningkatkan latensi tulis karena penulisan harus direplikasi dan berkomitmen untuk semua wilayah di akun. Penyiapan ini menghasilkan latensi tulis yang sama dengan akun wilayah tulis tunggal.

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 (whitepaper) oleh Doug Terry
• Jaminan sesi untuk data replikasi yang konsisten lemah
• Tradeoff konsistensi dalam desain sistem database terdistribusi modern: CAP hanyalah bagian dari cerita
• Keusangan terikat probabilistik (PBS) untuk kuorum parsial praktis
• Akhirnya konsisten - ditinjau kembali

Konten terkait

• Mengonfigurasi tingkat konsistensi default
• Mengganti tingkat konsistensi default
• Pelajari selengkapnya tentang Azure Cosmos DB SLA.