التقسيم في Azure Cosmos DB ل Apache Cassandra

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

توضح هذه المقالة كيفية عمل التقسيم في Azure Cosmos DB ل Apache Cassandra.

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

من منظور المطور، يتصرف التقسيم بنفس الطريقة ل Azure Cosmos DB ل Apache Cassandra كما هو الحال في Apache Cassandra الأصلي. ومع ذلك، هناك بعض الاختلافات وراء الكواليس.

الاختلافات الرئيسية بين Apache Cassandra وCassandra API

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

توصي Apache Cassandra بحد 100 ميغا بايت لحجم البيانات التي يمكن تخزينها في قسم. تسمح واجهة برمجة التطبيقات ل Cassandra ل Azure Cosmos DB بسعة تصل إلى 20 غيغابايت لكل قسم منطقي، وما يصل إلى 30 غيغابايت من البيانات لكل قسم فعلي. في Azure Cosmos DB، على عكس Apache Cassandra، يتم التعبير عن سعة الحوسبة المتاحة في القسم الفعلي باستخدام مقياس واحد يسمى وحدات الطلب، والذي يسمح لك بالتفكير في حمل العمل الخاص بك من حيث الطلبات (القراءة أو الكتابة) في الثانية، بدلاً من الذاكرة الأساسية أو الذاكرة أو IOPS. وهذا يمكن أن يجعل تخطيط القدرات أكثر مباشرة إلى الأمام، بمجرد فهم تكلفة كل طلب. يمكن أن يحتوي كل قسم فعلي على ما يصل إلى 10000 وحدة طلب حسابية متاحة له. يمكنك معرفة المزيد حول خيارات قابلية التوسع من خلال قراءة مقالتنا حول المقياس المرن في واجهة برمجة التطبيقات ل Cassandra.

في Azure Cosmos DB، يتكون كل قسم فعلي من مجموعة من النسخ المتماثلة، تعرف أيضا باسم مجموعات النسخ المتماثلة، مع ما لا يقل عن 4 نسخ متماثلة لكل قسم. هذا على عكس Apache Cassandra، حيث يكون تعيين عامل النسخ المتماثل 1 ممكناً. ومع ذلك، فهذا يؤدي إلى توفر منخفض إذا انخفضت العقدة الوحيدة مع البيانات. في واجهة برمجة التطبيقات ل Cassandra هناك دائما عامل النسخ المتماثل 4 (حصة 3). يقوم Azure Cosmos DB بإدارة مجموعات النسخ المتماثلة تلقائياً، في حين تحتاج هذه المجموعات إلى الحفاظ عليها باستخدام أدوات مختلفة في Apache Cassandra.

لدى Apache Cassandra مفهوم الرموز المميزة، وهي تجزئة مفاتيح التقسيم. تستند الرموز المميزة إلى تجزئة murmur3 بسعة 64 بايت، مع قيم تتراوح من -2^63 إلى -2^63-1. يشار إلى هذا النطاق عادة باسم "حلقة الرمز المميز" في Apache Cassandra. يتم توزيع حلقة الرمز المميز في نطاقات رمزية، وتنقسم هذه النطاقات بين العقد الموجودة في مجموعة Apache Cassandra الأصلية. يتم تنفيذ التقسيم ل Azure Cosmos DB بطريقة مشابهة، إلا أنه يستخدم خوارزمية تجزئة مختلفة، ويحتوي على حلقة رمز مميز داخلي أكبر. ومع ذلك، فإننا نكشف خارجياً نفس نطاق الرمز المميز مثل Apache Cassandra، أي -2^63 إلى -2^63-1.

المفتاح الأساسي

يجب أن تحتوي جميع الجداول في واجهة برمجة التطبيقات ل Cassandra على primary key تعريف. يتم عرض بنية المفتاح الأساسي أدناه:

column_name cql_type_definition PRIMARY KEY

لنفترض أننا نريد إنشاء جدول مستخدم يخزن الرسائل للمستخدمين المختلفين:

CREATE TABLE uprofile.user ( 
   id UUID PRIMARY KEY, 
   user text,  
   message text);

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

المفتاح الأساسي المُركّب

يتضمن Apache Cassandra أيضاً مفهوم compound keys. يتكون المُركّب primary key من أكثر من عمود؛ والعمود الأول هو partition key، وأي أعمدة إضافية هي clustering keys. يتم عرض compound primary key أدناه:

PRIMARY KEY (partition_key_column_name, clustering_column_name [, ...])

لنفترض أننا نريد تغيير التصميم أعلاه ونجعل من الممكن استرداد الرسائل لمستخدم معين بكفاءة:

CREATE TABLE uprofile.user (
   user text,  
   id int, 
   message text, 
   PRIMARY KEY (user, id));

في هذا التصميم، نحن الآن نُعرّف user كمفتاح التقسيم، وid كمفتاح التجميع. يمكنك تعريف العديد من مفاتيح التجميع كما يحلو لك، ولكن يجب أن تكون كل قيمة (أو مجموعة من القيم) لمفتاح التجميع فريدة من أجل أن ينتج عن ذلك إضافة سجلات متعددة إلى نفس القسم، على سبيل المثال:

insert into uprofile.user (user, id, message) values ('theo', 1, 'hello');
insert into uprofile.user (user, id, message) values ('theo', 2, 'hello again');

عند إرجاع البيانات، يتم فرزها بواسطة مفتاح التجميع، كما هو متوقع في Apache Cassandra:

تحذير

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

CREATE INDEX ON uprofile.user (user);

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

باستخدام البيانات التي تم تصميمها بهذه الطريقة، يمكن تعيين سجلات متعددة لكل قسم، مجمعة حسب المستخدم. وبالتالي يمكننا إصدار استعلام يتم توجيهه بكفاءة من قِبل partition key (في هذه الحالة user) للحصول على جميع الرسائل لمستخدم معين.

مفتاح التقسيم المركب

تعمل مفاتيح التقسيم المُركّبة بشكل أساسي بنفس طريقة عمل المفاتيح المُركّبة، باستثناء أنه يمكنك تحديد عدة أعمدة كمفتاح تقسيم مُركّب. تظهر بنية مفاتيح التقسيم المُركّبة أدناه:

PRIMARY KEY (
   (partition_key_column_name[, ...]), 
    clustering_column_name [, ...]);

على سبيل المثال، يمكن أن يكون لديك ما يلي، حيث تركيبة فريدة من نوعها من firstname وlastname لتشكيل مفتاح التقسيم، ويكون id هو مفتاح التجميع:

CREATE TABLE uprofile.user ( 
   firstname text, 
   lastname text,
   id int,  
   message text, 
   PRIMARY KEY ((firstname, lastname), id) );

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

• تعرف على التقسيم والتحجيم الأفقي في Azure Cosmos DB.
• اطلع على معلومات حول معدل النقل المقدم في Azure Cosmos DB.
• تعرف على التوزيع العالمي في Azure Cosmos DB.