مشاركة عبر

أفضل الممارسات لتوسيع معدل النقل المقدمة (وحدات الطلب/ثانية)

  • مقالة

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

توضح هذه المقالة أفضل الممارسات والاستراتيجيات لتوسيع نطاق معدل النقل (وحدات الطلب/ الثانية) لقاعدة البيانات أو الحاوية (مجموعة أو جدول أو رسم بياني). تنطبق المفاهيم عندما تقوم بزيادة إما وحدات الطلب/ الثانية اليدوية المتوفرة أو الحد الأقصى لـ وحدات الطلب/ الثانية ذات المقياس التلقائي لأي مورد لأي من واجهات برمجة تطبيقات Azure Cosmos DB.

المتطلبات الأساسية

خلفية عن تحجيم وحدات الطلب/ الثانية

عند إرسال طلب لزيادة وحدات الطلب/ الثانية لقاعدة البيانات أو الحاوية الخاصة بك، اعتماداً على وحدات الطلب/ الثانية المطلوبة وتخطيط القسم المادي الحالي، ستكتمل عملية توسيع النطاق إما على الفور أو بشكل غير متزامن (عادةً 4-6 ساعات).

  • توسيع فوري
    • عندما يمكن دعم وحدات الطلب/ الثانية المطلوبة بواسطة تخطيط القسم المادي الحالي، لا يحتاج Azure Cosmos DB إلى تقسيم أو إضافة أقسام جديدة.
    • نتيجة لذلك، تكتمل العملية على الفور وتكون وحدات الطلب/ الثانية متاحة للاستخدام.
  • توسيع نطاق غير متزامن
    • عندما تكون وحدات الطلب/ الثانية المطلوبة أعلى مما يمكن دعمه بواسطة تخطيط القسم المادي، سيقوم Azure Cosmos DB بتقسيم الأقسام المادية الموجودة. يحدث هذا حتى يكون لدى المورد الحد الأدنى من عدد الأقسام المطلوبة لدعم وحدات الطلب/ الثانية المطلوبة.
    • نتيجة لذلك، يمكن أن تستغرق العملية بعض الوقت حتى تكتمل، عادةً من 4 إلى 6 ساعات. يمكن أن يدعم كل قسم مادي حداً أقصى من معدل النقل يصل إلى 10000 وحدات الطلب/ الثانية (ينطبق على جميع واجهات برمجة التطبيقات) من الإنتاجية و50 جيجابايت من التخزين (ينطبق على جميع واجهات برمجة التطبيقات، باستثناء Cassandra، التي تحتوي على 30 جيجابايت من السعة التخزينية).

إشعار

إذا أجريت عملية تجاوز فشل منطقة يدوياً أو إضافة / إزالة منطقة جديدة أثناء إجراء عملية توسيع نطاق غير متزامنة، فسيتم إيقاف عملية زيادة معدل النقل مؤقتاً. سيتم استئنافه تلقائياً عند اكتمال عملية تجاوز الفشل أو إضافة/إزالة المنطقة.

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

كيفية توسيع نطاق وحدات الطلب/ الثانية دون تغيير تخطيط القسم

الخطوة 1: ابحث عن العدد الحالي للأقسام المادية.

انتقل إلى أفكار > معدل النقل > معدل استهلاك وحدة الطلب (RU) (٪) بواسطة PartitionKeyRangeID . حساب عدد مميز من PartitionKeyRangeIds.

احسب العدد المميز لـ PartitionKeyRangeIds في استهلاك RU العادي (٪) حسب مخطط PartitionKeyRangeID

إشعار

سيعرض المخطط فقط 50 PartitionKeyRangeIds كحد أقصى. إذا كان المورد الخاص بك يحتوي على أكثر من 50، فيمكنك استخدام Azure Cosmos DB REST API لحساب العدد الإجمالي للأقسام.

يتم تعيين كل PartitionKeyRangeId إلى قسم مادي واحد ويتم تعيينه للاحتفاظ بالبيانات لمجموعة من قيم التجزئة الممكنة.

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

الخطوة 2: احسب الحد الأقصى الافتراضي لمعدل النقل

أعلى وحدات الطلب/ الثانية التي يمكنك التحجيم إليها دون تشغيل Azure Cosmos DB لتقسيم الأقسام يساوي Current number of physical partitions * 10,000 RU/s. يمكنك الحصول على هذه القيمة من موفر موارد Azure Cosmos DB. تنفيذ طلب GET على قاعدة البيانات أو كائنات إعداد معدل نقل الحاوية واسترداد الخاصية instantMaximumThroughput . تتوفر هذه القيمة أيضا في صفحة المقياس والإعدادات لقاعدة البيانات أو الحاوية في المدخل.

مثال

