مستويات التناسق في قاعدة بيانات Azure Cosmos DB
ينطبق على: 
NoSQL MongoDB كاساندرا العفريت الجدول
يجب أن تقوم قواعد البيانات الموزعة التي تعتمد على النسخ المتماثل للحصول على إمكانية توفر عالية أو زمن وصول منخفض أو كليهما بإجراء مقايضة أساسية بين اتساق القراءة والتوافر وزمن الوصول والإنتاجية كما هو محدد بواسطة نظرية PACELC. إن إمكانية تحديد خط أساس نموذج الاتساق القوي هو المعيار الذهبي لقابلية برمجة البيانات. ولكنه يضيف سعراً باهظاً من أزمنة الكتابة المرتفعة بسبب اضطرار البيانات للتكرار والالتزام عبر مسافات كبيرة. قد يعاني التناسق القوي أيضا من انخفاض التوفر (أثناء حالات الفشل) لأن البيانات لا يمكن نسخها نسخا متماثلا والالتزام بها في كل منطقة. يوفر التناسق النهائي توفرا أعلى وأداء أفضل، ولكن من الصعب برمجة التطبيقات لأن البيانات قد لا تكون متسقة عبر جميع المناطق.
لا توفر معظم قواعد بيانات NoSQL الموزعة تجارياً والمتاحة في السوق اليوم سوى اتساق strong وeventual. يقدم Azure Cosmos DB خمسة مستويات محددة جيداً. من الأقوى إلى الأضعف، والمستويات هي:
لمزيد من المعلومات حول مستوى التناسق الافتراضي، راجع تكوين مستوى التناسق الافتراضي أو منع مستوى التناسق الافتراضي.
يوفر كل مستوى مفاضلات الأداء والتوفر. تظهر الصورة التالية مستويات التناسق المختلفة كطيف.
مستويات الاتساق و واجهات برمجة التطبيقات Azure Cosmos DB
يوفر Azure Cosmos DB الدعم الأصلي لواجهات برمجة التطبيقات المتوافقة مع بروتوكول سلكي لقواعد البيانات الشائعة. وتشمل هذه MongoDB وApache Cassandra وApache Gremlin وAzure Table Storage. في واجهة برمجة التطبيقات ل Gremlin أو Table، يتم استخدام مستوى التناسق الافتراضي الذي تم تكوينه على حساب Azure Cosmos DB. للحصول على تفاصيل حول تعيين مستوى التناسق بين Apache Cassandra وAzure Cosmos DB، راجع API لتعيين تناسق Cassandra. للحصول على تفاصيل حول تعيين مستوى التناسق بين MongoDB وAzure Cosmos DB، راجع API لتعيين تناسق MongoDB.
نطاق اتساق القراءة
ينطبق اتساق القراءة على عملية قراءة واحدة ضمن قسم منطقي. يمكن لعميل بعيد أو إجراء مخزن أو مشغل إصدار عملية القراءة.
تكوين مستوى الاتساق الافتراضي
يمكنك تكوين مستوى التناسق الافتراضي على حساب Azure Cosmos DB في أي وقت. ينطبق مستوى التناسق الافتراضي الذي تم تكوينه على حسابك على جميع قواعد بيانات وحاويات Azure Cosmos DB ضمن هذا الحساب. تستخدم جميع القراءات والاستعلامات الصادرة مقابل حاوية أو قاعدة بيانات مستوى الاتساق المحدد بشكل افتراضي. أثناء تغيير تناسق مستوى حسابك، تأكد من إعادة نشر التطبيقات وإجراء أي تعديلات ضرورية على التعليمات البرمجية لتطبيق هذه التغييرات. لمعرفة المزيد، راجع كيفية تكوين مستوى الاتساق الافتراضي. يمكنك أيضاً تجاوز مستوى الاتساق الافتراضي لطلب معين، لمعرفة المزيد، راجع كيفية تجاوز مقال مستوى الاتساق الافتراضي.
تلميح
تجاوز مستوى الاتساق الافتراضي ينطبق فقط على القراءات داخل عميل SDK. سيظل الحساب الذي تم تكوينه لتحقيق اتساق قوي بشكل افتراضي يكتب البيانات وينسخها بشكل متزامن مع كل منطقة في الحساب. عندما يتخطى مثيل أو طلب عميل SDK هذا مع جلسة عمل أو اتساق أضعف، سيتم إجراء عمليات القراءة باستخدام نسخة متماثلة واحدة. لمزيد من المعلومات، راجع مستويات الاتساق ومعدلات النقل.
هام
مطلوب إعادة إنشاء مثيل SDK بعد تغيير مستوى الاتساق الافتراضي. يمكن القيام بذلك عن طريق إعادة تشغيل التطبيق. يضمن ذلك استخدام SDK لمستوى الاتساق الافتراضي الجديد.
الضمانات المرتبطة بمستويات الاتساق
يضمن Azure Cosmos DB أن 100 بالمائة من طلبات القراءة تفي بضمان الاتساق لمستوى الاتساق الذي تم اختياره. يتم توفير التعريفات الدقيقة لمستويات الاتساق الخمسة في قاعدة بيانات Azure Cosmos باستخدام لغة مواصفات TLA+ في azure-cosmos-tla GitHub repo.
ترد في الأقسام التالية المصطلحات الدلالية لمستويات الاتساق الخمسة.
تناسق قوي
التناسق القوي يوفر ضمان القابلية الخطية. تشير إمكانية التحديد إلى طلبات الخدمة في نفس الوقت. تضمن عمليات القراءة إرجاع أحدث إصدار تم الالتزام به لأحد العناصر. لا يرى العميل أبداً كتابة غير ملتزمة أو جزئية. يضمن للمستخدمين دائماً قراءة آخر كتابة تم الالتزام بها.
يوضح الرسم التالي الاتساق القوي مع الملاحظات الموسيقية. بعد كتابة البيانات إلى منطقة "غرب الولايات المتحدة 2"، عندما تقرأ البيانات من مناطق أخرى، تحصل على أحدث قيمة:
تناسق غير محدد "Bounded staleness"
بالنسبة لحسابات الكتابة في منطقة واحدة مع منطقتين أو أكثر، يتم نسخ البيانات من المنطقة الأساسية إلى جميع المناطق الثانوية (للقراءة فقط). بالنسبة لحسابات الكتابة متعددة المناطق مع منطقتين أو أكثر، يتم نسخ البيانات من المنطقة التي تمت كتابتها فيها في الأصل إلى جميع المناطق الأخرى القابلة للكتابة. في كلا السيناريوهين، على الرغم من أنه غير شائع، قد يكون هناك أحيانا تأخر في النسخ المتماثل من منطقة إلى أخرى.
في تناسق الثبات المرتبط، يكون تأخر البيانات بين أي منطقتين دائما أقل من مقدار محدد. يمكن أن يكون المبلغ هو إصدارات "K" (أي "التحديثات") لعنصر أو بفواصل زمنية "T"، أيهما يتم الوصول إليه أولا. بمعنى آخر، عند اختيار bounded staleness، يمكن تكوين الحد الأقصى "staleness" للبيانات في أي منطقة بطريقتين:
- عدد إصدارات (K) من العنصر
- قد يتأخر الفاصل الزمني (T) الذي تمت قراءته عن عمليات الكتابة
Bounded Staleness مفيد في المقام الأول لحسابات الكتابة في منطقة واحدة مع منطقتين أو أكثر. إذا تجاوز تأخر البيانات في منطقة ما (يتم تحديده لكل قسم فعلي) قيمة الثبات المكونة، يتم تقييد عمليات الكتابة لهذا القسم حتى يعود الثبات داخل الحد الأعلى المكون.
بالنسبة لحساب منطقة واحدة، يوفر Bounded Staleness نفس ضمانات تناسق الكتابة مثل الجلسة والتناسق النهائي. مع Bounded Staleness، يتم نسخ البيانات إلى أغلبية محلية (ثلاث نسخ متماثلة في مجموعة أربع نسخ متماثلة) في المنطقة الواحدة.
هام
مع تناسق Bounded Staleness، يتم إجراء عمليات التحقق من الثبات عبر المناطق فقط وليس داخل المنطقة. داخل منطقة معينة، يتم دائما نسخ البيانات إلى أغلبية محلية (ثلاث نسخ متماثلة في مجموعة أربع نسخ متماثلة) بغض النظر عن مستوى التناسق.
تقوم القراءة عند استخدام Bounded Staleness بإرجاع أحدث البيانات المتوفرة في تلك المنطقة عن طريق القراءة من نسختين متماثلتين متوفرتين في تلك المنطقة. نظرا لأن عمليات الكتابة داخل منطقة ما تنسخ دائما إلى أغلبية محلية (ثلاث نسخ متماثلة من أصل أربع نسخ متماثلة)، فإن استشارة نسختين متماثلتين ترجع البيانات الأكثر تحديثا المتوفرة في تلك المنطقة.
هام
مع تناسق Bounded Staleness، قد لا ترجع القراءات الصادرة مقابل منطقة غير أساسية بالضرورة أحدث إصدار من البيانات عالميا، ولكنها مضمونة لإرجاع أحدث إصدار من البيانات في تلك المنطقة، والتي ستكون ضمن الحد الأقصى للثبات عالميا.
يعمل Bounded Staleness بشكل أفضل للتطبيقات الموزعة عالميا باستخدام حسابات كتابة منطقة واحدة مع منطقتين أو أكثر، حيث مطلوب تناسق قوي تقريبا عبر المناطق. بالنسبة لحسابات الكتابة متعددة المناطق مع منطقتين أو أكثر، يجب أن توجه خوادم التطبيقات القراءات والكتابة إلى نفس المنطقة التي تتم فيها استضافة خوادم التطبيق. Bounded Staleness في حساب متعدد الكتابة هو نمط مضاد. سيتطلب هذا المستوى تبعية على تأخر النسخ المتماثل بين المناطق، والذي لا ينبغي أن يكون مهما إذا تمت قراءة البيانات من نفس المنطقة التي تمت كتابتها إليها.
يوضح الرسم التالي تناسق الثبات المقيد مع الملاحظات الموسيقية. بعد كتابة البيانات إلى منطقة "غرب الولايات المتحدة 2"، تقرأ منطقتا "شرق الولايات المتحدة 2" و"شرق أستراليا" القيمة المكتوبة استناداً إلى الحد الأقصى للمهلة المحددة أو الحد الأقصى للعمليات:
تناسق "Session"
في تناسق الجلسة، ضمن جلسة عمل عميل واحدة، يتم ضمان القراءات لتكريم عمليات القراءة والكتابة وضمانات القراءة التالية. يفترض هذا الضمان جلسة "كاتب" واحدة أو مشاركة الرمز المميز للجلسة للعديد من الكتاب.
مثل جميع مستويات التناسق الأضعف من Strong، يتم نسخ عمليات الكتابة إلى ثلاث نسخ متماثلة كحد أدنى (في مجموعة أربع نسخ متماثلة) في المنطقة المحلية، مع النسخ المتماثل غير المتزامن إلى جميع المناطق الأخرى.
بعد كل عملية كتابة، يتلقى العميل رمز جلسة محدث من الخادم. يقوم العميل بتخزين الرموز المميزة مؤقتا وإرسالها إلى الخادم لعمليات القراءة في منطقة محددة. إذا كانت النسخة المتماثلة التي تم إصدار عملية القراءة مقابلها تحتوي على بيانات للرمز المميز المحدد (أو رمز مميز أحدث)، يتم إرجاع البيانات المطلوبة. إذا لم تحتوي النسخة المتماثلة على بيانات لجلسة العمل هذه، يعيد العميل محاولة الطلب مقابل نسخة متماثلة أخرى في المنطقة. إذا لزم الأمر، يعيد العميل محاولة القراءة مقابل المناطق المتوفرة الإضافية حتى يتم استرداد البيانات الخاصة بالرمز المميز لجلسة العمل المحددة.
هام
في تناسق الجلسة، يضمن استخدام العميل للرمز المميز لجلسة العمل عدم قراءة البيانات المقابلة لجلسة عمل قديمة. ومع ذلك، إذا كان العميل يستخدم رمزا مميزا قديما للجلسة وتم إجراء تحديثات أحدث على قاعدة البيانات، فسيتم إرجاع الإصدار الأحدث من البيانات على الرغم من استخدام رمز جلسة عمل قديم. يتم استخدام الرمز المميز للجلسة كحد أدنى من حاجز الإصدار ولكن ليس كإصدار محدد (ربما تاريخي) من البيانات التي سيتم استردادها من قاعدة البيانات.
الرموز المميزة للجلسة في Azure Cosmos DB مرتبطة بالقسم، ما يعني أنها مرتبطة حصريا بقسم واحد. للتأكد من أنه يمكنك قراءة كتاباتك، استخدم الرمز المميز للجلسة الذي تم إنشاؤه آخر عنصر (عناصر) ذي صلة.
إذا لم يبدأ العميل الكتابة إلى قسم فعلي، لا يحتوي العميل على رمز جلسة في ذاكرة التخزين المؤقت الخاصة به ويقرأ إلى هذا القسم الفعلي يتصرف كما هو الحال مع القراءة مع التناسق النهائي. وبالمثل، إذا تم إعادة إنشاء العميل، يتم أيضا إعادة إنشاء ذاكرة التخزين المؤقت للرمز المميزة للجلسة. هنا أيضا، تتبع عمليات القراءة نفس سلوك التناسق النهائي حتى تقوم عمليات الكتابة اللاحقة بإعادة إنشاء ذاكرة التخزين المؤقت للعميل من الرموز المميزة للجلسة.
هام
إذا تم تمرير الرموز المميزة لجلسة العمل من مثيل عميل إلى آخر، يجب عدم تعديل محتويات الرمز المميز.
تناسق الجلسة هو مستوى التناسق الأكثر استخداما لكل من المنطقة الواحدة والتطبيقات الموزعة عالميا. يوفر زمن انتقال الكتابة والتوافر ومعدل نقل القراءة المشابهة لتلك الخاصة بالتناسق النهائي. يوفر تناسق الجلسة أيضا ضمانات التناسق التي تناسب احتياجات التطبيقات المكتوبة للعمل في سياق المستخدم. يوضح الرسم التالي اتساق الجلسة مع الملاحظات الموسيقية. يستخدم "كاتب غرب الولايات المتحدة 2" و"قارئ شرق الولايات المتحدة 2" نفس الجلسة (الجلسة أ) بحيث يقرأ كلاهما نفس البيانات في نفس الوقت. في حين أن منطقة "أستراليا الشرقية" تستخدم "الجلسة ب" لذلك، فإنها تتلقى البيانات في وقت لاحق ولكن بترتيب الكتابة نفسه.
تناسق البادئة المتسقة والمستمر "Consistent Prefix"
مثل جميع مستويات التناسق الأضعف من Strong، يتم نسخ عمليات الكتابة إلى ثلاث نسخ متماثلة كحد أدنى (في مجموعة أربع نسخ متماثلة) في المنطقة المحلية، مع النسخ المتماثل غير المتزامن إلى جميع المناطق الأخرى.
في البادئة المتناسقة، ترى التحديثات التي تم إجراؤها أثناء كتابة مستند واحد التناسق النهائي.
يتم إرجاع التحديثات التي تم إجراؤها كدفعة داخل معاملة، بما يتفق مع المعاملة التي تم الالتزام بها. تكون عمليات الكتابة داخل معاملة من مستندات متعددة مرئية دائما معا.
افترض أنه يتم تنفيذ عمليتي كتابة بشكل معاملات (كل العمليات أو لا شيء) على مستند Doc1 متبوعا بمستند Doc2، ضمن الحركات T1 وT2. عندما يقوم العميل بقراءة في أي نسخة متماثلة، يرى المستخدم إما "Doc1 v1 و Doc2 v1" أو "Doc1 v2 و Doc2 v2" أو أي مستند إذا كانت النسخة المتماثلة متأخرة، ولكن لا يرى أبدا "Doc1 v1 و Doc2 v2" أو "Doc1 v2 و Doc2 v1" لنفس عملية القراءة أو الاستعلام.
يوضح الرسم التالي اتساق بادئة الاتساق مع الملاحظات الموسيقية. في جميع المناطق، لا ترى القراءات كتابات خارج الترتيب لمجموعة معاملات من عمليات الكتابة:
الاتساق النهائي "Eventual"
مثل جميع مستويات التناسق الأضعف من Strong، يتم نسخ عمليات الكتابة إلى ثلاث نسخ متماثلة كحد أدنى (في مجموعة أربع نسخ متماثلة) في المنطقة المحلية، مع النسخ المتماثل غير المتزامن إلى جميع المناطق الأخرى.
في التناسق النهائي، يصدر العميل طلبات القراءة مقابل أي من النسخ المتماثلة الأربع في المنطقة المحددة. قد تكون هذه النسخة المتماثلة متأخرة وقد ترجع بيانات قديمة أو لا توجد بيانات.
التناسق النهائي هو أضعف شكل من أشكال التناسق لأن العميل قد يقرأ القيم الأقدم من تلك التي يقرأها في الماضي. يعد التناسق في نهاية المطاف مثاليًا حيثما لا يتطلب التطبيق أي ضمانات للطلب. تتضمن الأمثلة عدد التغريدات التي تمت إعادة تغريدها أو الإعجاب بها أو التعليقات غير المرتبطة بها. يوضح الرسم التالي الاتساق Eventual مع الملاحظات الموسيقية.
ضمانات التناسق في الممارسة العملية
في الممارسة العملية، قد تحصل في كثير من الأحيان على ضمانات تناسق أقوى. تتوافق ضمانات التناسق لعملية القراءة مع حداثة وترتيب حالة قاعدة البيانات التي تطلبها. يرتبط تناسق القراءة بترتيب عمليات الكتابة/التحديث ونشرها.
في حالة عدم وجود عمليات كتابة على قاعدة البيانات، من المحتمل أن تؤدي عملية قراءة بمستويات اتساق eventual أو session أو consistent prefix إلى نفس النتائج كعملية قراءة بمستوى اتساق قوي.
إذا تم تكوين حسابك بمستوى تناسق آخر غير التناسق القوي، يمكنك معرفة احتمال أن يحصل عملاؤك على قراءات قوية ومتسقة لأحمال العمل الخاصة بك. يمكنك معرفة هذا الاحتمال من خلال النظر في مقياس Staleness المقيدة Probabilistically (PBS). يتم عرض هذا المقياس في مدخل Azure، لمعرفة المزيد، راجع مقياس Monitor Probabilistically Bounded Staleness (PBS).
يوضح مقياس «Probabilistically Bounded Staleness» كيف يكون الاتساق النهائي لديك. يوفر هذا المقياس نظرة ثاقبة حول عدد المرات التي يمكنك فيها الحصول على تناسق أقوى من مستوى التناسق الذي قمت بتكوينه حاليا على حساب Azure Cosmos DB الخاص بك. بمعنى آخر، يمكنك أن ترى احتمال (يقاس بالمللي ثانية) للحصول على قراءات متسقة لمجموعة من مناطق الكتابة والقراءة.
مستويات الاتساق وزمن الوصول
دائماً ما يكون زمن الوصول للقراءة لجميع مستويات الاتساق مضموناً بأن يكون أقل من 10 مللي ثانية عند النسبة المئوية 99. يبلغ متوسط زمن الوصول للقراءة، عند القيمة المئوية 50، 4 مللي ثانية أو أقل بشكل نموذجي.
دائماً ما يكون زمن وصول الكتابة لجميع مستويات الاتساق مضموناً بأن يكون أقل من 10 مللي ثانية عند النسبة المئوية 99. يبلغ متوسط زمن الوصول للكتابة، عند القيمة المئوية 50، 5 مللي ثانية أو أقل عادة. تعد حسابات Azure Cosmos DB التي تمتد عبر عدة مناطق ويتم تكوينها بتناسق قوي استثناء لهذا الضمان.
قم بكتابة زمن الوصول والاتساق القوي
بالنسبة لحسابات Azure Cosmos DB المكونة بتناسق قوي مع أكثر من منطقة واحدة، فإن زمن انتقال الكتابة يساوي مرتين وقت الإرسال والإياب (RTT) بين أي من المنطقتين البعيدتين، بالإضافة إلى 10 مللي ثانية عند النسبة المئوية 99. سيترجم RTT للشبكة العالية بين المناطق إلى زمن انتقال أعلى لطلبات Azure Cosmos DB نظرا لأن التناسق القوي لا يكمل العملية إلا بعد التأكد من أنها ملتزمة بجميع المناطق داخل الحساب.
يعتمد زمن وصول RTT الدقيق على سرعة المسافة الضوئية ومخطط شبكات Azure. لا توفر شبكة Azure أي وحدات SLA لوقت انتقال ل RTT بين أي منطقتين من مناطق Azure، إلا إنها تنشر إحصائيات زمن الوصول إلى الشبكة Azure. بالنسبة لحساب Azure Cosmos DB الخاص بك، يتم عرض زمن انتقال النسخ المتماثل في مدخل Microsoft Azure. يمكنك استخدام مدخل Microsoft Azure عن طريق الانتقال إلى قسم Metrics ثم تحديد خيار Consistency. باستخدام مدخل Microsoft Azure، يمكنك مراقبة زمن انتقال النسخ المتماثل بين المناطق المختلفة المقترنة بحساب Azure Cosmos DB الخاص بك.
هام
جري حجب اتساقاً قوياً مع الحسابات التي تغطي أكثر من 5000 ميل (8000 كيلومتر)، بشكل افتراضي بسبب زمن وصول الكتابة المرتفع. لتمكين هذه الإمكانية الرجاء الاتصال بالدعم.
مستويات الاتساق والإنتاجية
من أجل strong and bounded staleness، تتم القراءة مقابل نسختين متماثلتين في مجموعة أربع نسخ متماثلة (نصاب الأقلية) لتوفير ضمانات الاتساق. Session، وconsistent prefix، وeventual تنفيذ نسخة قراءة متماثلة واحدة. والنتيجة هي أن معدل القراءة بالنسبة لنفس العدد من وحدات الطلب، لتحقيق دوام قوي ومحدود، يمثل نصف مستويات الاتساق الأخرى.
بالنسبة لنوع معين من عملية الكتابة، مثل الإدراج والاستبدال والإصدار والحذف، فإن سعة معالجة الكتابة لوحدات الطلب متطابقة لجميع مستويات الاتساق. للحصول على اتساق قوي، يلزم إجراء تغييرات في كل منطقة (الأغلبية العالمية) بينما تستخدم الأغلبية المحلية (ثلاث نسخ مماثلة في مجموعة أربع نسخ مماثلة) بالنسبة لجميع المستويات الأخرى للاتساق.
| مستوى الأتساق | قراءات Quorum | كتابات Quorum |
|---|---|---|
| قويه | الأقلية المحلية | الأغلبية العالمية |
| Bounded Staleness | الأقلية المحلية | الأغلبية المحلية |
| الدوره | نسخة متماثلة واحدة (باستخدام رمز session) | الأغلبية المحلية |
| بادئة متسقة | نسخة متماثلة واحدة | الأغلبية المحلية |
| Eventual | نسخة متماثلة واحدة | الأغلبية المحلية |
إشعار
تكلفة وحدات الطلب للقراءات لقراءات الأقلية المحلية ضعف تكلفة مستويات التناسق الأضعف لأن القراءات تتم من نسختين متماثلتين لتوفير ضمانات التناسق لمستويات تناسق Strong و Bounded Staleness.
مستويات الاتساق ومتانة البيانات
داخل بيئة قاعدة البيانات الموزعة عالمياً، توجد علاقة مباشرة بين مستوى الاتساق ومتانة البيانات في حالة وجود انقطاع على مستوى المنطقة. أثناء قيامك بتطوير خطة استمرارية العمل، يتعين عليك فهم الفترة القصوى التي تستغرقها تحديثات البيانات الحديثة التي يمكن أن يتحمل التطبيق فقدانها عند الاستعادة بعد وقوع حدث تخريبي. تعرف الفترة الزمنية للتحديثات التي قد تتحمل فقدها ب هدف نقطة الاسترداد (RPO).
يحدد هذا الجدول العلاقة بين نموذج التناسق ومتانة البيانات في وجود انقطاع على مستوى المنطقة.
| المنطقة (المناطق) | وضع النسخ المتماثل | مستوى التناسق | هدف نقطة الاسترداد (RPO) |
|---|---|---|---|
| 1 | مناطق الكتابة المفردة أو المتعددة | أي مستوى اتساق | < 240 دقيقة |
| >1 | منطقة كتابة فردية | Session, Consistent Prefix, Eventual | < 15 دقيقة |
| >1 | منطقة كتابة فردية | Bounded Staleness | K & T |
| >1 | منطقة كتابة فردية | قوي "Strong" | 0 |
| >1 | مناطق كتابة متعددة | Session, Consistent Prefix, Eventual | < 15 دقيقة |
| >1 | مناطق كتابة متعددة | Bounded Staleness | K & T |
K = عدد إصدارات "K" (أي التحديثات) لعنصر ما.
T = الفاصل الزمني "T" منذ آخر تحديث.
بالنسبة لحساب منطقة واحد، تبلغ القيمة الدنيا لـ K وT هو 10 عمليات كتابة أو 5 ثوان. بالنسبة للحسابات متعددة المناطق، تبلغ القيمة الدنيا K وT 100،000 عملية كتابة أو 300 ثانية. تحدد هذه القيمة الحد الأدنى من RPO للبيانات عند استخدام Bounded Staleness.
اتساق قوي ومناطق كتابة متعددة
لا يمكن تكوين حسابات Azure Cosmos DB التي تم تكوينها مع مناطق كتابة متعددة لتناسق قوي حيث لا يمكن للنظام الموزع توفير RPO من الصفر وRTO من الصفر. بالإضافة إلى ذلك، لا توجد مزايا لزمن الكتابة عند استخدام الاتساق القوي مع مناطق الكتابة المتعددة لأنه يجب نسخ الكتابة إلى أي منطقة والالتزام بها لجميع المناطق التي تم تكوينها داخل الحساب. ينتج عن هذا السيناريو نفس زمن انتقال الكتابة مثل حساب منطقة كتابة واحدة.
المزيد من القراءة
لمعرفة المزيد حول مفاهيم الاتساق، اقرأ المقالات التالية:
- مواصفات TLA+ عالية المستوى لمستويات الاتساق الخمسة التي يقدمها Azure Cosmos DB
- تم شرح اتساق البيانات المنسوخة من خلال Baseball (فيديو) بواسطة Dog Terry
- تم شرح اتساق البيانات المنسوخة نسخا متماثلاً من خلال Baseball (ورقة بيضاء) بواسطة Dog Terry
- ضمانات الجلسة للبيانات المنسوخة بشكل ضعيف
- مقايضات الاتساق في تصميم أنظمة قواعد البيانات الحديثة الموزعة: CAP هي جزء فقط من المجموعة النصية
- Probabilistic Bounded Staleness (PBS) لـQuorums الجزئي العملي
- متسقة Eventually -- إعادة النظر
الخطوات التالية
لمعرفة المزيد حول مستويات الاتساق في Azure Cosmos DB، اقرأ المقالات التالية: