مشاركة عبر

توسيع نطاق قاعدة بيانات Azure Cosmos لحساب Apache Cassandra بمرونة

  • مقالة

ينطبق على: كاساندرا

هناك مجموعة متنوعة من الخيارات لاستكشاف الطبيعة المرنة ل Azure Cosmos DB ل Apache Cassandra. لفهم كيفية توسيع النطاق بشكل فعال في قاعدة بيانات Azure Cosmos من المهم فهم كيفية توفير الكمية المناسبة من وحدات الطلب (RU/s) لحساب متطلبات الأداء في النظام الخاص بك. لمعرفة المزيد حول وحدات الطلب، راجع مقالة وحدات الطلب.

بالنسبة لواجهة برمجة التطبيقات ل Cassandra، يمكنك استرداد رسوم وحدة الطلب للاستعلامات الفردية باستخدام .NET وJava SDKs. وهذا مفيد في تحديد مقدار وحدة/وحدات الطلب الذي ستحتاج توفيره في الخدمة.

عمليات قاعدة البيانات تستهلك Request Units

الحد من معدل المعالجة (429 خطأ)

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

إذا كان النظام غير حساس إلى زمن الانتقال، قد يكون كافيا لمعالجة الحد من معدل النقل باستخدام إعادة المحاولات. انظر عينات تعليمة Java البرمجيةللإصدار 3والإصدار 4 من برامج تشغيل Apache Cassandra Java لكيفية التعامل مع تقييد المعدل بشفافية. تنفذ هذه العينات إصدار مخصص من نهج إعادة محاولة Cassandra الافتراضي في Java. يمكنك أيضا استخدام ملحق Spark لمعالجة تحديد النسبة. عند استخدام Spark، تأكد من اتباع إرشاداتنا حول تحسين تكوين معدل النقل لموصل Spark.

إدارة التحجيم

إذا كنت بحاجة إلى تقليل زمن الانتقال، فهناك مجموعة من الخيارات لإدارة النطاق وتوفير معدل النقل (RUs) في واجهة برمجة التطبيقات ل Cassandra:

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

استخدام مدخل Microsoft Azure

يمكنك توسيع نطاق الموارد في Azure Cosmos DB لحساب Apache Cassandra باستخدام مدخل Microsoft Azure. لمعرفة المزيد، راجع المقالة حول توفير معدل النقل على الحاويات وقواعد البيانات. توضح هذه المقالة المزايا النسبية لإعداد معدل النقل في قاعدة البيانات أو مستوى الحاوية في مدخل Azure. يتم تعيين مصطلحي "database" و"container" المذكورين في هذه المقالات إلى "keyspace" و"table" على التوالي لواجهة برمجة التطبيقات ل Cassandra.

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

استخدام وحدة التحكم

توفر واجهة برمجة التطبيقات قاعدة بيانات Azure Cosmos لـ Cassandra القدرة على ضبط معدل النقل برمجيا باستخدام ميزاتنا المختلفة لوحدة التحكم. راجع مقالات إدارة موارد AzureوPowerShellو Azure CLI للإطلاع على إرشادات وعينات.

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

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

استخدام استعلامات CQL مع SDK محدد

يمكنك تحجيم النظام بشكل حيوي مع التعليمات البرمجية بتنفيذ أوامر CQL ALTER لقاعدة البيانات أو الحاوية المحددة.

ميزة هذا النهج هو أنه يسمح لك للاستجابة لاحتياجات التحجيم بشكل حيوي وبطريقة مخصصة تناسب التطبيق الخاص بك. مع هذا النهج، لا يزال بإمكانك الاستفادة من رسوم وحدة/وحدات الطلب القياسية والأسعار. إذا كانت احتياجات تحجيم النظام الخاص بك متوقعة في الغالب (حوالي 70٪ أو أكثر)، فقد يكون استخدام SDK مع CQL طريقة أكثر فعالية من حيث التكلفة للتحجيم التلقائي من استخدام التحجيم التلقائي. وعيب هذا النهج هو أنه يمكن أن يكون معقدا جدا لتنفيذ عمليات إعادة المحاولة في حين أن الحد من معدل قد يزيد من زمن الانتقال.

استخدام معدل النقل المقدم للتحجيم التلقائي

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

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

لتعيين أو تغيير الحد الأقصى (وحدات طلب) لمعدل النقل للتحجيم التلقائي باستخدام CQL، استخدم ما يلي (استبدال اسم مساحة المفتاح/الجدول وفقا لذلك):

# to set max throughput (RUs) for autoscale at keyspace level:
create keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at keyspace level:
alter keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=4000;

# to set max throughput (RUs) for autoscale at table level:
create table <keyspace name>.<table name> (pk int PRIMARY KEY, ck int) WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at table level:
alter table <keyspace name>.<table name> WITH cosmosdb_autoscale_max_throughput=4000;

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