لنفترض أن لدينا حاوية حالية بها خمسة أقسام مادية و30000 وحدات الطلب / ثانية من معدل النقل اليدوي المتوفر. يمكننا زيادة وحدات الطلب/ الثانية إلى 5 * 10،000 وحدات الطلب/ الثانية = 50،000 وحدات الطلب/ الثانية على الفور. وبالمثل، إذا كان لدينا حاوية ذات مقياس تلقائي بحد أقصى RU/s of 30,000 RU/s (مقاييس بين 3000 - 30,000 RU/s), يمكننا زيادة الحد الأقصى RU/s إلى 50,000 RU/s على الفور (بين المقاييس 5000 - 50,000 RU/s).

تلميح

إذا كنت تقوم بتوسيع نطاق وحدات الطلب/ الثانية للاستجابة لمعدل الطلب استثناءات كبيرة جداً (429s)، فمن المستحسن أولاً زيادة وحدات الطلب/ الثانية إلى أعلى وحدات الطلب/ الثانية التي يدعمها تخطيط القسم المادي الحالي وتقييم ما إذا كان RU الجديد / s كافية قبل زيادة أخرى.

كيفية ضمان التوزيع المتساوي للبيانات أثناء القياس غير المتزامن

خلفية

عندما تزيد وحدات الطلب في الثانية عن العدد الحالي للأقسام المادية * 10000 وحدة طلب في الثانية، تقسّم قاعدة بيانات Azure Cosmos الأقسام الموجودة حتى يصبح العدد الجديد للأقسام = ROUNDUP(requested RU/s / 10,000 RU/s). أثناء الانقسام، يتم تقسيم الأقسام الأصلية إلى قسمين أطفال.

على سبيل المثال، لنفترض أن لدينا حاوية بها ثلاثة أقسام مادية و30000 وحدة طلب/ الثانية من معدل النقل اليدوي المتوفر. إذا قمنا بزيادة معدل النقل إلى 45000 وحدات الطلب/ الثانية، فسيقوم Azure Cosmos DB بتقسيم اثنين من الأقسام المادية الموجودة بحيث يكون هناك إجمالي ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 أقسام فعلية.

إشعار

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

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

لمعرفة السبب، لنأخذ مثالاً حيث لدينا حاوية حالية بها قسمان ماديان، 20,000 وحدات الطلب/ الثانية، و80 جيجابايت من البيانات.

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

بالإضافة إلى ذلك، يقوم Azure Cosmos DB بتوزيع وحدات الطلب/ الثانية بالتساوي عبر جميع الأقسام المادية. نتيجة لذلك، يحتوي كل قسم مادي على 10000 وحدة وحدات الطلب/ الثانية و50٪ (40 جيجابايت) من إجمالي البيانات. يوضح الرسم البياني التالي حالتنا الحالية.

قسمان من PartitionKeyRangeIds، يحتوي كل منهما على 10000 وحدة وحدات الطلب/ الثانية، و40 غيغابايت، و50٪ من إجمالي مساحة المفاتيح

الآن، لنفترض أننا نريد زيادة وحدات الطلب/ الثانية الخاصة بنا من 20000 وحدات الطلب/ الثانية إلى 30000 وحدات الطلب/ الثانية.

إذا قمنا ببساطة بزيادة وحدات الطلب/ الثانية إلى 30000 وحدات الطلب/ الثانية، فسيتم تقسيم قسم واحد فقط. بعد الانقسام، سيكون لدينا:

  • قسم واحد يحتوي على 50٪ من البيانات (لم يتم تقسيم هذا القسم)
  • قسمان يحتوي كل منهما على 25٪ من البيانات (هذه هي الأقسام الفرعية الناتجة من الأصل الذي تم تقسيمه)

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

في الرسم التخطيطي التالي، نرى أن القسمين 3 و4 (الأقسام الفرعية للقسم 2) يحتوي كل منهما على 10000 وحدة وحدات الطلب/ الثانية لخدمة طلبات 20 جيجابايت من البيانات، بينما يحتوي القسم 1 على 10000 وحدات الطلب/ الثانية لخدمة الطلبات بضعف المبلغ من البيانات (40 جيجا بايت).

بعد الانقسام، هناك 3 PartitionKeyRangeIds، لكل منها 10000 وحدات الطلب/ الثانية. ومع ذلك، يحتوي أحد PartitionKeyRangeIds على 50٪ من إجمالي مساحة المفاتيح (40 جيجابايت)، بينما يمتلك اثنان من PartitionKeyRangeIds 25٪ من إجمالي مساحة المفاتيح (20 جيجابايت)

للحفاظ على توزيع تخزين متساوٍ، يمكننا أولاً توسيع نطاق وحدات الطلب/ الثانية الخاص بنا لضمان تقسيم كل قسم. بعد ذلك، يمكننا خفض وحدات الطلب/ الثانية الخاصة بنا إلى الحالة المطلوبة.

