إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يجب أن توازن قواعد البيانات الموزعة التي تعتمد على النسخ المتماثل للتوفر العالي أو زمن الانتقال المنخفض أو كليهما بين تناسق القراءة والتوافر وزمن الانتقال والإنتاجية كما هو محدد في نظرية PACELC. إن قابلية الخطية لنموذج الاتساق القوي هي المعيار لقابلية برمجة البيانات. ومع ذلك، فإنه يزيد من زمن انتقال الكتابة لأنه يجب أن يتم نسخ البيانات والالتزام بها عبر مسافات كبيرة. يقلل الاتساق القوي أيضا من التوفر أثناء حالات الفشل لأنه لا يمكن للبيانات النسخ المتماثل والالتزام في كل منطقة. يوفر الاتساق النهائي توفرا أعلى وأداء أفضل، ولكن من الصعب برمجة التطبيقات لأن البيانات قد لا تكون متسقة في جميع المناطق.
توفر معظم قواعد بيانات NoSQL الموزعة في السوق اليوم اتساقا قويا ونهائيا فقط. يقدم Azure Cosmos DB خمسة مستويات محددة جيداً. من الأقوى إلى الأضعف، والمستويات هي:
لمزيد من المعلومات حول مستوى التناسق الافتراضي، راجع تكوين مستوى التناسق الافتراضي أو منع مستوى التناسق الافتراضي.
يوازن كل مستوى بين التوافر والأداء. توضح الصورة التالية مستويات التناسق كلطيف.
مستويات الاتساق و واجهات برمجة التطبيقات Azure Cosmos DB
يدعم Azure Cosmos DB واجهات برمجة التطبيقات المتوافقة مع البروتوكول السلكي لقواعد البيانات الشائعة، بما في ذلك MongoDB وApache Cassandra وApache Gremlin وAzure Table Storage. بالنسبة لواجهة برمجة التطبيقات ل Gremlin أو Table، يستخدم Azure Cosmos DB مستوى التناسق الافتراضي الذي تم تكوينه على الحساب. للتعرف على تعيين مستوى التناسق، راجع واجهة برمجة التطبيقات لتعيين تناسق Cassandra ل Apache Cassandra وواجهة برمجة التطبيقات لتعيين تناسق MongoDB ل MongoDB.
نطاق تناسق القراءة
ينطبق تناسق القراءة على عملية قراءة واحدة داخل قسم منطقي. يمكن للعميل البعيد أو الإجراء المخزن أو المشغل إصدار عملية القراءة.
تكوين مستوى الاتساق الافتراضي
قم بتكوين مستوى التناسق الافتراضي على حساب Azure Cosmos DB في أي وقت. ينطبق مستوى التناسق الافتراضي الذي تم تكوينه على حسابك على جميع قواعد بيانات وحاويات Azure Cosmos DB ضمن هذا الحساب. تستخدم جميع القراءات والاستعلامات الصادرة مقابل حاوية أو قاعدة بيانات مستوى الاتساق المحدد بشكل افتراضي. عند تغيير الاتساق على مستوى الحساب، أعد توزيع تطبيقاتك وقم بإجراء أي تعديلات ضرورية على التعليمات البرمجية لتطبيق هذه التغييرات. تعرف على المزيد حول كيفية تكوين مستوى التناسق الافتراضي. يمكنك أيضا تجاوز مستوى التناسق الافتراضي لطلب معين. تعرف على المزيد في مقالة إلغاء مستوى التناسق التلقائي .
تلميح
ينطبق تجاوز مستوى التناسق الافتراضي فقط على القراءات داخل عميل SDK. لا يزال الحساب الذي تم تكوينه للتناسق القوي بشكل افتراضي يكتب البيانات وينسخها بشكل متزامن مع كل منطقة في الحساب. عندما يتجاوز مثيل عميل SDK أو الطلب هذا التناسق مع جلسة العمل أو الاتساق الأضعف، يتم إجراء القراءات باستخدام نسخة متماثلة واحدة. لمزيد من المعلومات، راجع مستويات التناسق ومعدل النقل.
هام
أعد إنشاء أي مثيل SDK بعد تغيير مستوى التناسق الافتراضي عن طريق إعادة تشغيل التطبيق. تضمن هذه الخطوة أن SDK يستخدم مستوى التناسق الافتراضي الجديد.
الضمانات المرتبطة بمستويات الاتساق
يضمن Azure Cosmos DB أن 100% من طلبات القراءة تفي بضمان التناسق لمستوى التناسق المختار. يتم توفير التعريفات الدقيقة لمستويات الاتساق الخمسة في Azure Cosmos DB باستخدام لغة مواصفات TLA - المنطق الزمني للإجراءات - في مستودع GitHub azure/azure-cosmos-tla .
ترد في الأقسام التالية المصطلحات الدلالية لمستويات الاتساق الخمسة.
تناسق قوي
التناسق القوي يوفر ضمان القابلية الخطية. تعني قابلية الخط خدمة الطلبات بشكل متزامن. تضمن عمليات القراءة إرجاع أحدث إصدار تم الالتزام به لأحد العناصر. لا يرى العميل أبداً كتابة غير ملتزمة أو جزئية. يضمن للمستخدمين دائماً قراءة آخر كتابة تم الالتزام بها.
يظهر الرسم التالي تناسقا قويا مع النوتات الموسيقية. بعد كتابة البيانات إلى منطقة "غرب الولايات المتحدة 2"، عندما تقرأ البيانات من مناطق أخرى، تحصل على أحدث قيمة:
الحصة الديناميكية
في ظل الظروف العادية، بالنسبة للحساب ذي الاتساق القوي، تعتبر الكتابة ملتزمة عندما تقر جميع المناطق بالنسخ المتماثل للسجل. إذا كان حسابك يحتوي على ثلاث مناطق أو أكثر، فيمكن للنظام خفض عدد المناطق المطلوبة للنصاب القانوني عندما تكون بعض المناطق بطيئة أو لا تستجيب. يساعد هذا في الحفاظ على الاتساق القوي حتى لو كانت هناك مشكلات في بعض المناطق. عند هذه النقطة، يتم إخراج المناطق غير المستجيبة من مجموعة الحصة من المناطق من أجل الحفاظ على الاتساق القوي. تتم إضافتها مرة أخرى فقط عندما تصبح متسقة مع المناطق الأخرى وتعمل كما هو متوقع. يعتمد عدد المناطق التي يمكن إخراجها من مجموعة النصاب القانوني على العدد الإجمالي للمناطق. على سبيل المثال، في حساب ثلاث أو أربع مناطق، تكون الأغلبية من منطقتين أو ثلاث مناطق على التوالي، لذلك يمكن إزالة منطقة واحدة فقط في كلتا الحالتين. بالنسبة لحساب خمس مناطق، تكون الأغلبية ثلاثة، لذلك يمكن إزالة ما يصل إلى منطقتين غير مستجيبين. تعرف هذه الإمكانية باسم "النصاب الديناميكي" ويمكنها تحسين كل من توفر الكتابة وزمن انتقال النسخ المتماثل للحسابات ذات ثلاث مناطق أو أكثر.
إشعار
عند إزالة المناطق من مجموعة النصاب كجزء من النصاب الديناميكي، لن تتمكن هذه المناطق من تقديم القراءات حتى تتم إعادة إضافتها إلى النصاب القانوني.
تناسق غير محدد "Bounded staleness"
بالنسبة لحسابات الكتابة في منطقة واحدة مع منطقتين أو أكثر، يتم نسخ البيانات من المنطقة الأساسية إلى جميع المناطق الثانوية (للقراءة فقط). بالنسبة لحسابات الكتابة متعددة المناطق مع منطقتين أو أكثر، يتم نسخ البيانات من المنطقة التي تمت كتابتها فيها في الأصل إلى جميع المناطق الأخرى القابلة للكتابة. في كلا السيناريوهين ، على الرغم من أنه ليس شائعا ، قد يكون هناك أحيانا تأخر في النسخ المتماثل من منطقة إلى أخرى.
في تناسق الثبات المرتبط، يكون تأخر البيانات بين أي منطقتين دائما أقل من مقدار محدد. يمكن أن يكون المبلغ هو إصدارات "K" (أي "التحديثات") لعنصر أو بفواصل زمنية "T"، أيهما يتم الوصول إليه أولا. بمعنى آخر، عند اختيار bounded staleness، يمكن تكوين الحد الأقصى "staleness" للبيانات في أي منطقة بطريقتين:
- عدد إصدارات (K) من العنصر
- قد يتأخر الفاصل الزمني (T) الذي تمت قراءته عن عمليات الكتابة
يعد التقادم المحدود مفيدا بشكل أساسي لكتابة حسابات منطقة واحدة مع منطقتين أو أكثر. إذا تجاوز تأخر البيانات في منطقة ما (يتم تحديده لكل قسم فعلي) قيمة الثبات المكونة، يتم تقييد عمليات الكتابة لهذا القسم حتى يعود الثبات داخل الحد الأعلى المكون.
بالنسبة لحساب منطقة واحدة، يوفر 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 مع الملاحظات الموسيقية.
ضمانات التناسق في الممارسة العملية
من الناحية العملية ، قد تحصل في كثير من الأحيان على ضمانات تناسق أقوى. تتوافق ضمانات التناسق لعملية القراءة مع حداثة وترتيب حالة قاعدة البيانات التي تطلبها. يرتبط تناسق القراءة بترتيب عمليات الكتابة والتحديث ونشرها.
إذا لم تكن هناك عمليات كتابة على قاعدة البيانات، فقد تؤدي عملية القراءة ذات مستويات تناسق البادئة النهائية أو جلسة العمل أو المتسقة إلى نفس نتائج عملية القراءة بمستوى التناسق القوي.
إذا تم تكوين حسابك بمستوى تناسق بخلاف التناسق القوي، فيمكنك معرفة احتمالية حصول عملائك على قراءات قوية ومتسقة لأحمال العمل الخاصة بك. اكتشف هذا الاحتمال من خلال النظر إلى مقياس الجمود الاحتمالي (PBS ). يتم عرض هذا المقياس في مدخل Microsoft Azure. لمزيد من المعلومات، راجع مقياس مراقبة الجمود الاحتمالي (PBS).
يظهر الجمود المحدود احتماليا مدى اتساقك النهائي في نهاية المطاف. يوفر هذا المقياس نظرة ثاقبة حول عدد المرات التي تحصل فيها على تناسق أقوى من مستوى التناسق الذي تم تكوينه حاليا على حساب 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 اتفاقيات مستوى خدمة زمن الانتقال (SLAs) ل RTT بين مناطق Azure، ولكنها تنشر إحصائيات زمن انتقال شبكة Azure ذهابا وإيابا. بالنسبة لحساب Azure Cosmos DB الخاص بك، يتم عرض زمن انتقال النسخ المتماثل في مدخل Microsoft Azure. استخدم مدخل Microsoft Azure بالانتقال إلى قسم المقاييس وتحديد خيار التناسق . باستخدام مدخل Microsoft Azure، يمكنك مراقبة زمن انتقال النسخ المتماثل بين المناطق المختلفة المقترنة بحساب Azure Cosmos DB الخاص بك.
هام
يتم حظر الاتساق القوي للحسابات ذات المناطق التي تمتد لأكثر من 5,000 ميل (8,000 كيلومتر) بشكل افتراضي بسبب زمن انتقال الكتابة المرتفع. لتمكين هذه الإمكانية، اتصل بالدعم.
مستويات الاتساق والإنتاجية
من أجل الجمود القوي والمحدود ، تتم القراءات مقابل نسختين متماثلتين في مجموعة من أربع نسخ متماثلة (نصاب الأقلية) لضمان ضمانات الاتساق. تستخدم الجلسة والبادئة المتسقة والاتساق النهائي قراءات النسخة المتماثلة الفردية. ونتيجة لذلك، بالنسبة لنفس العدد من وحدات الطلب، فإن معدل نقل القراءة للثبات القوي والمحدود هو نصف مستويات التناسق الأخرى.
بالنسبة لنوع معين من عمليات الكتابة، مثل الإدراج أو الاستبدال أو التثبيت أو الحذف، يكون معدل نقل الكتابة لوحدات الطلب متطابقا عبر جميع مستويات التناسق. من أجل الاتساق القوي، يجب إجراء تغييرات في كل منطقة (الأغلبية العالمية)، بينما بالنسبة لجميع مستويات الاتساق الأخرى، يتم استخدام الأغلبية المحلية (ثلاث نسخ متماثلة في مجموعة من أربع نسخ متماثلة).
| مستوى الأتساق | قراءات Quorum | كتابات Quorum |
|---|---|---|
| قوي | الأقلية المحلية | الأغلبية العالمية |
| الجمود المحدود | الأقلية المحلية | الأغلبية المحلية |
| جلسة | نسخة متماثلة واحدة (باستخدام رمز session) | الأغلبية المحلية |
| بادئة متسقة | نسخة متماثلة واحدة | الأغلبية المحلية |
| Eventual | نسخة متماثلة واحدة | الأغلبية المحلية |
إشعار
تبلغ تكلفة RU للقراءات لقراءات الأقليات المحلية ضعف تكلفة مستويات الاتساق الأضعف لأن القراءات تتم من نسختين متماثلتين لضمان ضمانات الاتساق لمستويات تناسق التقادم القوية والمحدودة.
مستويات الاتساق ومتانة البيانات
في بيئة قاعدة البيانات الموزعة عالميا، يؤثر مستوى الاتساق بشكل مباشر على متانة البيانات أثناء الانقطاع على مستوى المنطقة. عند تطوير خطة استمرارية الأعمال، افهم الحد الأقصى لفترة تحديثات البيانات الأخيرة التي يمكن للتطبيق تحمل فقدانها أثناء التعافي من حدث تخريبي. يشار إلى الفترة الزمنية للتحديثات التي يمكن فقدها باسم هدف نقطة الاسترداد (RPO).
يوضح هذا الجدول العلاقة بين نماذج التناسق ومتانة البيانات أثناء انقطاع التيار الكهربائي على مستوى المنطقة.
| Regions | وضع النسخ المتماثل | مستوى التناسق | هدف نقطة الاسترداد (RPO) |
|---|---|---|---|
| 1 | مناطق الكتابة المفردة أو المتعددة | أي مستوى اتساق | < 240 دقيقة |
| >1 | منطقة كتابة فردية | الجلسة ، بادئة متسقة ، نهائية | < 15 دقيقة |
| >1 | منطقة كتابة فردية | الجمود المحدود | كآند تي |
| >1 | منطقة كتابة فردية | قوي "Strong" | 0 |
| >1 | مناطق كتابة متعددة | الجلسة ، بادئة متسقة ، نهائية | < 15 دقيقة |
| >1 | مناطق كتابة متعددة | الجمود المحدود | كآند تي |
K = عدد إصدارات K (التحديثات) للعنصر.
T = الفاصل الزمني T منذ آخر تحديث.
بالنسبة لحساب منطقة واحدة، يكون الحد الأدنى لقيمة KوT هو 10 عمليات كتابة أو 5 ثوان. بالنسبة للحسابات متعددة المناطق، يكون الحد الأدنى لقيمة KوT هو 100,000 عملية كتابة أو 300 ثانية. تحدد هذه القيمة الحد الأدنى لهدف نقطة الاسترداد (RPO) للبيانات عند استخدام التقادم المحدود.
اتساق قوي ومناطق كتابة متعددة
لا يمكن لحسابات Azure Cosmos DB ذات مناطق الكتابة المتعددة استخدام تناسق قوي لأن النظام الموزع لا يمكنه توفير هدف نقطة استرداد (RPO) للصفر وهدف وقت الاسترداد (RTO) الصفر. بالإضافة إلى ذلك، لا يؤدي الاتساق القوي مع مناطق الكتابة المتعددة إلى تحسين زمن انتقال الكتابة لأنه يجب نسخ عمليات الكتابة والالتزام بها في جميع المناطق في الحساب. ينتج عن هذا الإعداد نفس زمن انتقال الكتابة مثل حساب منطقة كتابة واحدة.
المزيد من القراءة
لمعرفة المزيد حول مفاهيم الاتساق، اقرأ المقالات التالية:
- مواصفات TLA⁺ عالية المستوى لمستويات التناسق الخمسة التي يوفرها Azure Cosmos DB
- شرح تناسق البيانات المنسوخة من خلال لعبة البيسبول (فيديو) بواسطة دوغ تيري
- شرح تناسق البيانات المنسوخة من خلال لعبة البيسبول (المستند التقني) بواسطة دوغ تيري
- ضمانات الجلسة للبيانات المنسوخة بشكل ضعيف
- مقايضات الاتساق في تصميم أنظمة قواعد البيانات الموزعة الحديثة: CAP ليس سوى جزء من القصة
- الجمود الاحتمالي المحدود (PBS) للنصاب الجزئي العملي
- متسق في النهاية - إعادة النظر
المحتوى ذو الصلة
- تكوين مستوى الاتساق الافتراضي
- تجاوز مستوى الاتساق الافتراضي
- تعرف على المزيد حول Azure Cosmos DB SLA.