مشاركة عبر

التقسيم والتطوير الأفقي في Azure Cosmos DB

  • مقالة

ينطبق على: NoSQL MongoDB كاساندرا العفريت جدول

يستخدم Azure Cosmos DB التقسيم لتوسيع حجم الحاويات الفردية في قاعدة البيانات لتلبية احتياجات الأداء للتطبيق الخاص بك. تنقسم العناصر الموجودة في الحاوية إلى مجموعات فرعية مميزة تسمى الأقسام المنطقية. يتم تشكيل الأقسام المنطقية استناداً إلى قيمة مفتاح القسم المقترنة مع كل عنصر في الحاوية. تحتوي جميع العناصر الموجودة في القسم المنطقي على نفس قيمة مفتاح القسم.

على سبيل المثال، حاوية تحتوي على العناصر. يحتوي كل عنصر على قيمة فريدة للخاصية UserID. إذا كان UserID بمثابة مفتاح القسم للعناصر الموجودة في الحاوية، وهناك قيم UserID فريدة 1000، يتم إنشاء 1000 قسم منطقي للحاوية.

بالإضافة إلى مفتاح القسم الذي يحدد القسم المنطقي للعنصر، يحتوي كل عنصر في الحاوية على معرف عنصر (فريد داخل قسم منطقي). يؤدي دمج مفتاح القسم ومعرف العنصر إلى إنشاء فهرسالعنصر، والذي يحدد العنصر بشكل فريد. اختيار مفتاح القسم هو قرار مهم يؤثر على أداء التطبيق الخاص بك.

تشرح هذه المقالة العلاقة بين الأقسام المنطقية والمادية. كما يناقش أفضل الممارسات للتقسيم ويعطي نظرة متعمقة حول كيفية عمل القياس الأفقي في Azure Cosmos DB. ليس من الضروري فهم هذه التفاصيل الداخلية لتحديد مفتاح القسم الخاص بك لكننا نغطيها حتى تتمكن من الحصول على وضوح حول كيفية عمل Azure Cosmos DB.

الأقسام المنطقية

يتكون القسم المنطقي من مجموعة من العناصر التي تحتوي على نفس مفتاح القسم. على سبيل المثال، في حاوية تحتوي على بيانات حول التغذية الغذائية، تحتوي جميع العناصر على الخاصية foodGroup. يمكنك استخدام foodGroup كمفتاح القسم للحاوية. تشكل مجموعات العناصر التي تحتوي على قيم محددة لـ foodGroup، مثل Beef Products وBaked Productsو Sausages and Luncheon Meats، أقساماً منطقية مميزة.

كما يعرّف القسم المنطقي نطاق بحث عملية قاعدة البيانات. يمكنك تحديث العناصر داخل قسم منطقي باستخدام معاملة مع عزل لقطة. عند إضافة عناصر جديدة إلى حاوية، يقوم النظام بإنشاء أقسام منطقية جديدة بشفافية. لا داعي للقلق بشأن حذف القسم المنطقي عند حذف البيانات الأساسية.

لا يوجد حد لعدد الأقسام المنطقية في الحاوية الخاصة بك. يمكن لكل قسم منطقي تخزين ما يصل إلى 20 غيغابايت من البيانات. خيارات مفتاح التقسيم الجيدة لها نطاق واسع من القيم الممكنة. على سبيل المثال، في حاوية تحتوي جميع العناصر فيها على خاصية foodGroup، يمكن أن تزيد البيانات داخل القسم المنطقي Beef Products حتى 20 غيغابايت. يضمنتحديد مفتاح قسم بنطاق واسع من القيم الممكنة أن الحاوية قادرة على التحجيم.

يمكنك استخدام Azure Monitor Alerts لمراقبة ما إذا كان حجم قسم منطقي يقترب من 20 غيغابايت.

الأقسام المادية

يتم تحجيم حاوية بتوزيع البيانات والإنتاجية عبر الأقسام الفعلية. داخلياً، يتم تعيين قسم منطقي واحد أو أكثر إلى قسم فعلي واحد. تحتوي حاويات أصغر عادة على العديد من الأقسام المنطقية ولكنها تتطلب قسم فعلي واحد فقط. على عكس الأقسام المنطقية، تعد الأقسام المادية تنفيذا داخليا للنظام ويدير Azure Cosmos DB الأقسام المادية بالكامل.

يعتمد عدد الأقسام الفعلية في الحاوية على الخصائص التالية:

  • مقدار الإنتاجية المقدمة (يمكن أن يوفر كل قسم مادي فردي معدل نقل تصل إلى 10000 وحدة طلب في الثانية). الحد 10,000 وحدة طلب لكل ثانية للأقسام الفعلية يعني أن الأقسام المنطقية أيضاً سعتها 10,000 وحدة طلب لكل ثانية، كما يتم تعيين كل قسم منطقي إلى قسم فعلي واحد فقط.

  • إجمالي تخزين البيانات (يمكن لكل قسم مادي فردي تخزين ما يصل إلى 50 جيجابايت من البيانات).

