مشاركة عبر

تصميم للاستعلام

  • مقالة

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

تتمثل نقطة البداية الجيدة لتصميم حل خدمة الجدول الخاص بك لتمكينك من قراءة البيانات بكفاءة في السؤال "ما هي الاستعلامات التي سيحتاج تطبيقي إلى تنفيذها لاسترداد البيانات التي يحتاجها من خدمة الجدول؟"

ملاحظة

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

يركز هذا القسم على المشكلات الرئيسية التي يجب عليك معالجتها عند تصميم الجداول للاستعلام. تشمل الموضوعات التي يغطيها هذا القسم ما يلي:

كيف يؤثر اختيارك لـ PartitionKey و RowKey على أداء الاستعلام

تفترض الأمثلة التالية أن خدمة الجدول تقوم بتخزين كيانات الموظفين بالبنية التالية (معظم الأمثلة تحذف خاصية الطابع الزمني للوضوح):

⁧⁩اسم العمود⁧⁩ نوع البيانات
مفتاح التقسيم (اسم القسم) سلسلة
RowKey (معرف الموظف) سلسلة
الاسم الأول سلسلة
اسم العائلة سلسلة
Age عدد صحيح
EmailAddress سلسلة

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

  • يعد استعلام النقاط أكثر عمليات البحث كفاءة في الاستخدام، ويوصى باستخدامه لعمليات البحث كبيرة الحجم أو عمليات البحث التي تتطلب أقل زمن انتقال. يمكن لمثل هذا الاستعلام استخدام الفهارس لتحديد موقع كيان فردي بكفاءة عالية عن طريق تحديد كل من قيم PartitionKey و RowKey. كمثال: $filter=(PartitionKey eq 'Sales') و(RowKey eq '2')
  • ثاني أفضل استعلام هو استعلام النطاق الذي يستخدم PartitionKey وعوامل الترشيح على نطاق من قيم RowKey لإرجاع أكثر من كيان واحد. تحدد قيمة PartitionKey قسما معينا، وتحدد قيم RowKey مجموعة فرعية من الكيانات الموجودة في هذا القسم. كمثال: $filter=(PartitionKey eq 'Sales') وRowKey ge 'S' and RowKey lt 'T'
  • ثالث أفضل استعلام هو فحص القسم الذي يستخدم PartitionKey وعوامل التصفية على خاصية أخرى غير رئيسية والتي قد ترجع أكثر من كيان واحد. تحدد قيمة PartitionKey قسما معينا، وتحدد قيم الميزات لمجموعة فرعية من الكيانات الموجودة في هذا القسم. كمثال: $filter=PartitionKey eq 'Sales' و LastName eq 'Smith'
  • لا يتضمن فحص الجدولPartitionKey وهو غير فعال على الإطلاق لأنه يبحث في جميع الأقسام التي تشكل جدولك بدوره عن أي كيانات مطابقة. سيقوم بإجراء فحص جدول بغض النظر عما إذا كان عامل التصفية الخاص بك يستخدم RowKey أم لا. على سبيل المثال: $filter=LastName eq 'Jones'
  • تقوم الاستعلامات التي ترجع كيانات متعددة بإرجاعها مرتبة بترتيب PartitionKey و RowKey. لتجنب اللجوء إلى الكيانات الموجودة في العميل، اختر RowKey الذي يحدد ترتيب الفرز الأكثر شيوعا.

لاحظ أن استخدام "أو" لتحديد عامل تصفية استنادا إلى قيم RowKey يؤدي إلى فحص القسم ولا يتم التعامل معه كاستعلام نطاق. لذلك، يجب تجنب الاستعلامات التي تستخدم عوامل التصفية مثل: $filter=PartitionKey eq 'Sales و (RowKey eq '121' أو RowKey eq '322')

للحصول على أمثلة للتعليمات البرمجية من جانب العميل التي تستخدم "مكتبة عميل التخزين" لتنفيذ استعلامات فعالة، راجع:

للحصول على أمثلة على التعليمات البرمجية من جانب العميل التي يمكنها التعامل مع أنواع كيانات متعددة مخزنة في نفس الجدول، راجع:

اختيار مفتاح التقسيم المناسب

يجب أن يوازن اختيارك ل PartitionKey الحاجة إلى تمكين استخدام معاملات مجموعة الكيانات (لضمان التناسق) مقابل متطلبات توزيع الكيانات الخاصة بك عبر أقسام متعددة (لضمان حل قابل للتطوير).

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

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

ملاحظة

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

هناك اعتبارات إضافية في اختيارك لـ PartitionKey تتعلق بكيفية إدراج الكيانات وتحديثها وحذفها. لمزيد من المعلومات، راجع تصميم الجداول لتعديل البيانات.

تحسين الاستعلامات لخدمة الجدول

تقوم خدمة الجدول تلقائيا بفهرسة كياناتك باستخدام قيم PartitionKey و RowKey في فهرس واحد متفاوت المسافات، ولهذا استعلامات النقاط هي الأكثر كفاءة في الاستخدام. ومع ذلك، لا توجد فهارس أخرى غير تلك الموجودة على الفهرس متفاوت المسافات على PartitionKey و RowKey.

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

  • نمط الفهرس الثانوي داخل - تخزين نسخ متعددة من كل كيان باستخدام قيم RowKey مختلفة (في نفس القسم) لتمكين عمليات البحث السريعة والفعالة وترتيبات الفرز البديلة باستخدام قيم RowKey مختلفة.
  • نمط الفهرس الثانوي بين الأقسام - تخزين نسخ متعددة من كل كيان باستخدام قيم RowKey مختلفة في أقسام منفصلة أو في جداول منفصلة لتمكين عمليات البحث السريعة والفعالة وترتيبات الفرز البديلة باستخدام قيم RowKey مختلفة.
  • نمط كيانات الفهرس - الإبقاء على كيانات الفهرس لتمكين عمليات البحث الفعالة التي تعرض قوائم الكيانات.

فرز البيانات في خدمة الجدول

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

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

  • نمط الفهرس الثانوي داخل - تخزين نسخ متعددة من كل كيان باستخدام قيم RowKey مختلفة (في نفس القسم) لتمكين عمليات البحث السريعة والفعالة وترتيبات الفرز البديلة باستخدام قيم RowKey مختلفة.
  • نمط الفهرس الثانوي بين الأقسام - تخزين نسخ متعددة من كل كيان باستخدام قيم RowKey مختلفة في أقسام منفصلة في جداول منفصلة لتمكين عمليات البحث السريعة والفعالة وترتيبات الفرز البديلة باستخدام قيم RowKey مختلفة.
  • نمط ذيل السجل - استرد الكيانات n التي تمت إضافتها مؤخرًا إلى القسم باستخدام قيمة RowKey التي تفرز في ترتيب التاريخ والوقت العكسي.

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