Tingkat Konsistensi di Azure Cosmos DB

BERLAKU UNTUK: SQL API Cassandra API Gremlin API Table API Azure Cosmos DB API for MongoDB

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 ketersediaan yang berkurang (selama kegagalan) karena data tidak dapat mereplikasi dan menerapkan di setiap wilayah. Konsistensi akhir menawarkan ketersediaan yang lebih tinggi dan performa yang lebih baik, tapi lebih sulit untuk memprogram aplikasi karena data mungkin tidak benar-benar konsisten di seluruh kawasan.

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.

Consistency as a spectrum

Tingkat konsistensi adalah agnostik wilayah dan dijamin untuk semua operasi terlepas dari wilayah tempat baca dan tulis dilayani, jumlah wilayah yang terkait dengan akun Azure Cosmos Anda, atau apakah akun Anda dikonfigurasi dengan satu atau beberapa wilayah tulis.

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 penyimpanan MongoDB, Apache Cassandra, Gremlin, dan Azure Table. Saat menggunakan Gremlin API dan Table API, tingkat konsistensi default yang dikonfigurasi pada akun Azure Cosmos digunakan. Untuk detail tentang pemetaan tingkat konsistensi antara Cassandra API atau API untuk tingkat konsistensi MongoDB dan Azure Cosmos DB lihat, pemetaan konsistensi API Cassandra dan API untuk pemetaan konsistensi MongoDB.

Cakupan konsistensi baca

Konsistensi baca berlaku untuk satu operasi baca yang tercakup dalam partisi logika. Operasi baca dapat dikeluarkan oleh klien jarak jauh atau prosedur yang disimpan.

Mengonfigurasi tingkat konsistensi default

Anda dapat mengonfigurasi tingkat konsistensi default di akun Azure Cosmos kapan saja. Tingkat konsistensi default yang dikonfigurasi di akun Anda berlaku untuk semua database dan kontainer Azure Cosmos di bawah akun tersebut. Semua baca dan kueri yang dikeluarkan terhadap kontainer atau database menggunakan tingkat konsistensi yang ditentukan secara default. 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 yang 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:

Illustration of strong consistency level

Konsistensi kedaluwarsa terikat

Dalam konsistensi kedaluwarsa terikat, bacaan dijamin untuk menghormati jaminan awalan yang konsisten. Bacaan mungkin tertinggal menulis oleh paling banyak versi "K" (yaitu, "pembaruan") dari item atau dengan interval waktu "T" , mana yang dicapai terlebih dahulu. Dengan kata lain, ketika Anda memilih kedaluwarsa terikat, "kedaluwarsa" dapat dikonfigurasi dengan dua cara:

  • Jumlah versi (K) item
  • Interval waktu (T) berbunyi mungkin tertinggal dari tulisan

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.

Kedaluwarsa terikat menawarkan urutan global total di luar "interval kedaluwarsa". Ketika klien melakukan operasi baca dalam wilayah yang menerima tulis, jaminan yang diberikan konsistensi kedaluwarsa terikat identik dengan jaminan dari konsistensi kuat. Ketika jendela kedaluwarsa mendekati untuk waktu atau pembaruan, mana yang lebih dekat, layanan akan mencekik tulisan baru untuk memungkinkan replikasi untuk mengejar ketinggalan dan menghormati jaminan konsistensi.

Di dalam jendela kedaluwarsa, Bounded Staleness memberikan jaminan konsistensi berikut:

  • Konsistensi untuk klien di wilayah yang sama untuk akun dengan wilayah tulis tunggal = Kuat

  • Konsistensi untuk klien di berbagai wilayah untuk akun dengan wilayah tulis tunggal = Awalan Konsisten

  • Konsistensi untuk klien yang menulis ke satu wilayah untuk akun dengan beberapa wilayah tulis = Awalan Konsisten

  • Konsistensi untuk klien yang menulis ke wilayah yang berbeda untuk akun dengan beberapa wilayah tulis = Peristiwa

    Kedaluwarsa terikat sering dipilih oleh aplikasi terdistribusi secara global yang mengharapkan latensi tulis rendah, tetapi memerlukan jaminan pesanan global secara total. Kekakuan terikat sangat bagus untuk aplikasi yang menampilkan kolaborasi dan berbagi grup, saham ticker, terbit-langganan/antrian dll. Grafik berikut menggambarkan konsistensi kedaluwarsa yang dibatasi 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:

    Illustration of bounded staleness consistency level

Konsistensi sesi

Dalam konsistensi sesi, dalam satu sesi klien, dijamin untuk menghormati awalan yang konsisten, bacaan monotonik, penulisan monotonik, read-your-writes, dan jaminan write-follows-reads. Ini mengasumsikan sesi "penulis" tunggal atau berbagi token sesi untuk beberapa penulis.

Klien di luar sesi yang melakukan penulisan akan melihat jaminan berikut:

  • Konsistensi untuk klien di wilayah yang sama untuk akun dengan wilayah tulis tunggal = Awalan Konsisten

  • Konsistensi untuk klien di berbagai wilayah untuk akun dengan wilayah tulis tunggal = Awalan Konsisten

  • Konsistensi untuk klien yang menulis ke satu wilayah untuk akun dengan beberapa wilayah tulis = Awalan Konsisten

  • Konsistensi untuk klien yang menulis ke berbagai wilayah untuk akun dengan beberapa wilayah tulis = Peristiwa

  • Konsistensi untuk klien menggunakan cache terintegrasi Azure Cosmos DB = Peristiwa

    Konsistensi sesi adalah tingkat konsistensi yang paling banyak digunakan untuk wilayah tunggal maupun aplikasi yang didistribusikan secara global. Ini memberikan latensi tulis, ketersediaan, dan throughput baca sebanding dengan konsistensi peristiwa tetapi 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 AS Barat 2" menggunakan sesi yang sama (Sesi A) sehingga mereka berdua membaca data yang sama pada saat yang sama. Sedangkan wilayah "Australia Timur" menggunakan "Sesi B" sehingga, ia menerima data nanti tetapi dalam urutan yang sama dengan tulisan.

    Illustration of session consistency level