إشعار

الأقسام المادية هي تطبيق داخلي للنظام ويتم إدارتها بالكامل من قِبَل Azure Cosmos DB. عند تطوير الحلول الخاصة بك، لا تركز على الأقسام الفعلية لأنك لا تستطيع التحكم فيها. بدلاً من ذلك، ركز على مفاتيح القسم. إذا اخترت مفتاح قسم يوزع بالتساوي استهلاك الإنتاجية عبر الأقسام المنطقية، فسوف تضمن أن استهلاك الإنتاجية عبر الأقسام الفعلية متوازن.

لا يوجد حد لإجمالي عدد الأقسام المادية في الحاوية الخاصة بك. مع نمو معدل النقل أو حجم البيانات المقدمة، يقوم Azure Cosmos DB تلقائيا بإنشاء أقسام فعلية جديدة عن طريق تقسيم الأقسام الموجودة. لا تؤثر تقسيمات الأقسام المادية على توفر التطبيق الخاص بك. بعد تقسيم القسم المادي، ستظل جميع البيانات الموجودة داخل قسم منطقي واحد مخزنة على نفس القسم المادي. ينشئ تقسيم القسم المادي ببساطة تعييناً جديداً للأقسام المنطقية إلى الأقسام المادية.

يتم تقسيم الإنتاجية المخصصة للحاوية بالتساوي بين الأقسام الفعلية. قد ينتج عن تصميم مفتاح القسم الذي لا يوزع الطلبات بالتساوي عدداً كبيراً جداً من الطلبات الموجهة إلى مجموعة فرعية صغيرة من الأقسام التي تصبح "فعالة". تؤدي الأقسام الفعالة إلى الاستخدام غير الفعال لمعدل النقل المتوفر، مما قد يؤدي إلى تحديد المعدل وارتفاع التكاليف.

على سبيل المثال، ضع في اعتبارك حاوية بالمسار /foodGroup المحدد كمفتاح القسم. يمكن أن تحتوي الحاوية على أي عدد من الأقسام المادية، ولكن في هذا المثال نفترض أن لديها ثلاثة. يمكن أن يحتوي قسم فعلي واحد على مفاتيح أقسام متعددة. على سبيل المثال، يمكن أن يحتوي القسم المادي الأكبر على أهم ثلاثة أقسام منطقية للحجم: Beef Productsو Vegetable and Vegetable Productsو Soups, Sauces, and Gravies.

إذا قمت بتعيين معدل نقل يبلغ 18000 وحدة طلب في الثانية (RU/s)، فيمكن لكل قسم من الأقسام المادية الثلاثة الاستفادة من 1/3 من إجمالي معدل النقل المقدم. داخل القسم المادي المحدد، يمكن لمفاتيح الأقسام المنطقية Beef Productsو Vegetable and Vegetable Productsو Soups, Sauces, and Gravies، بشكل جماعي، استخدام 6000 وحدة RU / ثانية متوفرة للقسم المادي. نظرا لأن معدل النقل المقدم مقسم بالتساوي عبر الأقسام المادية للحاوية الخاصة بك، فمن المهم اختيار مفتاح قسم يوزع استهلاك معدل النقل بالتساوي. لمزيد من المعلومات، راجع اختيار مفتاح القسم المنطقي الصحيح.

إدارة الأقسام المنطقية

يقوم Azure Cosmos DB بإدارة وضع الأقسام المنطقية على الأقسام المادية بشفافية وتلقائية لتلبية احتياجات قابلية التوسع والأداء للحاوية بكفاءة. مع زيادة متطلبات معدل النقل والتخزين لأحد التطبيقات، يقوم Azure Cosmos DB بنقل الأقسام المنطقية لتوزيع الحمل تلقائياً عبر عدد أكبر من الأقسام المادية. يمكنك معرفة المزيد حول الأقسام المادية.

يستخدم Azure Cosmos DB التقسيم المستند إلى التجزئة لنشر الأقسام المنطقية عبر الأقسام المادية. يقوم Azure Cosmos DB بتجزئة قيمة مفتاح القسم للعنصر. تحدد النتيجة المقسمة القسم المنطقي. بعد ذلك، يخصص Azure Cosmos DB المساحة الرئيسية لتجزئة مفاتيح القسم بالتساوي عبر الأقسام المادية.

يُسمح بالمعاملات (في الإجراءات المخزنة أو المشغلات) فقط مقابل العناصر الموجودة في قسم منطقي واحد.

مجموعات النسخ المتماثلة

