نمط التقسيم

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

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

قد يخضع مخزن البيانات الذي يستضيفه خادم واحد للقيود التالية:

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

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

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

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

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

حل

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

هذا النمط له الفوائد التالية:

• يمكنك توسيع نطاق النظام عن طريق إضافة المزيد من القطع التي تعمل على عقد تخزين إضافية.

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

• يمكنك تقليل الخلاف وتحسين الأداء من خلال موازنة حمل العمل عبر الأجزاء.

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

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

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

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

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

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

إستراتيجيات التقسيم

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

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

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

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

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

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

لفهم ميزة استراتيجية التجزئة على استراتيجيات التجزئة الأخرى، ضع في اعتبارك كيف يمكن للتطبيق متعدد المستأجرين الذي يسجل مستأجرين جدد بشكل تسلسلي تعيين المستأجرين للأجزاء في مخزن البيانات. عند استخدام إستراتيجية Range، سيتم تخزين جميع بيانات المستأجرين من 1 إلى n في الجزء A، وسيتم تخزين بيانات المستأجرين من n + 1 إلى m في الجزء B، وهكذا. إذا كان أحدث المستأجرين المسجلين هم أيضاً الأكثر نشاطاً، فسيحدث معظم نشاط البيانات في عدد صغير من الأجزاء، ما قد يتسبب في وجود نقاط فعالة. في المقابل، تخصص إستراتيجية Hash المستأجرين لأجزاء بناءً على تجزئة معرف المستأجر الخاص بهم. هذا يعني أنه من المرجح أن يتم تخصيص المستأجرين المتسلسلين لأجزاء مختلفة، والتي ستوزع الحمل عبرهم. يوضح الشكل السابق هذا للمستأجرين 55 و56.

تتمتع إستراتيجيات التجزئة الثلاث بالمزايا والاعتبارات التالية:

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

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

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

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

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

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

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

• يمكن تخزين البيانات الخاصة بالمستأجرين الذين يحتاجون إلى درجة عالية من عزل البيانات والخصوصية على خادم منفصل تماماً.

عمليات التحجيم ونقل البيانات

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

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

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

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

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

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

• التقاسم مكمل لأشكال أخرى من التقسيم، مثل التقسيم الرأسي والتقسيم الوظيفي. على سبيل المثال، يمكن أن يحتوي جزء واحد على كيانات تم تقسيمها رأسياً، ويمكن تنفيذ قسم وظيفي كأجزاء متعددة. لمزيد من المعلومات حول التقسيم، راجع Data Partitioning Guidance.

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

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

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

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

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

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

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

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

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

• تأكد من أن الموارد المتاحة لكل عقدة تخزين جزء كافية للتعامل مع متطلبات قابلية التوسع من حيث حجم البيانات ومعدل النقل. لمزيد من المعلومات، راجع قسم "تصميم أقسام لقابلية التوسيع" في Data Partitioning Guidance.

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

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

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

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

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

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

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

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

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

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

مثال

ضع في اعتبارك موقع ويب يجسد مجموعة واسعة من المعلومات حول الكتب المنشورة في جميع أنحاء العالم. يشير عدد الكتب الممكنة التي تم فهرستها في حمل العمل هذا وأنماط الاستعلام/الاستخدام النموذجية إلى استخدام قاعدة بيانات ارتباطية واحدة لتخزين معلومات الكتاب. يقرر مهندس حمل العمل تقسيم البيانات عبر مثيلات قاعدة بيانات متعددة، باستخدام رقم الكتاب القياسي الدولي الثابت (ISBN) للكتب لمفتاح القطع. على وجه التحديد، يستخدمون رقم الفحص (0 - 10) من ISBN لأن ذلك يعطي 11 قطعة منطقية محتملة وسيتم موازنة البيانات إلى حد ما عبر كل جزء. للبدء، يقررون تجميع الأجزاء المنطقية ال 11 في ثلاث قواعد بيانات للأجزاء المادية. يستخدمون نهج تقسيم البحث ويخزنون معلومات تعيين المفتاح إلى الخادم في قاعدة بيانات خريطة الأجزاء.

خريطة جزء البحث

تحتوي قاعدة بيانات خريطة الجزء على جدول وبيانات تعيين الجزء التالي.

SELECT ShardKey, DatabaseServer
FROM BookDataShardMap

| ShardKey | DatabaseServer |
|----------|----------------|
|        0 | bookdbshard0   |
|        1 | bookdbshard0   |
|        2 | bookdbshard0   |
|        3 | bookdbshard1   |
|        4 | bookdbshard1   |
|        5 | bookdbshard1   |
|        6 | bookdbshard2   |
|        7 | bookdbshard2   |
|        8 | bookdbshard2   |
|        9 | bookdbshard0   |
|       10 | bookdbshard1   |

