استراتيجيات تقسيم البيانات

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

تقسيم قواعد بيانات Azure SQL

قاعدة بيانات SQL واحدة لها حد لحجم البيانات التي يمكن أن تحتوي عليها. يتم تقييد الإنتاجية من خلال العوامل المعمارية وعدد الاتصالات المتزامنة التي يدعمها.

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

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

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

لمزيد من المعلومات حول التجمعات المرنة، راجع التوسع باستخدام قاعدة بيانات Azure SQL.

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

بدلاً من ذلك، استخدم Azure SQL Data Sync أو Azure Data Factory لنسخ قاعدة بيانات مدير خريطة الجزء عبر المناطق. يعمل هذا الشكل من النسخ المتماثل بشكل دوري ويكون أكثر ملاءمة إذا تغيرت خريطة الجزء بشكل غير متكرر، ولا تتطلب طبقة مميزة.

توفر قاعدة البيانات المرنة مخططين لتعيين البيانات إلى الأجزاء الصغيرة وتخزينها في أجزاء:

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

  

  قم بتنزيل ملف Visio لهذا الرسم التخطيطي.

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

  

  تنزيل ملف Visio لهذا الرسم التخطيطي

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

قم بتنزيل ملف Visio لهذا الرسم التخطيطي.

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

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

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

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

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

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

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

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

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

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

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

تقسيم تخزين جدول Azure

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

• مفتاح التقسيم. هذه قيمة سلسلة تحدد القسم حيث سيضع تخزين Azure Table الكيان. يتم تخزين جميع الكيانات التي لها نفس مفتاح القسم في نفس القسم.

• مفتاح الصف. هذه قيمة سلسلة تحدد الكيان داخل القسم. يتم فرز جميع الكيانات داخل القسم حسب المعجم، بترتيب تصاعدي، بواسطة هذا المفتاح. يجب أن تكون تركيبة مفتاح/صف القسم فريدة لكل كيان ولا يمكن أن يتجاوز طولها 1 كيلوبايت.

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

هذه الآلية تنفذ بشكل فعال استراتيجية التوسع التلقائي. يتم تخزين كل قسم على نفس الخادم في مركز بيانات Azure للمساعدة في ضمان تشغيل الاستعلامات التي تسترد البيانات من قسم واحد بسرعة.

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

يوضح الرسم البياني التالي البنية المنطقية لحساب تخزين كمثال. يحتوي حساب التخزين على ثلاثة جداول: معلومات العميل ومعلومات المنتج ومعلومات الطلب.

يحتوي كل جدول على أقسام متعددة.

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

ضع في اعتبارك النقاط التالية عند تصميم الكيانات الخاصة بك لتخزين Azure Table:

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

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

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

• إذا قمت بإنشاء مفاتيح أقسام باستخدام تسلسل رتيبة (مثل "0001" و"0002" و"0003") ويحتوي كل قسم على كمية محدودة من البيانات فقط، يمكن لتخزين جدول Azure تجميع هذه الأقسام معا فعليا على نفس الخادم. يفترض Azure Storage أنه من المرجح أن يقوم التطبيق بتنفيذ استعلامات عبر نطاق متجاور من الأقسام (استعلامات النطاق) وقد تم تحسينه لهذه الحالة. ومع ذلك، يمكن أن يؤدي هذا النهج إلى النقاط الساخنة، لأنه من المحتمل أن تتركز جميع عمليات إدراج الكيانات الجديدة في أحد طرفي النطاق المتجاور. يمكن أن يقلل أيضًا من قابلية التوسع. لتوزيع الحمل بشكل متساوٍ، ضع في اعتبارك تجزئة مفتاح القسم.

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

• ضع في اعتبارك مدى دقة مفتاح القسم:

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

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

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

لمزيد من المعلومات، راجع دليل تصميم جدول تخزين Azure واستراتيجية التقسيم القابلة للتوسعة.

تقسيم تخزين كائن ثنائي كبير الحجم من Azure

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

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

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

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

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

تقسيم قوائم انتظار Azure Storage

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

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

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

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

تقسيم ناقل خدمة Azure

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

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

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

يقوم ناقل الخدمة بتعيين رسالة إلى جزء على النحو التالي:

• إذا كانت الرسالة تنتمي إلى إحدى الجلسات، فسيتم إرسال جميع الرسائل التي لها نفس القيمة للخاصية SessionId إلى الجزء نفسه.

• إذا كانت الرسالة لا تنتمي إلى جلسة، ولكن المرسل حدد قيمة للخاصية PartitionKey، فسيتم إرسال جميع الرسائل التي لها نفس قيمة PartitionKey إلى الجزء نفسه.

  إشعار

  إذا تم تحديد خصائص SessionId وPartitionKey، فيجب تعيينهما على نفس القيمة وإلا فسيتم رفض الرسالة.

• إذا لم يتم تحديد خصائص SessionId وPartitionKey لإحدى الرسائل، ولكن تم تمكين الكشف عن التكرارات، فسيتم استخدام الخاصية MessageId. سيتم توجيه جميع الرسائل التي لها MessageId نفسه إلى الجزء نفسه.

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

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

• يتم إنشاء قوائم انتظار وموضوعات ناقل الخدمة ضمن نطاق مساحة اسم ناقل الخدمة. يسمح ناقل خدمة Microsoft Azure حالياً بما يصل إلى 100 قائمة انتظار أو موضوعات مقسمة لكل مساحة اسم.

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

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

• لا يمكن تكوين قوائم الانتظار والموضوعات المقسمة ليتم حذفها تلقائيًا عندما تصبح خاملة.