يتكون كل قسم فعلي من مجموعة من النسخ المتماثلة، يشار إليها أيضاً باسم مجموعة النسخ المتماثلة. تستضيف كل نسخة متماثلة مثيلًا لمشغل قاعدة البيانات. تجعل مجموعة النسخ المتماثلة مخزن البيانات داخل القسم الفعلي دائما ومتاحا للغاية ومتسقا. ترث كل نسخة متماثلة تشكل القسم الفعلي حصة التخزين الخاصة بالقسم. تدعم جميع النسخ المتماثلة للقسم المادي بشكل جماعي معدل النقل المخصص للقسم المادي. يقوم Azure Cosmos DB تلقائياً بإدارة مجموعات النسخ المتماثلة.

عادة ما تتطلب الحاويات الأصغر قسما ماديا واحدا فقط، ولكن لا يزال لديها أربع نسخ متماثلة على الأقل.

توضح الصورة التالية كيفية تعيين الأقسام المنطقية للأقسام المادية الموزعة عالمياً. تشيرمجموعة الأقسام في الصورة إلى مجموعة من الأقسام المادية التي تدير نفس مفاتيح الأقسام المنطقية عبر مناطق متعددة:

صورة توضح تقسيم Azure Cosmos DB

اختيار مفتاح التقسيم

يحتوي مفتاح القسم على مكونين: مسار مفتاح القسم وقيمة مفتاح القسم. على سبيل المثال، خذ بعين الاعتبار عنصر { "userId" : "Andrew", "worksFor": "Microsoft" } إذا اخترت "userId" كمفتاح القسم، فيما يلي مكونين مفتاح القسم:

  • مسار مفتاح القسم (على سبيل المثال: "/ userId"). يقبل مسار مفتاح القسم الأحرف الأبجدية الرقمية والتسطير السفلي (_). يمكنك أيضاً استخدام الكائنات المتداخلة باستخدام رمز المسار القياسي(/).

  • قيمة مفتاح القسم (على سبيل المثال: "أندرو"). يمكن أن تكون قيمة مفتاح القسم من أنواع سلسلة أو رقمية.

للتعرف على حدود معدل النقل والتخزين وطول مفتاح القسم، راجع مقالة حصص خدمة Azure Cosmos DB .

اختيار مفتاح القسم الخاص بك هو خيار تصميم بسيط ولكنه مهم في Azure Cosmos DB. بمجرد تحديد مفتاح القسم الخاص بك، لا يمكن تغييره في مكانه. إذا كنت بحاجة إلى تغيير مفتاح القسم الخاص بك، يجب نقل البيانات إلى حاوية جديدة مع مفتاح القسم الجديد المطلوب. (تساعد مهام نسخ الحاوية في هذه العملية.)

بالنسبة لجميع الحاويات، يجب أن يكون مفتاح القسم الخاص بك:

  • كن خاصية لها قيمة، والتي لا تتغير. إذا كانت خاصية مفتاح القسم الخاص بك، لا يمكنك تحديث قيمة تلك الخاصية.

  • يجب أن تحتوي فقط على String قيم - أو يجب تحويل الأرقام بشكل مثالي إلى String، إذا كانت هناك أي فرصة أنها خارج حدود أرقام الدقة المزدوجة وفقا ل IEEE 754 binary64. توضح مواصفات Json الأسباب التي تجعل استخدام الأرقام خارج هذه الحدود ممارسةً سيئةً بوجهٍ عامٍ بسبب مشاكل إمكانية التشغيل التفاعلي المحتملة. هذه المخاوف ذات صلة خاصة بعمود مفتاح القسم، لأنه غير قابل للتغيير ويتطلب ترحيل البيانات لتغييره لاحقا.

  • تمتع بالحصول على علاقات أساسية مميزة. بمعنى آخر، يجب أن يكون الخاصية مجموعة واسعة من القيم المحتملة.

  • يجب نشر استهلاك وحدة الطلب وتخزين البيانات بالتساوي عبر جميع الأقسام المنطقية. يضمن هذا الانتشار استهلاك وحدات الطلب وتوزيع التخزين عبر الأقسام المادية.

  • لديك قيم لا تزيد عن 2048 بايت عادة، أو 101 بايت إذا لم يتم تمكين مفاتيح الأقسام الكبيرة. لمزيد من المعلومات، راجع مفاتيح الأقسام الكبيرة

إذا كنت بحاجة إلى معاملات ACID متعددة العناصر في Azure Cosmos DB، فأنت بحاجة إلى استخدام الإجراءات أو المشغلات المخزنة. يتم تحديد جميع الإجراءات والمشغلات المخزنة المستندة إلى JavaScript في قسم منطقي واحد.

إشعار

