النمط الخاص بجدول الفهرس

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

السياق والمشكلة

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

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

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

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

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

حل

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

الاستراتيجية الأولى هي تكرار البيانات في كل جدول فهرس وتنظيمها بواسطة مفاتيح مختلفة (التسوية الكاملة). يعرض الشكل التالي جداول الفهرس التي تنظم معلومات العميل نفسها حسب المدينة واسم العائلة.

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

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

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

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

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

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

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

المسائل والاعتبارات

راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

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

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

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

• إن كان النظام يتضمن عددا من جداول الفهرس عبر مجموعات بيانات كبيرة جدا، فقد يصعب الحفاظ على التناسق بين جداول الفهرس والبيانات الأصلية. وقد يمكن تصميم التطبيق حول نموذج التناسق النهائي. على سبيل المثال، لإدراج البيانات أو تحديثها أو حذفها، يمكن للتطبيق نشر رسالة إلى قائمة انتظار والسماح لمهمة منفصلة بتنفيذ العملية والحفاظ على جداول الفهرس التي تشير إلى هذه البيانات بصورة غير متزامنة. لمزيد من المعلومات حول تنفيذ التناسق النهائي، يرجى مراجعةData Consistency Primer.

  تلميح

  تدعم جداول تخزين Microsoft Azure تحديثات العمليات للتغييرات التي أُجريت على البيانات الموجودة في نفس القسم (يشار إليها باسم عمليات مجموعة الكيانات). إن كان بإمكانك تخزين البيانات في جدول حقائق وجدول فهرس واحد أو أكثر في نفس القسم، يمكنك استخدام هذه الميزة للمساعدة في ضمان التناسق.

• قد تكون جداول الفهرس نفسها مقسمة أو مشاركة.

موعد استخدام النمط

استخدم هذا النمط لتحسين أداء الاستعلام عندما يحتاج التطبيق بشكل متكرر إلى استرداد البيانات من خلال مفتاح آخر غير المفتاح الأساسي (أو المقطع).

قد لا يكون هذا النمط مفيدًا في الحالات الآتية:

• تغير البيانات. يمكن أن يصبح جدول الفهرس قديما بسرعة كبيرة، مما يجعله غير فعال أو يجعل الحمل للحفاظ على جدول الفهرس أكبر من أي وفورات أُجريت باستخدامه.
• الحقل المحدد باعتباره مفتاح ثانوي لجدول فهرس غير قابل للاكتشاف ويمكن أن يحتوي فقط على مجموعة صغيرة من القيم (على سبيل المثال، الجنس).
• ينحرف توازن قيم البيانات لحقل محدد باعتباره مفتاح ثانوي لجدول فهرس بشكل كبير. على سبيل المثال، إن احتوت 90٪ من السجلات على نفس القيمة في حقل، فقد يؤدي إنشاء جدول فهرس وصيانته للبحث عن البيانات استنادا إلى هذا الحقل إلى زيادة الحمل مقارنة بالمسح بالتسلسل من خلال البيانات. ومع ذلك، إن كانت الاستعلامات تستهدف بشكل متكرر القيم الموجودة في 10٪المتبقية، يمكن أن يكون هذا الفهرس مفيدا. يجب أن تفهم الاستعلامات التي ينفذها التطبيق الخاص بك، ومدى تكرار تنفيذها.

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط جدول الفهرس في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

مثال

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

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

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

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

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

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

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

الموارد ذات الصلة

قد تكون الأنماط الموضحة أدناه مناسبة أيضًا عند تنفيذ هذا النمط:

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