Konsistensi awalan yang konsisten

Dalam opsi konsisten awalan, pembaruan yang dikembalikan berisi beberapa awalan dari semua pembaruan, tanpa celah. Tingkat konsistensi konsisten awalan menjamin bahwa bacaan tidak akan pernah melihat penulisan yang tidak berurutan.

Jika penulisan dilakukan di susunan A, B, C, maka klien melihat A, A,B, atau A,B,C, tetapi tidak pernah permutasi acak seperti A,C atau B,A,C. Konsisten awalan memberikan latensi tulis, ketersediaan, dan throughput baca sebanding dengan konsistensi peristiwa, tetapi juga memberikan jaminan pesanan yang sesuai dengan kebutuhan skenario di mana pesanan penting.

Di bawah ini adalah jaminan konsistensi untuk Awalan Konsisten:

  • Konsistensi untuk klien di wilayah yang sama untuk akun dengan wilayah tulis tunggal = Awalan Konsisten
  • Konsistensi untuk klien di berbagai wilayah untuk akun dengan wilayah tulis tunggal = Awalan Konsisten
  • Konsistensi untuk klien yang menulis ke satu wilayah untuk akun dengan beberapa wilayah tulis = Awalan Konsisten
  • Konsistensi untuk klien yang menulis ke berbagai wilayah untuk akun dengan beberapa wilayah tulis = Peristiwa

Grafik berikut menggambarkan konsistensi konsisten awalansi dengan not musik. Di semua wilayah, bacaan tidak pernah terlihat rusak menulis:

Illustration of consistent prefix

Konsistensi peristiwa

Pada konsistensi peristiwa, tidak ada jaminan pemesanan untuk bacaan. Dengan tidak adanya tulisan lebih lanjut, replika peristiwa bertemu.

Konsistensi akhirnya adalah bentuk konsistensi terlemah karena klien dapat membaca nilai-nilai yang lebih tua dari yang telah dibaca sebelumnya. Konsistensi akhirnya sangat ideal di mana aplikasi tidak memerlukan jaminan pemesanan. Contohnya termasuk jumlah Retweet, Suka, atau komentar non-utas. Grafik berikut menggambarkan konsistensi peristiwa dengan not musik.

viIllustration of eventual consistency

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 Azure Cosmos Anda dikonfigurasikan dengan tingkat konsistensi selain konsistensi yang kuat, Anda dapat mengetahui probabilitas kalau klien Anda mungkin mendapatkan pembacaan yang kuat dan konsisten untuk beban kerja Anda dengan melihat metrik Probabilistically Bounded Staleness (PBS). Metrik ini terdapat di portal Microsoft Azure, untuk mempelajari selengkapnya, lihat Metrik Monitor Probabilistically Bounded Staleness (PBS).

Ketidakstabilan yang dibatasi probabilistik menunjukkan seberapa peristiwa konsistensi peristiwa Anda. Metrik ini memberikan wawasan tentang seberapa sering Anda bisa mendapatkan konsistensi yang lebih kuat dibandingkan tingkat konsistensi yang saat ini telah Anda konfigurasi di akun Azure Cosmos Anda. Dengan kata lain, Anda dapat melihat probabilitas (diukur dalam milidetik) mendapatkan pembacaan yang sangat 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 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 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 Cosmos DB karena konsistensi yang kuat menyelesaikan operasi hanya setelah memastikan bahwa itu telah diterapkan untuk 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 Anda, latensi replikasi ditampilkan di portal Microsoft Azure. Anda dapat menggunakan portal Microsoft Azure (buka bilah Metrik, pilih tab Konsistensi) untuk memantau latensi replikasi antara berbagai wilayah yang terkait dengan akun Azure Cosmos 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
Ses Replika Tunggal (menggunakan token sesi) Mayoritas Lokal
Awalan Konsisten Replika Tunggal Mayoritas Lokal
Peristiwa Replika Tunggal Mayoritas Lokal

Catatan

Biaya baca RU/s untuk bacaan Minoritas Lokal dua kali lipat dari tingkat konsistensi yang lebih lemah karena bacaan terbuat dari dua replika untuk memberikan jaminan konsistensi untuk Bounded Staleness dan Strong.

Tingkat konsistensi dan ketahanan 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 di bawah ini menjelaskan hubungan antara model konsistensi dan ketahanan 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" (misalnya, 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. Ini menentukan RPO minimum untuk data saat menggunakan Bounded Staleness.

Konsistensi yang kuat dan beberapa wilayah tulis

Akun Cosmos yang dikonfigurasi dengan beberapa wilayah tulis tidak dapat dikonfigurasi untuk konsistensi yang kuat karena tidak mungkin 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. Ini menghasilkan latensi tulis yang sama dengan akun wilayah tulis tunggal.

Bacaan tambahan

Untuk mempelajari selengkapnya tentang konsep konsistensi, baca artikel berikut ini:

Langkah berikutnya

Untuk mempelajari selengkapnya tentang tingkat konsistensi di Azure Cosmos DB, baca artikel berikut ini: