تصميم جداول قابلة للتوسع ذات أداء
تلميح
ينطبق المحتوى الموجود في هذه المقالة على تخزين Azure Table الأصلي. ومع ذلك، تنطبق نفس المفاهيم على Azure Cosmos DB الأحدث للجدول، والذي يوفر أداء وتوافرا أعلى وتوزيعا عالميا وفهرسات ثانوية تلقائية. وهو متوفر أيضًا في وضع عدم وجود خادم قائم على الاستهلاك. هناك بعض اختلافات الميزات بين Table API في Azure Cosmos DB وتخزين Azure Table. لمزيد من المعلومات، راجع Azure Cosmos DB for Table. لتسهيل التطوير، نقدم الآن Azure Tables SDK موحدا يمكن استخدامه لاستهداف كل من تخزين Azure Table وAzure Cosmos DB للجدول.
لتصميم جداول قابلة للتطوير والأداء، يجب مراعاة عوامل مثل الأداء وقابلية التوسع والتكلفة. إذا كنت قد قمت مسبقًا بتصميم مخططات لقواعد البيانات العلائقية، فإن هذه الاعتبارات مألوفة، ولكن على الرغم من وجود بعض أوجه التشابه بين نموذج تخزين خدمة Azure Table والنماذج العلائقية، إلا أن هناك أيضًا اختلافات مهمة. عادة ما تؤدي هذه الاختلافات إلى تصميمات مختلفة قد تبدو غير بديهية أو خاطئة لشخص على دراية بقواعد البيانات العلائقية، ولكنها تكون منطقية إذا كنت تصمم لمخزن مفتاح / قيمة NoSQL مثل خدمة Azure Table. تعكس العديد من اختلافات التصميم الخاصة بك حقيقة أن خدمة Table مصممة لدعم التطبيقات على نطاق السحابة التي يمكن أن تحتوي على مليارات الكيانات (أو الصفوف في مصطلحات قاعدة البيانات العلائقية) من البيانات أو لمجموعات البيانات التي يجب أن تدعم أحجام المعاملات الكبيرة. لذلك، يجب أن تفكر بشكل مختلف حول كيفية تخزين بياناتك وفهم كيفية عمل خدمة Table. يمكن لمخزن بيانات NoSQL المصمم بشكل جيد تمكين الحل الخاص بك من التوسع بشكل أكبر بكثير وبتكلفة أقل من الحل الذي يستخدم قاعدة بيانات علائقية. يساعدك هذا الدليل في هذه المواضيع.
حول خدمة Azure Table
يسلط هذا القسم الضوء على بعض الميزات الرئيسية لخدمة Table ذات الصلة بشكل خاص بالتصميم من أجل الأداء وقابلية التوسع. إذا كنت مستخدما جديدا ل Azure Storage وخدمة Table، فاقرأ أولا بدء استخدام Azure Table Storage باستخدام .NET قبل قراءة الجزء المتبقي من هذه المقالة. على الرغم من أن تركيز هذا الدليل ينصب على خدمة الجدول، إلا أنه يتضمن مناقشة خدمات قائمة انتظار Azure وBlob، وكيفية استخدامها مع خدمة الجدول.
ما هي خدمة الجدول؟ كما قد تتوقع من الاسم، تستخدم خدمة الجدول تنسيق جدولي لتخزين البيانات. في المصطلحات القياسية، يمثل كل صف من صفوف الجدول كيانًا، وتخزن الأعمدة الخصائص المختلفة لهذا الكيان. يحتوي كل كيان على زوج من المفاتيح لتعريفه بشكل فريد، وعمود طابع زمني تستخدمه خدمة الجدول لتعقب آخر تحديث للكيان. يتم تطبيق الطابع الزمني تلقائيًا، ولا يمكنك الكتابة فوق الطابع الزمني يدويًا بقيمة عشوائية. تستخدم خدمة الجدول هذا الطابع الزمني الأخير المعدل (LMT) لإدارة التزامن المتفائل.
إشعار
تقوم عمليات واجهة برمجة تطبيقات REST لخدمة الجدول أيضًا بإرجاع قيمة ETag التي تستمدها من LMT. تستخدم هذه الوثيقة المصطلحين ETag وLMT بالتبادل لأنهما تشيران إلى نفس البيانات الأساسية.
يوضح المثال التالي تصميم جدول بسيط لتخزين كيانات الموظفين والقسم. تستند العديد من الأمثلة الموضحة لاحقًا في هذا الدليل إلى هذا التصميم البسيط.
| PartitionKey | RowKey | الطابع الزمني | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | الإدارة | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
حتى الآن، تبدو هذه البيانات مشابهة لجدول في قاعدة بيانات علائقية مع الاختلافات الرئيسية هي الأعمدة الإلزامية، والقدرة على تخزين أنواع كيانات متعددة في نفس الجدول. أيضًا، تحتوي كل خاصية من الخصائص المعرفة من قبل المستخدم مثل FirstName أو Age على نوع بيانات، مثل عدد صحيح أو سلسلة، تمامًا مثل عمود في قاعدة بيانات علائقية. على الرغم من أنه على عكس قاعدة البيانات العلائقية، فإن الطبيعة الخالية من المخطط لخدمة الجدول تعني أن الخاصية لا تحتاج إلى نفس نوع البيانات على كل كيان. لتخزين أنواع البيانات المعقدة في خاصية واحدة، يجب عليك استخدام تنسيق متسلسل مثل JSON أو XML. لمزيد من المعلومات حول خدمة الجدول مثل أنواع البيانات المعتمدة والنطاقات الزمنية المعتمدة وقواعد التسمية وقيود الحجم، راجع فهم نموذج بيانات خدمة الجدول.
اختيارك لـPartitionKey وRowKey أمر أساسي لتصميم الجدول الجيد. يجب أن يحتوي كل كيان مخزن في جدول على مزيج فريد من PartitionKey وRowKey. كما هو الحال مع المفاتيح الموجودة في جدول قاعدة بيانات علائقية، تتم فهرسة قيم PartitionKey وRowKey لإنشاء فهرس متفاوت المسافات لتمكين عمليات البحث السريعة. ومع ذلك، لا تقوم خدمة الجدول بإنشاء أية فهارس ثانوية، لذا فإن PartitionKey وRowKey هما الخاصيتان المفهرستان الوحيدتان. توضح بعض الأنماط الموضحة في أنماط تصميم الجدول كيف يمكنك التغلب على هذا القيد الظاهر.
يتكون الجدول من قسم واحد أو أكثر، وستكون العديد من قرارات التصميم التي تتخذها حول اختيار PartitionKey وRowKey المناسبين لتحسين الحل الخاص بك. قد يتكون الحل من جدول واحد يحتوي على جميع الكيانات المنظمة في أقسام، ولكن عادة ما يحتوي الحل على جداول متعددة. تساعدك الجداول على تنظيم كياناتك بشكل منطقي، وتساعدك على إدارة الوصول إلى البيانات باستخدام قوائم التحكم في الوصول، ويمكنك إسقاط جدول بأكمله باستخدام عملية تخزين واحدة.
أقسام الجدول
يحدد اسم الحساب واسم الجدول وPartitionKey معًا القسم داخل خدمة التخزين حيث تقوم خدمة الجدول بتخزين الكيان. بالإضافة إلى كونها جزءًا من مخطط العنونة للكيانات، تحدد الأقسام نطاقًا للمعاملات (انظر معاملات مجموعة الكيانات أدناه)، وتشكل الأساس لكيفية قياس خدمة الجدول. لمزيد من المعلومات حول الأقسام، راجع قائمة التحقق من الأداء وقابلية التوسع لتخزين الجدول.
في خدمة الجدول، تقوم العقدة الفردية بخدمة قسم كامل واحد أو أكثر، ويتم قياس الخدمة بواسطة أقسام موازنة التحميل ديناميكيًا عبر العقد. إذا كانت العقدة قيد التحميل، فيمكن لخدمة الجدول تقسيم نطاق الأقسام التي تخدمها تلك العقدة إلى عقد مختلفة؛ عندما تهدأ حركة المرور، يمكن للخدمة دمج نطاقات القسم من العقد الهادئة مرة أخرى إلى عقدة واحدة.
لمزيد من المعلومات حول التفاصيل الداخلية لخدمة الجدول، وعلى وجه الخصوص كيفية إدارة الخدمة للأقسام، راجع ورقة Microsoft Azure Storage: خدمة تخزين سحابي متوفرة للغاية مع اتساق قوي.
عمليات مجموعة الكيانات
في خدمة الجدول، تعد معاملات مجموعة الكيانات (EGTs) الآلية المضمنة الوحيدة لإجراء التحديثات الذرية عبر كيانات متعددة. يشار أحيانًا إلى EGTs أيضا باسم المعاملات الدفعية. يمكن أن تعمل EGTs فقط على الكيانات المخزنة في نفس القسم (أي مشاركة نفس مفتاح القسم في جدول معين). لذلك في أي وقت تحتاج فيه إلى سلوك المعاملات الذرية عبر كيانات متعددة، يجب عليك التأكد من أن هذه الكيانات في نفس القسم. غالبًا ما يكون هذا سببًا للاحتفاظ بأنواع كيانات متعددة في نفس الجدول (والقسم) وعدم استخدام جداول متعددة لأنواع كيانات مختلفة. يمكن أن تعمل EGT واحدة على 100 كيان على الأكثر. إذا قمت بتقديم العديد من EGTs المتزامنة للمعالجة، فمن المهم التأكد من أن EGTs هذه لا تعمل على الكيانات الشائعة عبر EGTs؛ خلاف ذلك، يمكن تأخير المعالجة.
تقدم EGTs أيضًا مقايضة محتملة لك لتقييمها في تصميمك. أي أن استخدام المزيد من الأقسام يزيد من قابلية تطوير تطبيقك، لأن Azure لديه المزيد من الفرص لطلبات موازنة التحميل عبر العقد. ولكن استخدام المزيد من الأقسام قد يحد من قدرة التطبيق الخاص بك على إجراء المعاملات الذرية والحفاظ على اتساق قوي لبياناتك. علاوة على ذلك، هناك أهداف محددة للتوسع على مستوى القسم قد تحد من معدل نقل المعاملات التي يمكنك توقعها لعقدة واحدة. لمزيد من المعلومات حول أهداف قابلية التوسع لحسابات التخزين القياسية Azure، راجع أهداف قابلية التوسع لحسابات التخزين القياسية. للحصول على مزيد من المعلومات عن أهداف قابلية التوسع لخدمة Table، راجع أهداف قابلية التوسع والأداء لمخزن Table.
اعتبارات السعة
يصف الجدول التالي السعة وقابلية التوسع وأهداف الأداء لتخزين الجدول.
| Resource | استهداف |
|---|---|
| عدد الجداول في حساب تخزين Azure | يقتصر فقط على سعة حساب التخزين |
| عدد الأقسام في الجدول | يقتصر فقط على سعة حساب التخزين |
| عدد الكيانات في القسم | يقتصر فقط على سعة حساب التخزين |
| الحجم الأقصى لجدول واحد | 500 تيرابيت |
| الحجم الأقصى لكيان واحد، بما في ذلك جميع قيم الخصائص | 1 ميبيبايت |
| الحد الأقصى لعدد الخصائص في كيان جدول | 255 (بما في ذلك خصائص النظام الثلاثة، PartitionKey وRowKey والطابع الزمني) |
| الحجم الإجمالي الأقصى لخاصية فردية في كيان | يختلف حسب نوع الخاصية. للحصول على مزيدٍ من المعلومات، راجع أنواع الخصائص في فهم نموذج بيانات خدمة الجدول. |
| حجم PartitionKey | سلسلة يصل حجمها إلى 1024 حرفا |
| حجم RowKey | سلسلة يصل حجمها إلى 1024 حرفا |
| حجم معاملة مجموعة الكيانات | يمكن أن تشتمل المعاملة على 100 كيان على الأكثر ويجب أن يكون حجم الحمولة أقل من 4 ميبيبايت. يمكن أن تتضمن معاملة مجموعة الكيانات تحديثًا لكيان مرة واحدة فقط. |
| الحد الأقصى لعدد نُهج الوصول المخزنة لكل جدول | 5 |
| معدل الطلب الأقصى لكل حساب تخزين | 20,000 معاملة في الثانية، والتي تفترض حجم كيان 1 كيبيبايت |
| سرعة النقل المستهدفة لقسم جدول واحد (كيانات بحجم 1 كيبيبايت) | ما يصل إلى 2,000 كيان في الثانية |
اعتبارات التكلفة
تخزين الجدول غير مكلف نسبيًا، ولكن يجب عليك تضمين تقديرات التكلفة لكل من استخدام السعة وكمية المعاملات كجزء من تقييمك لأي حل خدمة جدول. ومع ذلك، في العديد من السيناريوهات، يعد تخزين البيانات غير الطبيعية أو المكررة من أجل تحسين أداء الحل الخاص بك أو قابليته للتوسع نهجًا صالحًا. لمزيد من المعلومات حول الأسعار، راجع أسعار Azure Storage.