• لا يمكن حاليًا استخدام قوائم الانتظار والموضوعات المقسمة مع بروتوكول وضع الرسائل في قائمة انتظار (AMQP) إذا كنت تقوم بإنشاء حلول مشتركة بين الأنظمة الأساسية أو حلول مختلطة.

تقسيم Azure Cosmos DB

Azure Cosmos DB ل NoSQL هي قاعدة بيانات NoSQL لتخزين مستندات JSON. المستند في قاعدة بيانات Azure Cosmos DB هو تمثيل تسلسلي JSON لعنصر أو جزء آخر من البيانات. لا يتم فرض مخططات ثابتة إلا أنه يجب أن يحتوي كل مستند على معرف فريد.

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

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

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

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

ضع في اعتبارك النقاط التالية عند تحديد كيفية تقسيم البيانات باستخدام Azure Cosmos DB ل NoSQL:

• تخضع الموارد المتوفرة لقاعدة بيانات Azure Cosmos DB لقيود الحصة النسبية للحساب. يمكن أن تحتوي كل قاعدة بيانات على عدد من المجموعات، وترتبط كل مجموعة بمستوى أداء يحكم حد معدل وحدة الطلب (معدل النقل المحجوز) لتلك المجموعة. لمزيد من المعلومات، راجع حدود الاشتراك والخدمة في Azure والحصص النسبية والقيود.

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

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

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

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

• يجب ألا تتجاوز المجموعات التي تنوي الاحتفاظ بها في قواعد البيانات حدود الإنتاجية المحددة بواسطة مستويات أداء المجموعات.. لمزيد من المعلومات، راجع Request Units in Azure Cosmos DB. إذا كنت تتوقع الوصول إلى هذه الحدود، ففكر في تقسيم المجموعات عبر قواعد البيانات في حسابات مختلفة لتقليل الحمل لكل مجموعة.

تقسيم بحث Azure

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

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

لتقليل التنازع، يمكن تقسيم مساحة التخزين المستخدمة بواسطة Azure Search إلى قسم 1 أو 2 أو 3 أو 4 أو 6 أو 12، ويمكن نسخ كل قسم حتى 6 مرات. يسمى ناتج عدد الأقسام مضروبًا في عدد النسخ المتماثلة بوحدة البحث (SU). يمكن أن يحتوي مثيل واحد من Azure Search على 36 وحدة تخزين بحد أقصى (تدعم قاعدة البيانات التي تحتوي على 12 قسمًا 3 نسخ متماثلة كحد أقصى فقط).

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

يمكن أن يحتوي كل قسم على 15 مليون مستند كحد أقصى أو يشغل 300 جيجابايت من مساحة التخزين (أيهما أصغر). يمكنك إنشاء ما يصل إلى 50 فهرسًا. يختلف أداء الخدمة ويعتمد على مدى تعقيد المستندات والفهارس المتاحة وتأثيرات زمن انتقال الشبكة. في المتوسط، يجب أن تكون النسخة المتماثلة الفردية (1 SU) قادرة على معالجة 15 استعلامًا في الثانية (QPS)، على الرغم من أننا نوصي بإجراء قياس الأداء باستخدام بياناتك الخاصة للحصول على قياس أكثر دقة للإنتاجية. لمزيد من المعلومات، راجع حدود الخدمة في Azure Search.

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

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

• إنشاء مستويين من Azure Search:

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

هذا النهج هو الأكثر ملاءمة عندما يكون هناك تباين إقليمي كبير في البيانات التي يتم البحث عنها.

تقسيم ذاكرة التخزين المؤقت Azure لـ Redis

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

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

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

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

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

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

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

ضع في اعتبارك النقاط التالية عند تحديد كيفية تقسيم البيانات باستخدام ذاكرة التخزين المؤقت في Azure لـ Redis:

• لا يُقصد من ذاكرة التخزين المؤقت في Azure لـ Redis العمل كمخزن بيانات دائم، لذا مهما كان مخطط التقسيم الذي تقوم بتنفيذه، يجب أن يكون رمز التطبيق الخاص بك قادرًا على استرداد البيانات من موقع ليس ذاكرة التخزين المؤقت.

• يجب الاحتفاظ بالبيانات التي يتم الوصول إليها بشكل متكرر معًا في نفس القسم. يعد Redis متجرًا قويًا للقيمة الرئيسية يوفر العديد من الآليات المحسّنة للغاية لهيكلة البيانات. يمكن أن تكون هذه الآليات واحدة مما يلي:

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

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

الشكل 8 الهيكل المقترح في تخزين Redis لتسجيل طلبات العملاء وتفاصيلهم.

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

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

  إشعار

  عند استخدام Azure Cache لـ Redis، فإنك تحدد الحجم الأقصى لذاكرة التخزين المؤقت (من 250 ميجابايت إلى 53 جيجابايت) عن طريق تحديد طبقة التسعير المناسبة. ومع ذلك، بعد إنشاء Azure Cache لـ Redis، لا يمكنك زيادة (أو تقليل) حجمها.

• لا يمكن أن تمتد دفعات ومعاملات Redis عبر اتصالات متعددة، لذلك يجب الاحتفاظ بجميع البيانات المتأثرة بدفعة أو معاملة في نفس قاعدة البيانات (جزء).

  إشعار

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

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

تقسيم نسيج خدمة Azure

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

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

• نظرة عامة على Azure Service Fabric هي مقدمة إلى Azure Service Fabric.

• توفر خدمات Partition Service Fabric الموثوقة مزيدًا من المعلومات عن الخدمات الموثوقة في Azure Service Fabric.

تقسيم مراكز أحداث Azure

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

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

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

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

لمزيد من المعلومات عن استخدام الأقسام في Event Hubs، راجع ما هو مراكز الأحداث؟.

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