مثال على رمز موقع الويب - الوصول إلى جزء واحد

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

يتم تكوين موقع الويب باستخدام سلسلة الاتصال التالية، إما في appsettings.json ملف، كما هو الحال في هذا المثال، أو من خلال إعدادات تطبيق App Service.

{
  ...
  "ConnectionStrings": {
    "ShardMapDb": "Data Source=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=ShardMap;Authentication=Active Directory Default;App=Book Site v1.5a",
    "BookDbFragment": "Data Source=tcp:SHARD.database.windows.net,1433;Initial Catalog=Books;Authentication=Active Directory Default;App=Book Site v1.5a"
  },
  ...
}

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

...

// All data for this book is stored in a shard based on the book's ISBN check digit,
// which is converted to an integer 0 - 10 (special value 'X' becomes 10).
int isbnCheckDigit = book.Isbn.CheckDigitAsInt;

// Establish a pooled connection to the database shard for this specific book.
using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: isbnCheckDigit, cancellationToken))
{
  // Update the book's Library of Congress catalog information
  SqlCommand cmd = sqlConn.CreateCommand();
  cmd.CommandText = @"UPDATE LibraryOfCongressCatalog
                         SET ControlNumber = @lccn,
                             ...
                             Classification = @lcc
                       WHERE BookID = @bookId";

  cmd.Parameters.AddWithValue("@lccn", book.LibraryOfCongress.Lccn);
  ...
  cmd.Parameters.AddWithValue("@lcc", book.LibraryOfCongress.Lcc);
  cmd.Parameters.AddWithValue("@bookId", book.Id);

  await cmd.ExecuteNonQueryAsync(cancellationToken);
}

...

في المثال السابق للتعليمات البرمجية، إذا كان book.Isbn978-8-1130-1024-6، isbnCheckDigit فيجب أن يكون 6. عادة ما يتم تنفيذ الاستدعاء إلى OpenShardConnectionForKeyAsync(6) بنهج ذاكرة التخزين المؤقت جانبا. يستعلم عن قاعدة بيانات خريطة الأجزاء المحددة مع سلسلة الاتصال ShardMapDb إذا لم تكن تحتوي على معلومات الأجزاء المخزنة مؤقتا لمفتاح الجزء 6. إما من ذاكرة التخزين المؤقت للتطبيق أو من قاعدة بيانات الجزء، تأخذ القيمة bookdbshard2 مكان SHARD في BookDbFragment سلسلة الاتصال. يتم إنشاء اتصال مجمع (إعادة) إلى bookdbshard2.database.windows.net وفتحه وإعادته إلى رمز الاستدعاء. ثم تقوم التعليمات البرمجية بتحديث السجل الموجود على مثيل قاعدة البيانات هذا.

مثال على التعليمات البرمجية لموقع الويب - الوصول إلى أجزاء متعددة

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

...

// Retrieve all shard keys
var shardKeys = shardedDatabaseConnections.GetAllShardKeys();

// Execute the query, in a fan-out style, against each shard in the shard list.
Parallel.ForEachAsync(shardKeys, async (shardKey, cancellationToken) =>
{
  using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: shardKey, cancellationToken))
  {
    SqlCommand cmd = sqlConn.CreateCommand();
    cmd.CommandText = @"SELECT ...
                          FROM ...
                         WHERE ...";

    SqlDataReader reader = await cmd.ExecuteReaderAsync(cancellationToken);

    while (await reader.ReadAsync(cancellationToken))
    {
      // Read the results in to a thread-safe data structure.
    }

    reader.Close();
  }
});

...

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

إضافة مثيلات الأجزاء

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

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

وظائف SDK

بدلا من كتابة تعليمات برمجية مخصصة لإدارة الأجزاء وتوجيه الاستعلام إلى مثيلات قاعدة بيانات Azure SQL، قم بتقييم مكتبة عميل قاعدة البيانات المرنة. تدعم هذه المكتبة إدارة خريطة الأجزاء وتوجيه الاستعلام المعتمد على البيانات والاستعلامات عبر الأجزاء في كل من C# وJava.

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

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

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

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

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

• نمط Index Table. في بعض الأحيان، لا يمكن دعم الاستعلامات تماماً من خلال تصميم مفتاح جزء فقط. يُمكِّن تطبيقاً من استرداد البيانات بسرعة من مخزن بيانات كبير عن طريق تحديد مفتاح آخر غير مفتاح الجزء.
• نمط العرض الفعلي. للحفاظ على أداء بعض عمليات الاستعلام، من المفيد إنشاء طرق عرض فعلية تقوم بتجميع البيانات وتلخيصها، خاصةً إذا كانت هذه البيانات الموجزة تستند إلى المعلومات الموزعة عبر الأجزاء. يصف كيفية إنشاء وتعبئة طرق العرض هذه.