لذا، إذا بدأنا بقسمين ماديين، لضمان أن الأقسام بعد الانقسام، نحتاج إلى تعيين وحدات الطلب/ الثانية بحيث ينتهي بنا الأمر بأربعة أقسام مادية. لتحقيق ذلك، سنقوم أولاً بتعيين وحدات الطلب/ الثانية = 4 * 10،000 وحدات الطلب/ الثانية لكل قسم = 40،000 وحدات الطلب/ الثانية. بعد ذلك، بعد اكتمال الانقسام، يمكننا خفض وحدات الطلب/ الثانية الخاصة بنا إلى 30000 وحدات الطلب/ الثانية.

نتيجة لذلك، نرى في الرسم التخطيطي التالي أن كل قسم مادي يحصل على 30000 وحدات الطلب/ الثانية / 4 = 7500 وحدات الطلب/ الثانية لخدمة طلبات 20 جيجا بايت من البيانات. بشكل عام، نحافظ على التوزيع حتى التخزين وطلب عبر أقسام.

بعد اكتمال الانقسام وخفض وحدات الطلب/ الثانية من 40،000 وحدات الطلب/ الثانية إلى 30،000 وحدات الطلب/ الثانية، هناك 4 PartitionKeyRangeIds، لكل منها 7500 وحدة RU / ثانية و25٪ من إجمالي مساحة المفاتيح (20 جيجابايت)

صيغة عامة

الخطوة 1: قم بزيادة وحدات الطلب/ الثانية لضمان تقسيم جميع الأقسام بالتساوي

بشكل عام، إذا كان لديك عدد بداية من الأقسام المادية P، وتريد تعيين وحدات الطلب/ الثانية المطلوبة S:

قم بزيادة وحدات الطلب/ الثانية الخاصة بك إلى: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). هذا يعطي أقرب وحدات الطلب/ الثانية إلى القيمة المطلوبة التي ستضمن تقسيم جميع الأقسام بالتساوي.

إشعار

عند زيادة وحدات الطلب/ الثانية لقاعدة بيانات أو حاوية، يمكن أن يؤثر ذلك على الحد الأدنى من وحدات الطلب/ الثانية الذي يمكنك خفضه في المستقبل. عادة ما يكون الحد الأدنى من وحدات الطلب/الثانية مساويا ل MAX(400 RU/s، والتخزين الحالي بالجيجابايت * 1 RU/s، وأعلى وحدة طلب/ثانية تم توفيرها / 100). على سبيل المثال، إذا كانت أعلى وحدة RU / ثانية قمت بالقياس إليها هي 100،000 وحدات الطلب/ الثانية، فإن أقل وحدات الطلب/ الثانية يمكنك تعيينها في المستقبل هو 1000 وحدات الطلب/ الثانية. تعرف على المزيد حول الحد الأدنى من وحدات الطلب/ الثانية .

الخطوة 2: أنزل وحدات الطلب/ الثانية إلى وحدات الطلب/ الثانية المطلوب

على سبيل المثال، لنفترض أن لدينا خمسة أقسام مادية، 50000 RU / ثانية ونريد التوسع إلى 150000 وحدات الطلب/ الثانية. يجب أولاً تعيين: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200000 وحدات الطلب/ الثانية، ثم خفضها إلى 150000 وحدات الطلب/ الثانية.

عندما قمنا بتحجيم ما يصل إلى 20,0000 وحدات الطلب/ الثانية، فإن أقل وحدة وحدات الطلب/ الثانية يدوية يمكننا الآن تعيينها في المستقبل هي 2000 وحدة طلب/ الثانية. أدنى حد أقصى للمقياس التلقائي وحدات الطلب/ الثانية يمكننا تعيينه هو 20,000 وحدة طلب/ الثانية (أحجام بين 2000 – 20,000 وحدة طلب / ثانية). نظراً لأن وحدات الطلب/ الثانية المستهدفة هي 150.000 وحدات الطلب/ الثانية، فإننا لا نتأثر بالحد الأدنى من وحدات الطلب/ الثانية.

كيفية تحسين وحدات الطلب/ الثانية لاستيعاب البيانات الكبيرة

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

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

الخطوة 1: راجع اختيار مفتاح القسم

اتبع أفضل الممارسات لاختيار مفتاح قسم لضمان التوزيع المتساوي لحجم الطلب والتخزين بعد الترحيل.

الخطوة 2: احسب عدد الأقسام المادية التي ستحتاج إليها

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

