في العديد من الحلول واسعة النطاق، يتم تقسيم البيانات إلى أقسام يمكن إدارتها والوصول إليها بشكل منفصل. يمكن أن يؤدي التقسيم إلى تحسين قابلية التوسع وتقليل الخلاف وتحسين الأداء. يمكن أن يوفر أيضًا آلية لتقسيم البيانات حسب نمط الاستخدام. فعلى سبيل المثال، يمكنك أرشفة البيانات القديمة في تخزين بيانات أرخص.
ومع ذلك، يجب اختيار استراتيجية التقسيم بعناية لتحقيق أقصى قدر من الفوائد مع تقليل الآثار الضارة إلى الحد الأدنى.
إشعار
في هذه المقالة، يعني مصطلح التقسيم عملية تقسيم البيانات فعلياً إلى مخازن بيانات منفصلة. إنه ليس هو نفسه تقسيم جدول SQL Server.
لماذا تقسيم البيانات?
تحسين قابلية التوسع. عند توسيع نطاق نظام قاعدة بيانات واحد، سيصل في النهاية إلى حد الأجهزة الفعلية. إذا قمت بتقسيم البيانات عبر أقسام متعددة، كل منها مستضاف على خادم منفصل، فيمكنك توسيع نطاق النظام إلى أجل غير مسمى تقريباً.
تحسين الأداء. تتم عمليات الوصول إلى البيانات على كل قسم على حجم أصغر من البيانات. إذا تم ذلك بشكل صحيح، يمكن أن يجعل التقسيم نظامك أكثر كفاءة. يمكن تشغيل العمليات التي تؤثر على أكثر من قسمٍ بالتوازي.
تحسين الأمان. في بعض الحالات، يمكنك فصل البيانات الحساسة وغير الهامة إلى أقسام مختلفة وتطبيق عناصر تحكم أمان مختلفة على البيانات الحساسة.
توفير المرونة التشغيلية. يوفر التقسيم العديد من الفرص لضبط العمليات، وزيادة الكفاءة الإدارية إلى أقصى حد، وتقليل التكلفة. على سبيل المثال، يمكنك تحديد استراتيجيات مختلفة للإدارة والمراقبة والنسخ الاحتياطي والاستعادة والمهام الإدارية الأخرى استناداً إلى أهمية البيانات في كل قسم.
مطابقة مخزن البيانات مع نمط الاستخدام. يسمح التقسيم بنشر كل قسم على نوع مختلف من مخزن البيانات، استناداً إلى التكلفة والميزات المضمنة التي يوفرها مخزن البيانات. على سبيل المثال، يمكن تخزين البيانات الثنائية الكبيرة في وحدة تخزين blob، في حين يمكن الاحتفاظ ببيانات أكثر تنظيماً في قاعدة بيانات المستندات. راجع اختر مخزن البيانات المناسب.
تحسين التوفر. يؤدي فصل البيانات عبر خوادم متعددة إلى تجنب نقطة فشل واحدة. إذا فشل مثيل واحد، لا يعني ذلك سوى أن البيانات الموجودة في هذا القسم غير متوفرة. يمكن متابعة العمليات على أقسام أخرى. بالنسبة إلى مخازن بيانات النظام الأساسي المدار كخدمة (PaaS)، فإن هذا الاعتبار أقل صلة، لأن هذه الخدمات مصممة بتكرار مضمن.
تصميم الأقسام
هناك ثلاث استراتيجيات نموذجية لتقسيم البيانات:
التقسيم الأفقي (غالباً ما يسمى التقسيم). في هذه الاستراتيجية، يكون كل قسم عبارة عن مخزن بيانات منفصل، ولكن جميع الأقسام لها نفس المخطط. يعرف كل قسم باسم shard ويحمل مجموعة فرعية محددة من البيانات، مثل جميع الطلبات لمجموعة محددة من العملاء.
التقسيم العمودي. في هذه الاستراتيجية، يحتوي كل قسم على مجموعة فرعية من حقول العناصر الموجودة في مخزن البيانات. يتم تقسيم الحقول وفقاً لنمط استخدامها. على سبيل المثال، قد يتم وضع الحقول التي يتم الوصول إليها بشكل متكرر في قسم رأسي واحد وحقول أقل وصولاً إليها بشكل متكرر في قسم آخر.
التقسيم الوظيفي. في هذه الاستراتيجية، يتم تجميع البيانات وفقاً لكيفية استخدامها من قبل كل سياق محدود في النظام. على سبيل المثال، قد يقوم نظام التجارة الإلكترونية بتخزين بيانات الفاتورة في قسم واحد وبيانات مخزون المنتج في قسم آخر.
يمكن الجمع بين هذه الاستراتيجيات، ونوصي بأن تفكر فيها جميعاً عند تصميم مخطط تقسيم. على سبيل المثال، قد تقسم البيانات إلى أجزاء ثم تستخدم التقسيم العمودي لتقسيم البيانات في كل جزء.
التقسيم الأفقي - (التجزئة)
ويبين الشكل 1 التقسيم الأفقي أو التجزئة. في هذا المثال، يتم تقسيم بيانات مخزون المنتج إلى أجزاء استناداً إلى مفتاح المنتج. يحتفظ كل جزء بالبيانات الخاصة بمجموعة متجاورة من مفاتيح الأجزاء (A-G وH-Z)، منظمة أبجدياً. يؤدي التقسيم إلى نشر الحمل على المزيد من أجهزة الكمبيوتر، مما يقلل من الخلاف ويحسن الأداء.
الشكل 1 - تقسيم (تشارك) البيانات أفقياً استناداً إلى مفتاح قسم.
العامل الأكثر أهمية هو اختيار مفتاح التقسيم. قد يكون من الصعب تغيير المفتاح بعد تشغيل النظام. يجب أن يضمن المفتاح تقسيم البيانات لنشر حِمل العمل بالتساوي قدر الإمكان عبر الأجزاء.
لا يجب أن تكون الأجزاء بنفس الحجم. من المهم تحقيق التوازن بين عدد الطلبات. قد تكون بعض الأجزاء كبيرة جداً، ولكن كل عنصر لديه عدد قليل من عمليات الوصول. قد تكون الأجزاء الأخرى أصغر، ولكن يتم الوصول إلى كل عنصر بشكل متكرر. من المهم أيضاً التأكد من أن قطعة واحدة لا تتجاوز حدود المقياس (من حيث السعة وموارد المعالجة) لمخزن البيانات.
تجنب إنشاء أقسام "نشطة" يمكن أن تؤثر على الأداء والتوافر. على سبيل المثال، يؤدي استخدام الحرف الأول من اسم العميل إلى توزيع غير متوازن، لأن بعض الأحرف أكثر شيوعاً. بدلاً من ذلك، استخدم تجزئة معرف عميل لتوزيع البيانات بشكل أكثر توازناً عبر الأقسام.
اختر مفتاح تقسيم يقلل من أي متطلبات مستقبلية لتقسيم الأجزاء الكبيرة، أو دمج الأجزاء الصغيرة في أقسام أكبر، أو تغيير المخطط. يمكن أن تستغرق هذه العمليات وقتا طويلاً جداً، وقد تتطلب أخذ جزء واحد أو أكثر دون اتصال أثناء تنفيذها.
إذا تم نسخ الأجزاء نسخاً متماثلاً، فقد يكون من الممكن الاحتفاظ ببعض النسخ المتماثلة عبر الإنترنت بينما يتم تقسيم النسخ المتماثلة الأخرى أو دمجها أو إعادة تكوينها. ومع ذلك، قد يحتاج النظام إلى الحد من العمليات التي يمكن تنفيذها أثناء إعادة التكوين. على سبيل المثال، قد يتم وضع علامة على البيانات الموجودة في النسخ المتماثلة على أنها للقراءة فقط لمنع عدم اتساق البيانات.
لمزيد من المعلومات حول التقسيم الأفقي، راجع نمط التقسيم.
التقسيم العمودي
الاستخدام الأكثر شيوعاً للتقسيم الرأسي هو تقليل تكاليف الإدخال/الإخراج والأداء المرتبطة بجلب العناصر التي يتم الوصول إليها بشكل متكرر. يوضح الشكل 2 مثالاً على التقسيم الرأسي. في هذا المثال، يتم تخزين خصائص مختلفة لعنصر في أقسام مختلفة. يحتوي قسم واحد على البيانات التي يتم الوصول إليها بشكل متكرر، بما في ذلك اسم المنتج والوصف والسعر. يحتوي قسم آخر على بيانات المخزون: عدد الأسهم وتاريخ آخر طلب.
الشكل 2 - تقسيم البيانات عمودياً حسب نمط استخدامها.
في هذا المثال، يقوم التطبيق بالاستعلام بانتظام عن اسم المنتج ووصفه وسعره عند عرض تفاصيل المنتج للعملاء. يتم الاحتفاظ بعدد المخزون وتاريخ آخر طلب في قسم منفصل لأن هذين العنصرين يستخدمان معاً بشكل شائع.
مزايا أخرى للتقسيم الرأسي:
يمكن فصل البيانات البطيئة الحركة نسبياً (اسم المنتج والوصف والسعر) عن البيانات الأكثر ديناميكية (مستوى المخزون وتاريخ آخر طلب). تعد البيانات البطيئة الحركة مرشحاً جيداً للتطبيق لتخزين ذاكرة التخزين المؤقت في الذاكرة.
يمكن تخزين البيانات الحساسة في قسم منفصل مع عناصر تحكم أمان إضافية.
يمكن أن يقلل التقسيم العمودي من مقدار الوصول المتزامن المطلوب.
يعمل التقسيم الرأسي على مستوى الكيان داخل مخزن بيانات، مما يؤدي إلى تطبيع الكيان جزئياً لتقسيمه من عنصر عريض إلى مجموعة من العناصر الضيقة. وهي مناسبة بشكل مثالي لمخازن البيانات الموجهة نحو الأعمدة مثل HBase و Cassandra. إذا كان من غير المرجح أن تتغير البيانات الموجودة في مجموعة من الأعمدة، فيمكنك أيضا التفكير في استخدام مخازن الأعمدة في SQL Server.
التقسيم الوظيفي
عندما يكون من الممكن تحديد سياق محدود لكل منطقة عمل متميزة في أحد التطبيقات، فإن التقسيم الوظيفي هو وسيلة لتحسين أداء العزل والوصول إلى البيانات. استخدام شائع آخر للتقسيم الوظيفي هو فصل بيانات القراءة والكتابة عن بيانات القراءة فقط. يوضح الشكل 3 نظرة عامة على التقسيم الوظيفي حيث يتم فصل بيانات المخزون عن بيانات العملاء.
الشكل 3 - تقسيم البيانات وظيفياً حسب السياق المحدد أو المجال الفرعي.
يمكن أن تساعد استراتيجية التقسيم هذه في تقليل التنازع على الوصول إلى البيانات عبر أجزاء مختلفة من النظام.
تصميم أقسام لقابلية التوسع
من الضروري مراعاة الحجم و حمل العمل لكل قسم وموازنتهما بحيث يتم توزيع البيانات لتحقيق أقصى قدر من قابلية التوسع. ومع ذلك، يجب عليك أيضاً تقسيم البيانات بحيث لا تتجاوز حدود القياس لمخزن أقسام واحد.
اتبع الخطوات التالية عند تصميم أقسام لقابلية التوسع:
- قم بتحليل التطبيق لفهم أنماط الوصول إلى البيانات، مثل حجم مجموعة النتائج التي تم إرجاعها بواسطة كل استعلام، وتكرار الوصول، والكمون المتأصل، ومتطلبات معالجة الحوسبة من جانب الخادم. وفي كثير من الحالات، سيطلب عدد قليل من الكيانات الرئيسية معظم موارد المعالجة.
- استخدم هذا التحليل لتحديد أهداف قابلية التوسع الحالية والمستقبلية، مثل حجم البيانات و حِمل العمل. ثم قم بتوزيع البيانات عبر الأقسام لتحقيق هدف قابلية التوسع. للتقسيم الأفقي، يعد اختيار مفتاح الجزء الصحيح أمراً مهماً للتأكد من أن التوزيع زوجي. لمزيد من المعلومات، راجع نمط التقسيم.
- تأكد من أن كل قسم يحتوي على موارد كافية للتعامل مع متطلبات قابلية التوسع، من حيث حجم البيانات و معدل النقل. اعتمادا على مخزن البيانات، قد يكون هناك حد لمقدار مساحة التخزين أو طاقة المعالجة أو النطاق الترددي للشبكة لكل قسم. إذا كان من المحتمل أن تتجاوز المتطلبات هذه الحدود، فقد تحتاج إلى تحسين استراتيجية التقسيم أو تقسيم البيانات بشكل أكبر، وربما الجمع بين إستراتيجيتين أو أكثر.
- راقب النظام للتحقق من توزيع البيانات كما هو متوقع وأن الأقسام يمكنها التعامل مع الحِمل. الاستخدام الفعلي لا يتطابق دائماً مع ما يتنبأ به التحليل. إذا كان الأمر كذلك، فقد يكون من الممكن إعادة توازن الأقسام، أو إعادة تصميم بعض أجزاء النظام للحصول على التوازن المطلوب.
تخصص بعض البيئات السحابية الموارد من حيث حدود البنية التحتية. تأكد من أن حدود الحدود المحددة توفر مساحة كافية لأي نمو متوقع في حجم البيانات، من حيث تخزين البيانات وقوة المعالجة وعرض النطاق الترددي.
على سبيل المثال، إذا كنت تستخدم تخزين جدول Azure، فهناك حد لحجم الطلبات التي يمكن معالجتها بواسطة قسم واحد في فترة زمنية معينة. (لمزيد من المعلومات، راجع أهداف قابلية توسيع تخزين Azure وأدائه.) قد يتطلب الجزء المشغول موارد أكثر مما يمكن لقسم واحد التعامل معه. إذا كان الأمر كذلك، فقد يحتاج الجزء إلى إعادة تقسيم لنشر الحمل. إذا تجاوز الحجم الإجمالي أو معدل النقل لهذه الجداول سعة حساب التخزين، فقد تحتاج إلى إنشاء حسابات تخزين إضافية وتوزيع الجداول عبر هذه الحسابات.
تصميم أقسام لأداء الاستعلام
غالباً ما يمكن تعزيز أداء الاستعلام باستخدام مجموعات بيانات أصغر وتشغيل استعلامات متوازية. يجب أن يحتوي كل قسم على نسبة صغيرة من مجموعة البيانات بأكملها. يمكن أن يؤدي هذا الانخفاض في الحجم إلى تحسين أداء الاستعلامات. ومع ذلك، فإن التقسيم ليس بديلاً لتصميم قاعدة بيانات وتكوينها بشكل مناسب. على سبيل المثال، تأكد من أن لديك الفهارس اللازمة في مكانها.
اتبع الخطوات التالية عند تصميم أقسام لأداء الاستعلام:
فحص متطلبات التطبيق والأداء:
- استخدم متطلبات العمل لتحديد الاستعلامات الهامة التي يجب أن تعمل دائماً بسرعة.
- راقب النظام لتحديد أي استعلامات تعمل ببطء.
- ابحث عن الاستعلامات التي يتم تنفيذها بشكل متكرر. حتى إذا كان لاستعلام واحد تكلفة ضئيلة، فقد يكون الاستهلاك التراكمي للموارد كبيراً.
تقسيم البيانات التي تسبب بطء الأداء:
- حدد حجم كل قسم بحيث يكون وقت استجابة الاستعلام ضمن الهدف.
- إذا كنت تستخدم التقسيم الأفقي، فقم بتصميم مفتاح shard بحيث يمكن للتطبيق تحديد القسم الصحيح بسهولة. هذا يمنع الاستعلام من الاضطرار إلى المسح الضوئي من خلال كل قسم.
- النظر في موقع القسم. إذا كان ذلك ممكناً، حاول الاحتفاظ بالبيانات في أقسام قريبة جغرافيا من التطبيقات والمستخدمين الذين يصلون إليها.
إذا كان لدى كيان متطلبات أداء معدل النقل والاستعلام، فاستخدم التقسيم الوظيفي استناداً إلى هذا الكيان. إذا كان هذا لا يزال لا يفي بالمتطلبات، فقم بتطبيق التقسيم الأفقي أيضاً. في معظم الحالات، تكفي استراتيجية تقسيم واحدة، ولكن في بعض الحالات يكون الجمع بين كلتا الاستراتيجيتين أكثر كفاءة.
فكر في تشغيل الاستعلامات بالتوازي عبر الأقسام لتحسين الأداء.
تصميم أقسام للتوفر
يمكن أن يؤدي تقسيم البيانات إلى تحسين توافر التطبيقات من خلال التأكد من أن مجموعة البيانات بأكملها لا تشكل نقطة فشل واحدة وأن المجموعات الفرعية الفردية لمجموعة البيانات يمكن إدارتها بشكل مستقل.
ضع في اعتبارك العوامل التالية التي تؤثر على التوافر:
مدى أهمية البيانات للعمليات التجارية . حدد البيانات التي تعد معلومات تجارية مهمة، مثل المعاملات، والبيانات التي تعد بيانات تشغيلية أقل أهمية، مثل ملفات السجل.
فكر في تخزين البيانات الهامة في أقسام متوفرة بشكل كبير باستخدام خطة نسخ احتياطي مناسبة.
وضع إجراءات منفصلة للإدارة والرصد لمجموعات البيانات المختلفة.
ضع البيانات التي لها نفس مستوى الأهمية الحرجة في نفس القسم بحيث يمكن نسخها احتياطياً معاً بتردد مناسب. على سبيل المثال، قد تحتاج الأقسام التي تحتوي على بيانات المعاملات إلى النسخ الاحتياطي بشكل متكرر أكثر من الأقسام التي تحتوي على معلومات التسجيل أو التتبع.
كيف يمكن إدارة الأقسام الفردية . يوفر تصميم الأقسام لدعم الإدارة والصيانة المستقلة العديد من المزايا. على سبيل المثال:
في حالة فشل أحد الأقسام، يمكن استرداده بشكل مستقل بدون تطبيقات يمكنها الوصول إلى البيانات الموجودة في أقسام أخرى.
يسمح تقسيم البيانات حسب المنطقة الجغرافية بمهام الصيانة المجدولة في خارج ساعات الذروة لكل موقع. تأكد من أن الأقسام ليست كبيرة جداً لمنع أي صيانة مخططة من الانتهاء خلال هذه الفترة.
ما إذا كنت تريد نسخ البيانات الهامة عبر الأقسام أم لا. يمكن لهذه الاستراتيجية تحسين التوافر والأداء، ولكن يمكن أن تؤدي أيضاً إلى مشكلات الاتساق. يستغرق الأمر بعض الوقت لمزامنة التغييرات مع كل نسخة متماثلة. خلال هذه الفترة، ستحتوي أقسام مختلفة على قيم بيانات مختلفة.
اعتبارات تصميم التطبيق
يضيف التقسيم تعقيدًا لتصميم نظامك وتطويره. ضع في اعتبارك التقسيم كجزء أساسي من تصميم النظام حتى لو كان النظام يحتوي في البداية على قسم واحد فقط. فإذا كنت تتناول التقسيم كفكرة لاحقة، فسيكون الأمر أكثر صعوبة لأن لديك بالفعل نظامًا مباشرًا يجب صيانته:
- منطق الوصول إلى البيانات سوف تحتاج إلى تعديل.
- قد تحتاج كميات كبيرة من البيانات الموجودة إلى الترحيل، لتوزيعها عبر الأقسام.
- يتوقع المستخدمون أن يكونوا قادرين على الاستمرار في استخدام النظام أثناء الترحيل.
في بعض الحالات، لا يعتبر التقسيم مهماً لأن مجموعة البيانات الأولية صغيرة ويمكن معالجتها بسهولة بواسطة خادم واحد. قد يكون هذا صحيحاً لبعض أحمال العمل، ولكن العديد من الأنظمة التجارية تحتاج إلى التوسع مع زيادة عدد المستخدمين.
علاوةً على ذلك، ليس فقط مخازن البيانات الكبيرة هي التي تستفيد من التقسيم. على سبيل المثال، قد يتم الوصول إلى مخزن بيانات صغير بشكل كبير من قبل مئات العملاء المتزامنين. يمكن أن يساعد تقسيم البيانات في هذه الحالة على تقليل الخلاف وتحسين معدل النقل.
ضع في اعتبارك النقاط التالية عند تصميم نظام تقسيم بيانات:
تقليل عمليات الوصول إلى البيانات عبر الأقسام. حيثما أمكن، احتفظ بالبيانات الخاصة بعمليات قاعدة البيانات الأكثر شيوعاً معاً في كل قسم لتقليل عمليات الوصول إلى البيانات عبر الأقسام. يمكن أن يكون الاستعلام عبر الأقسام أكثر استهلاكاً للوقت من الاستعلام داخل قسم واحد، ولكن تحسين الأقسام لمجموعة واحدة من الاستعلامات قد يؤثر سلباً على مجموعات أخرى من الاستعلامات. إذا كان يجب عليك الاستعلام عبر الأقسام، فقم بتقليل وقت الاستعلام عن طريق تشغيل استعلامات متوازية وتجميع النتائج داخل التطبيق. (قد لا يكون هذا الأسلوب ممكناً في بعض الحالات، مثل عند استخدام النتيجة من استعلام واحد في الاستعلام التالي.)
ضع في اعتبارك نسخ البيانات المرجعية الثابتة نسخاً متماثلاً. إذا كانت الاستعلامات تستخدم بيانات مرجعية ثابتة نسبياً، مثل جداول الرموز البريدية أو قوائم المنتجات، ففكر في نسخ هذه البيانات في كافة الأقسام لتقليل عمليات البحث المنفصلة في أقسام مختلفة. يمكن أن يقلل هذا النهج أيضاً من احتمال أن تصبح البيانات المرجعية مجموعة بيانات "نشطة"، مع حركة مرور كثيفة من جميع أنحاء النظام بأكمله. ومع ذلك، هناك تكلفة إضافية مقترنة بمزامنة أي تغييرات على البيانات المرجعية.
تقليل الصلات عبر الأقسام. حيثما أمكن، قلل من متطلبات التكامل المرجعي عبر الأقسام الرأسية والوظيفية. في هذه المخططات، يكون التطبيق مسؤولاً عن الحفاظ على التكامل المرجعي عبر الأقسام. الاستعلامات التي تربط البيانات عبر أقسام متعددة غير فعالة لأن التطبيق يحتاج عادة إلى إجراء استعلامات متتالية استناداً إلى مفتاح ثم مفتاح خارجي. بدلاً من ذلك، فكر في تكرار البيانات ذات الصلة أو إلغاء تطبيعها. إذا كانت الصلات عبر الأقسام ضرورية، فقم بتشغيل الاستعلامات المتوازية عبر الأقسام وضم البيانات داخل التطبيق.
اختر الاتساق النهائي. تقييم ما إذا كان الاتساق القوي هو في الواقع مطلب. ومن النهج الشائعة في الأنظمة الموزعة تنفيذ الاتساق النهائي. يتم تحديث البيانات في كل قسم بشكل منفصل، ويضمن منطق التطبيق اكتمال جميع التحديثات بنجاح. كما أنه يعالج حالات عدم التناسق التي يمكن أن تنشأ من الاستعلام عن البيانات أثناء تشغيل عملية متسقة في النهاية.
ضع في اعتبارك كيفية تحديد الاستعلامات للقسم الصحيح. إذا كان يجب أن يقوم استعلام بفحص جميع الأقسام لتحديد موقع البيانات المطلوبة، فهناك تأثير كبير على الأداء، حتى عند تشغيل استعلامات متوازية متعددة. مع التقسيم العمودي والوظيفي، يمكن للاستعلامات تحديد القسم بشكل طبيعي. من ناحية أخرى، يمكن أن يجعل التقسيم الأفقي تحديد موقع عنصر ما أمراً صعباً، لأن كل جزء له نفس المخطط. حل نموذجي للحفاظ على خريطة تستخدم للبحث عن موقع الجزء لعناصر معينة. يمكن تنفيذ هذه الخريطة في منطق التقسيم الخاص بالتطبيق، أو صيانتها بواسطة مخزن البيانات إذا كانت تدعم التقسيم الشفاف.
ضع في اعتبارك إعادة التوازن بشكل دوري للأجزاء. مع التقسيم الأفقي، يمكن أن تساعد إعادة التوازن بين الأجزاء في توزيع البيانات بالتساوي حسب الحجم وعبء العمل لتقليل نقاط الاتصال الفعالة، وزيادة أداء الاستعلام، والتغلب على قيود التخزين الفعلية. ومع ذلك، هذه مهمة معقدة تتطلب غالباً استخدام أداة أو عملية مخصصة.
نسخ الأقسام نسخاً متماثلاً. إذا قمت بنسخ كل قسم نسخاً متماثلاً، فإنه يوفر حماية إضافية ضد الفشل. إذا فشلت نسخة متماثلة واحدة، يمكن توجيه الاستعلامات نحو نسخة عمل.
إذا وصلت إلى الحدود المادية لاستراتيجية التقسيم، فقد تحتاج إلى توسيع قابلية التوسع إلى مستوى مختلف. على سبيل المثال، إذا كان التقسيم على مستوى قاعدة البيانات، فقد تحتاج إلى تحديد موقع الأقسام أو نسخها نسخاً متماثلاً في قواعد بيانات متعددة. إذا كان التقسيم بالفعل على مستوى قاعدة البيانات، وكانت القيود الفعلية مشكلة، فقد يعني ذلك أنك تحتاج إلى تحديد موقع الأقسام أو نسخها نسخاً متماثلاً في حسابات استضافة متعددة.
تجنب المعاملات التي تصل إلى البيانات في أقسام متعددة. تنفذ بعض مخازن البيانات تناسق المعاملات وتكاملها للعمليات التي تقوم بتعديل البيانات، ولكن فقط عندما تكون البيانات موجودة في قسم واحد. إذا كنت بحاجة إلى دعم المعاملات عبر أقسام متعددة، فستحتاج على الأرجح إلى تنفيذ ذلك كجزء من منطق التطبيق خاصتك لأن معظم أنظمة التقسيم لا توفر دعماً أصلياً.
تتطلب جميع مخازن البيانات بعض أنشطة الإدارة التشغيلية والمراقبة. يمكن أن تتراوح المهام من تحميل البيانات والنسخ الاحتياطي للبيانات واستعادتها وإعادة تنظيم البيانات وضمان أداء النظام بشكل صحيح وفعال.
ضع في اعتبارك العوامل التالية التي تؤثر على الإدارة التشغيلية:
كيفية تنفيذ مهام الإدارة والتشغيل المناسبة عند تقسيم البيانات . قد تتضمن هذه المهام النسخ الاحتياطي والاستعادة وأرشفة البيانات ومراقبة النظام والمهام الإدارية الأخرى. على سبيل المثال، يمكن أن يمثل الحفاظ على الاتساق المنطقي أثناء عمليات النسخ الاحتياطي والاستعادة تحدياً.
كيفية تحميل البيانات إلى أقسام متعددة وإضافة بيانات جديدة تصل من مصادر أخرى . قد لا تدعم بعض الأدوات والأدوات المساعدة عمليات البيانات المجزأة مثل تحميل البيانات في القسم الصحيح.
كيفية أرشفة البيانات وحذفها على أساس منتظم . لمنع النمو المفرط للأقسام، تحتاج إلى أرشفة البيانات وحذفها على أساس منتظم (مثل شهرياً). قد يكون من الضروري تحويل البيانات لمطابقة مخطط أرشيف مختلف.
كيفية تحديد موقع مشكلات تكامل البيانات. فكر في تشغيل عملية دورية لتحديد موقع أي مشكلات تتعلق بسلامة البيانات، مثل البيانات الموجودة في أحد الأقسام التي تشير إلى المعلومات المفقودة في قسم آخر. يمكن للعملية إما محاولة إصلاح هذه المشكلات تلقائياً أو إنشاء تقرير للمراجعة اليدوية.
إعادة توازن الأقسام
مع نضوج النظام، قد تضطر إلى ضبط نظام التقسيم. على سبيل المثال، قد تبدأ الأقسام الفردية في الحصول على حجم غير متناسب من حركة المرور وتصبح نشطة، مما يؤدي إلى خلاف مفرط. أو ربما تكون قد قللت من حجم البيانات في بعض الأقسام، مما تسبب في اقتراب بعض الأقسام من حدود السعة.
يمكن لبعض مخازن البيانات، مثل Azure Cosmos DB، إعادة توازن الأقسام تلقائيا. في حالات أخرى، تعد إعادة التوازن مهمة إدارية تتكون من مرحلتين:
تحديد استراتيجية تقسيم جديدة.
- ما هي الأقسام التي يجب تقسيمها (أو ربما دمجها)?
- ما هو مفتاح القسم الجديد?
ترحيل البيانات من نظام التقسيم القديم إلى مجموعة الأقسام الجديدة.
استنادا إلى مخزن البيانات، قد تتمكن من ترحيل البيانات بين الأقسام أثناء استخدامها. وهذا ما يسمى الترحيل عبر الإنترنت. إذا لم يكن ذلك ممكناً، فقد تحتاج إلى جعل الأقسام غير متوفرة أثناء نقل البيانات (الترحيل دون اتصال).
الترحيل في وضع عدم الاتصال بالإنترنت
عادة ما يكون الترحيل دون اتصال أبسط لأنه يقلل من فرص حدوث نزاع. من الناحية المفاهيمية، يعمل الترحيل دون اتصال على النحو التالي:
- ضع علامة على القسم في وضع عدم الاتصال.
- تقسيم دمج ونقل البيانات إلى الأقسام الجديدة.
- تحقق من البيانات.
- أحضر الأقسام الجديدة عبر الإنترنت.
- إزالة القسم القديم.
اختيارياً، يمكنك وضع علامة على قسم للقراءة فقط في الخطوة 1، بحيث لا يزال بإمكان التطبيقات قراءة البيانات أثناء نقلها.
الترحيل عبر الإنترنت
الترحيل عبر الإنترنت أكثر تعقيداً في الأداء ولكنه أقل اضطراباً. تشبه العملية الترحيل دون اتصال بالإنترنت، باستثناء أن القسم الأصلي لم يتم وضع علامة عليه في وضع عدم الاتصال. اعتمادا على دقة عملية الترحيل (على سبيل المثال، عنصر بعنصر مقابل جزء بجزء)، قد تضطر التعليمات البرمجية للوصول إلى البيانات في تطبيقات العميل إلى التعامل مع قراءة وكتابة البيانات التي يتم الاحتفاظ بها في موقعين، القسم الأصلي والقسم الجديد.
الخطوات التالية
- تعرف على استراتيجيات التقسيم لخدمات Azure محددة. راجع إستراتيجيات تقسيم البيانات.
- قابلية توسعة تخزين Azure وأهداف الأداء
الموارد ذات الصلة
قد تكون أنماط التصميم التالية ذات صلة بالسيناريو خاصتك:
يصف نمط التقسيم بعض الاستراتيجيات الشائعة لتقسيم البيانات.
يوضح نمط جدول index كيفية إنشاء فهارس ثانوية فوق البيانات. يمكن للتطبيق استرداد البيانات بسرعة باستخدام هذا النهج، باستخدام الاستعلامات التي لا تشير إلى المفتاح الأساسي للمجموعة.
يصف نمط العرض الملموس كيفية إنشاء طرق عرض معبأة مسبقاً تلخص البيانات لدعم عمليات الاستعلام السريعة. يمكن أن يكون هذا النهج مفيداً في مخزن بيانات مقسم إذا تم توزيع الأقسام التي تحتوي على البيانات التي يتم تلخيصها عبر مواقع متعددة.