مشاركة عبر


Sharding for Horizontal Scalability في Azure DocumentDB

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

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

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

الشظايا المنطقية

جميع المستندات التي تحتوي على نفس قيمة مفتاح الشظية تنتمي إلى نفس الشارد المنطقي.

على سبيل المثال، دعونا ننظر إلى مجموعة تسمى Employees مع هيكل المستند أدناه.

يعرض هذا الجدول تعيين قيم مفاتيح الشظية إلى التقسيمات المنطقية.

معرف المستند قيمة مفتاح الشظية الشظية المنطقية
"12345" "ستيف سميث" القطعة 1
"23456" "جين دو" شارد 2
"34567" "ستيف سميث" القطعة 1
"45678" "مايكل سميث" شارد 3
"56789" "جين دو" شارد 2
  • لا توجد حدود لعدد الشظايا المنطقية في المجموعة. يمكن أن تحتوي المجموعة على عدد من الشظايا المنطقية مثل المستندات ذات القيمة الفريدة لخاصية مفتاح الشارد في كل مستند.

  • لا توجد أيضا حدود لحجم شظية منطقية واحدة.

  • بالإضافة إلى ذلك، لا تقيد الخدمة المعاملات ضمن نطاق الشظية المنطقية. يدعم Azure DocumentDB معاملات القراءة والكتابة التي يمكن تطبيقها عبر عدة شاردات منطقية وعبر عدة شاردات مادية في العنقود.

القطع المادية

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

يتم تعريف عدد الشظايا الفيزيائية عند إنشاء عنقود ويمكن زيادته إذا زاد حجم قاعدة البيانات مع مرور الوقت. تحتوي مجموعات الشظية المفردة على شارد مادي واحد (عقدة) مسؤولة بالكامل عن تخزين العنبوت ومعاملات قاعدة البيانات. توزع مجموعات القطع المتعددة البيانات وحجم المعاملات عبر الشظايا الفيزيائية في العنقود.

ربط الشظايا المنطقية بالشظايا الفيزيائية

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

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

استنادا إلى المثال السابق باستخدام عنقود يحتوي على شظيتين ماديين، يعرض هذا الجدول نموذجا لتحويل المستندات إلى شظايا مادية.

معرف المستند قيمة مفتاح الشظية الشظية المنطقية الشظية الفيزيائية
"12345" "ستيف سميث" القطعة 1 الشظية الفيزيائية 1
"23456" "جين دو" شارد 2 الشظية الفيزيائية 2
"34567" "ستيف سميث" القطعة 1 الشظية الفيزيائية 1
"45678" "مايكل سميث" شارد 3 الشظية الفيزيائية 1
"56789" "جين دو" شارد 2 الشظية الفيزيائية 2

سعة الشظايا الفيزيائية

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

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

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

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

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

أفضل الممارسات لتقسيم البيانات

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

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

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

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

  • لتحقيق الأداء الأمثل، يجب أن يكون حجم التخزين للشظية المنطقية أقل من 4 تيرابايت.

  • لتحقيق الأداء الأمثل، يجب توزيع الشظايا المنطقية بشكل متساو في حجم التخزين والطلب عبر الشظايا الفيزيائية في العنقود.

كيفية تقسيم مجموعة

انظر إلى الوثيقة التالية ضمن قاعدة بيانات 'cosmicworks' ومجموعة 'الموظفين'

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

العينة التالية تفصل مجموعة الموظفين ضمن قاعدة بيانات cosmicworks على خاصية firstName.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

يمكن أيضا تقسيم المجموعة باستخدام أمر المسؤول:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

على الرغم من أنه ليس مثاليا تغيير مفتاح الشارد بعد أن ينمو حجم التخزين بشكل كبير، إلا أن أمر reshardCollection يمكن استخدامه لتغيير مفتاح الشارد.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

يمكن أيضا إعادة تشارد المجموعة باستخدام أمر المسؤول:

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

كأفضل ممارسة، يجب إنشاء مؤشر على خاصية مفتاح الشارد.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

الخطوات التالية