يمكن أن يحتفظ كل قسم فعلي بحد أقصى 50 غيغابايت من التخزين (30 غيغابايت لواجهة برمجة التطبيقات ل Cassandra). تعتمد القيمة التي يجب أن تختارها لـ Target data per physical partition in GB على مدى التعبئة الكاملة التي تريدها للأقسام المادية ومقدار السعة التخزينية التي تتوقع زيادة حجمها بعد الترحيل.

على سبيل المثال، إذا كنت تتوقع أن يستمر التخزين في النمو، فيمكنك اختيار تعيين القيمة على 30 جيجابايت. بافتراض أنك اخترت مفتاح تقسيم جيد يوزع التخزين بالتساوي، سيكون كل قسم ممتلئاً بنسبة 60٪ تقريباً (30 جيجا بايت من 50 جيجا بايت). أثناء كتابة البيانات المستقبلية، يمكن تخزينها على المجموعة الحالية من الأقسام المادية، دون مطالبة الخدمة بإضافة المزيد من الأقسام المادية على الفور.

في المقابل، إذا كنت تعتقد أن مساحة التخزين لن تنمو بشكل ملحوظ بعد الترحيل، فيمكنك اختيار تعيين القيمة أعلى، على سبيل المثال 45 جيجابايت. هذا يعني أن كل قسم سيكون ممتلئاً بنسبة 90٪ تقريباً (45 جيجا بايت من 50 جيجا بايت). يقلل هذا من عدد الأقسام المادية التي تنتشر بياناتك عبرها، ما يعني أن كل قسم مادي يمكن أن يحصل على جزء أكبر من إجمالي وحدات الطلب/ الثانية المتوفرة.

الخطوة 3: حساب عدد وحدات الطلب/ الثانية للبدء بها لجميع الأقسام

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition.

لنبدأ بمثال بعدد عشوائي من وحدات الطلب/ الثانية المستهدفة لكل قسم مادي.

  • Initial throughput per physical partition = 10,000 وحدة طلب/ثانية لكل قسم فعلي عند استخدام قواعد بيانات معدل النقل أو التحجيم التلقائي المشترك
  • Initial throughput per physical partition = 6000 وحدة طلب/ثانية لكل قسم فعلي عند استخدام معدل النقل اليدوي

مثال

لنفترض أن لدينا 1 تيرابايت (1000 جيجابايت) من البيانات التي نخطط لاستيعابها ونريد استخدام معدل النقل اليدوي. تبلغ سعة كل قسم مادي في Azure Cosmos DB 50 جيجابايت. لنفترض أننا نهدف إلى حزم الأقسام بحيث تكون ممتلئة بنسبة 80٪ (40 جيجابايت)، ما يترك لنا مجالاً للنمو في المستقبل.

هذا يعني أنه بالنسبة إلى 1 تيرابايت من البيانات، سنحتاج إلى 1000 جيجابايت / 40 جيجابايت = 25 قسماً فعلياً. لضمان حصولنا على 25 قسماً مادياً، إذا كنا نستخدم معدل نقل يدوية، فنحن نقدم أولاً 25 * 6000 وحدات الطلب/ الثانية = 150.000 وحدات الطلب/ الثانية. بعد ذلك، بعد إنشاء الحاوية، للمساعدة في زيادة سرعة الابتلاع، نزيد وحدات الطلب/ الثانية إلى 250.000 وحدات الطلب/ الثانية قبل بدء الابتلاع (يحدث على الفور لأن لدينا بالفعل 25 قسماً مادياً). يسمح هذا لكل قسم بالحصول على الحد الأقصى وهو 10000 وحدات الطلب/ الثانية.

إذا كنا نستخدم معدل نقل تلقائي أو قاعدة بيانات نقل مشتركة، للحصول على 25 قسماً مادياً، فسنقوم أولاً بتوفير 25 * 10،000 وحدات الطلب/ الثانية = 250،000 وحدات الطلب/ الثانية. نظراً لأننا بالفعل في أعلى وحدات الطلب/ الثانية التي يمكن دعمها بـ 25 قسماً مادياً، فلن نزيد من وحدات الطلب/ الثانية المتوفرة لدينا قبل الابتلاع.

من الناحية النظرية، مع 250.000 وحدة طلب/ الثانية و1 تيرابايت من البيانات، إذا افترضنا مستندات 1 kb و10 RUs المطلوبة للكتابة، فيمكن أن يكتمل الاستيعاب نظرياً في: 1000 GB * (1،000،000 kb / 1 GB) * (مستند واحد / 1 كيلو بايت) * (10 RU / مستند) * (1 ثانية / 250000 رو) * (ساعة واحدة / 3600 ثانية) = 11.1 ساعة.

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

بمجرد انتهاء الترحيل، يمكننا خفض وحدات الطلب/ الثانية أو تمكين مقياس تلقائي حسب الحاجة.

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