إذا كان لديك قسم فعلي واحد فقط، فقد لا تكون قيمة مفتاح القسم ذات صلة لأن جميع الاستعلامات ستستهدف نفس القسم الفعلي.

مفاتيح التقسيم للحاويات ذات الثقل المقروء

بالنسبة لمعظم الحاويات، فإن المعايير المذكورة أعلاه هي كل ما تحتاج إلى مراعاته عند اختيار مفتاح قسم. ومع ذلك، بالنسبة للحاويات الكبيرة والمثقلة للقراءة، قد ترغب في اختيار مفتاح قسم يظهر بشكل متكرر كعامل تصفية في استعلاماتك. يمكن توجيه الاستعلامات بكفاءة إلى الأقسام الفعلية ذات الصلة فقط عن طريق تضمين مفتاح القسم في دالة التقييم لعامل التصفية.

يمكن أن تكون هذه الخاصية اختيار مفتاح قسم جيد إذا كانت معظم طلبات حمل العمل هي استعلامات ومعظم الاستعلامات الخاصة بك لها عامل تصفية المساواة على نفس الخاصية. على سبيل المثال، إذا كنت تقوم بشكل متكرر بتشغيل استعلام يقوم بالتصفية على UserID، فإن تحديد UserID كمفتاح القسم سيقلل من عدد استعلامات الأقسام المشتركة.

ومع ذلك، إذا كانت الحاوية صغيرة، فمن المحتمل ألا يكون لديك أقسام فعلية كافية للقلق بشأن أداء الاستعلامات عبر الأقسام. تتطلب معظم الحاويات الصغيرة في Azure Cosmos DB قسماً مادياً واحداً أو قسمين فقط.

إذا كان من المُتوقّع أن تنمو الحاوية إلى أكثر من بضعة أقسام من الأقسام الفعلية، يجب عليك التأكد من اختيار مفتاح القسم الذي يقلل من استعلامات التقسيم المشترك. تتطلب الحاوية الخاصة بك أكثر من عدد قليل من الأقسام المادية عندما يكون أي مما يلي صحيحا:

  • تحتوي الحاوية الخاصة بك على أكثر من 30000 وحدة طلب/ وحدة طلب تم توفيرها

  • تخزن حاويتك أكثر من 100 غيغابايت من البيانات

استخدم معرف العنصر كمفتاح القسم

إشعار

ينطبق هذا القسم بشكل أساسي على واجهة برمجة التطبيقات ل NoSQL. لا تدعم واجهات برمجة التطبيقات الأخرى، مثل واجهة برمجة التطبيقات ل Gremlin، المعرف الفريد كمفتاح القسم.

إذا كانت الحاوية تحتوي على خاصية تحتوي على مجموعة واسعة من القيم المحتملة، فمن المحتمل أن يكون اختيار مفتاح قسم رائع. أحد الأمثلة المحتملة على هذه الخاصية هو معرف العنصر. بالنسبة للحاويات الصغيرة الثقيلة للقراءة أو الحاويات الثقيلة للكتابة من أي حجم، فإن معرف العنصر (/id) هو اختيار رائع لمفتاح القسم بشكل طبيعي.

خاصية النظام معرف العنصر موجود في كل عنصر في حاويتك. قد يكون لديك خصائص أخرى تمثل معرفا منطقيا للعنصر الخاص بك. في كثير من الحالات، هذه المعرفات هي أيضا خيارات مفتاح قسم كبيرة لنفس الأسباب مثل معرف العنصر.

معرف العنصر هو خيار مفتاح قسم رائع للأسباب التالية:

  • هناك مجموعة واسعة من القيم الممكنة (معرف عنصر فريد واحد لكل عنصر).
  • نظرا لوجود معرف عنصر فريد لكل عنصر، يقوم معرف العنصر بعمل رائع في موازنة استهلاك RU وتخزين البيانات بالتساوي.
  • يمكنك بسهولة القيام بقراءة نقطة فعالة لأنك تعرف دائما مفتاح قسم العنصر إذا كنت تعرف معرف العنصر الخاص به.

تتضمن بعض الأشياء التي يجب مراعاتها عند تحديد معرف العنصر كمفتاح القسم ما يلي:

  • إذا كان معرف العنصر هو مفتاح القسم، فإنه يصبح معرفا فريدا في جميع أنحاء الحاوية بأكملها. لا يمكنك إنشاء عناصر تحتوي على معرفات عناصر مكررة.
  • إذا كان لديك حاوية ثقيلة القراءة مع العديد من الأقسام المادية، تكون الاستعلامات أكثر كفاءة إذا كان لديها عامل تصفية المساواة مع معرف العنصر.
  • لا يمكنك تشغيل الإجراءات المخزنة أو المشغلات التي تستهدف أقسام منطقية متعددة.

المحتوى ذو الصلة