مشاركة عبر

اعتبارات النظام الأساسي للبيانات لأحمال العمل الحرجة للمهام على Azure

  • مقالة

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

يتوسع مجال التصميم هذا في تصميم التطبيق، ما يوفر اعتبارات وتوصيات رئيسية لإبلاغ اختيار نظام أساسي للبيانات الأمثل.

هام

هذه المقالة هي جزء من سلسلة حمل العمل الحرجة للمهام Well-Architected Azure . إذا لم تكن على دراية بهذه السلسلة، نوصيك بالبدء بما هو حمل العمل الحرج للمهمة؟

أربعة مقابل البيانات الضخمة

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

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

الاعتبارات المتعلقة بالتصميم

وحدة تخزين

  • وحدات تخزين البيانات الحالية (إن وجدت) والمتوقعة في المستقبل استنادا إلى معدلات نمو البيانات المتوقعة التي تتوافق مع أهداف العمل وخططه.

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

  • قد يتقلب حجم البيانات بسبب تغير ظروف العمل أو إجراءات التدبير المنزلي.

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

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

    • هل سيؤدي ذلك إلى وقت تعطل؟ وإذا كان الأمر كذلك، فكم من الوقت؟
    • ما هي إجراءات التخفيف من المخاطر؟ هل سيتطلب التخفيف من المخاطر تغييرات في التطبيق؟
    • هل سيكون هناك خطر فقدان البيانات؟

  • يمكن استخدام ميزات مثل Time to Live (TTL) لإدارة نمو البيانات عن طريق حذف السجلات تلقائيا بعد مرور وقت منقضي، باستخدام إما إنشاء السجلات أو تعديلها.

    • على سبيل المثال، يوفر Azure Cosmos DB إمكانية TTL مدمجة.

السرعة

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

    • ستختلف طبيعة متطلبات معدل النقل حسب سيناريو حمل العمل، مثل تلك التي تكون ثقيلة القراءة أو ثقيلة الكتابة.
      • على سبيل المثال، ستحتاج أحمال العمل التحليلية عادة إلى تلبية معدل نقل كبير للقراءة.
    • ما هو معدل النقل المطلوب؟ وكيف من المتوقع أن ينمو معدل النقل؟
    • ما هي متطلبات زمن انتقال البيانات في P50/P99 ضمن مستويات التحميل المرجعية؟

  • تعد قدرات مثل دعم تصميم خال من التأمين وضبط الفهرس ونهج التناسق أمرا بالغ الأهمية لتحقيق معدل نقل عال.

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

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

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

  • يمكن أن يختلف تأثير انخفاض معدل النقل استنادا إلى سيناريو حمل العمل.

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

  • تقدم توصية تصميم التطبيق الأساسية لاستخدام توزيع جغرافي نشط-نشط تحديات حول تناسق البيانات.

    • هناك مفاضلة بين الاتساق والأداء فيما يتعلق دلالات معاملات ACID الكاملة وسلوك التأمين التقليدي.
      • سيأتي تقليل زمن انتقال الكتابة على حساب تناسق البيانات.

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

  • يمكن استخدام النسخ المتماثلة للقراءة فقط (داخل المنطقة وعبر المنطقة) لتقليل زمن انتقال التقريب وتوزيع نسبة استخدام الشبكة لتعزيز الأداء ومعدل النقل والتوافر وقابلية التوسع.

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

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

متنوعه

  • سيؤثر نموذج البيانات وأنواع البيانات وعلاقات البيانات ونموذج الاستعلام المقصود بشدة على قرارات النظام الأساسي للبيانات.

    • هل يتطلب التطبيق نموذج بيانات ارتباطية أو يمكنه دعم مخطط متغير أو نموذج بيانات غير ارتباطي؟
    • كيف سيتم الاستعلام عن بيانات التطبيق؟ وسوف تعتمد الاستعلامات على مفاهيم طبقة قاعدة البيانات مثل الصلات الارتباطية؟ أم أن التطبيق يوفر مثل هذه الدلالات؟

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

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

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

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

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

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

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

  • ستؤثر قدرات المحاذاة المحسنة مع نموذج البيانات وأنواع البيانات الشاملة بقوة على قرارات النظام الأساسي للبيانات.

    • طبقات الاستعلام مثل الإجراءات المخزنة والمخططين الارتباطيين للكائنات.
    • إمكانية الاستعلام المحايدة للغة، مثل طبقة REST API آمنة.
    • قدرات استمرارية الأعمال، مثل النسخ الاحتياطي والاستعادة.

  • تدعم مخازن البيانات التحليلية عادة التخزين متعدد اللغات للأنوعات المختلفة من بنيات البيانات.

    • قد يكون لبيئات وقت التشغيل التحليلي، مثل Apache Spark، قيود تكامل لتحليل بنيات البيانات متعددة اللغات.

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

صحه

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

    • تناسق البيانات.
    • ميزات أمان النظام الأساسي.
    • إدارة البيانات.
    • تغيير الإدارة وتطور المخطط.
    • التبعيات بين مجموعات البيانات.

  • في أي تطبيق موزع مع نسخ متماثلة متعددة للبيانات، هناك مفاضلة بين التناسق وا لزمن الانتقال، كما هو مبين في نظريتي CAP و PACELC .

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

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

    • يمكن تطبيق نهج موحدة لحل التعارض، مثل "Last Write Wins"، أو استراتيجية مخصصة مع منطق مخصص.

  • قد يؤثر تنفيذ متطلبات الأمان سلبا على معدل النقل أو الأداء.

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

  • يدعم Azure نماذج تشفير مختلفة، بما في ذلك التشفير من جانب الخادم الذي يستخدم المفاتيح المدارة بواسطة الخدمة أو المفاتيح التي يديرها العميل في Key Vault أو المفاتيح التي يديرها العميل على الأجهزة التي يتحكم فيها العميل.

    • باستخدام التشفير من جانب العميل، يمكن إدارة المفاتيح في Key Vault أو موقع آمن آخر.

  • يتم استخدام تشفير ارتباط بيانات MACsec (IEEE 802.1AE MAC) لتأمين جميع حركة المرور التي تنتقل بين مراكز بيانات Azure على شبكة Microsoft الأساسية.

    • يتم تشفير الحزم وفك تشفيرها على الأجهزة قبل إرسالها، مما يمنع هجمات "الرجل في الوسط" الفعلية أو التطفل/التنصت.

  • المصادقة والتخويل لمستوى البيانات ومستوى التحكم.

    • كيف سيقوم النظام الأساسي للبيانات بمصادقة وتخويل الوصول إلى التطبيق والوصول التشغيلي؟

  • إمكانية المراقبة من خلال مراقبة صحة النظام الأساسي والوصول إلى البيانات.

    • كيف سيتم تطبيق التنبيه على الظروف خارج الحدود التشغيلية المقبولة؟

توصيات التصميم

وحدة تخزين

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

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

  • مراقبة حجم البيانات والتحقق من صحتها مقابل نموذج السعة، مع مراعاة حدود المقياس ومعدلات نمو البيانات المتوقعة.

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

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

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

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

    • تكوين انتهاء صلاحية Time-To-Live (TTL) للبيانات التي لم تعد مطلوبة وليس لها قيمة تحليلية طويلة الأجل.
      • تحقق من أن البيانات القديمة يمكن تصنيفها بأمان إلى تخزين ثانوي، أو حذفها مباشرة، دون تأثير سلبي على التطبيق.
    • قم بإلغاء تحميل البيانات غير الحرجة إلى التخزين الثانوي البارد، ولكن احتفظ بها للقيمة التحليلية وتلبية متطلبات التدقيق.
    • جمع بيانات تتبع الاستخدام وإحصاءات الاستخدام للنظام الأساسي للبيانات لتمكين فرق DevOps من تقييم متطلبات التدبير المنزلي ومخازن البيانات "بالحجم الصحيح" باستمرار.

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

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

السرعة

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

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

  • مستوى التحميل من خلال استخدام المراسلة غير المتزامنة غير المحظورة، على سبيل المثال باستخدام أنماط CQRS أو مصادر الأحداث .

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

  • تأكد من قابلية التوسع السريع لدعم مستويات معدل النقل والتحميل المتغيرة.

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

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

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

  • مراقبة معدل نقل قراءة وكتابة بيانات التطبيق مقابل متطلبات زمن انتقال P50/P99 ومحاذاة نموذج سعة التطبيق.

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

  • تنفيذ التخزين المؤقت لسيناريوهات البيانات "الفعالة" لتقليل أوقات الاستجابة.

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

متنوعه

  • وفقا لمبدأ التصميم السحابي والأصلي ل Azure، يوصى بشدة بتحديد أولويات خدمات Azure المدارة لتقليل تعقيد التشغيل والإدارة، والاستفادة من استثمارات النظام الأساسي المستقبلية لشركة Microsoft.

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

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

  • تحقق من توفر الإمكانات المطلوبة لتقنيات البيانات المحددة.

    • تأكد من دعم اللغات المطلوبة وقدرات SDK. لا تتوفر كل القدرة لكل لغة/SDK بنفس الطريقة.

صحه

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

    • توزيع النسخ المتماثلة للبيانات عبر مناطق التوفر (AZs) داخل منطقة (أو استخدام مستويات الخدمة المكررة في المنطقة) لزيادة التوفر داخل المنطقة إلى أقصى حد.

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

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

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

  • قم بتشغيل معايير الأداء لضمان عدم تأثر متطلبات معدل النقل والأداء بتضمين قدرات الأمان المطلوبة، مثل التشفير.

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

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

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

ملاحظة

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

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

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

مراجع إضافية

تتوفر إرشادات إضافية للنظام الأساسي للبيانات ضمن دليل بنية تطبيق Azure.

مخزن بيانات الكتابة متعدد المناطق الموزع عالميا

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

هام

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

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

اعتبارات التصميم

Azure Cosmos DB

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

  • يدعم Azure Cosmos DB واجهات برمجة تطبيقات مختلفة متعددة مع مجموعات ميزات مختلفة، مثل SQL وCassandra وMongoDB.

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

  • يدعم Azure Cosmos DB أوضاع الاتصال المباشر والبوابة، حيث يسهل Direct الاتصال عبر TCP بالواجهة الخلفية لعقد النسخ المتماثلة ل Azure Cosmos DB لتحسين الأداء مع عدد أقل من قفزات الشبكة، بينما توفر البوابة اتصال HTTPS بعقد بوابة الواجهة الأمامية.

    • يتوفر الوضع المباشر فقط عند استخدام Azure Cosmos DB ل NoSQL وهو مدعوم حاليا فقط على الأنظمة الأساسية .NET وJava SDK.

  • ضمن المناطق الممكنة لمنطقة التوفر، يوفر Azure Cosmos DB دعم تكرار منطقة التوفر (AZ) لقابلية الوصول العالية والمرونة للفشل المناطقي داخل المنطقة.

  • يحتفظ Azure Cosmos DB بأربع نسخ متماثلة من البيانات داخل منطقة واحدة، وعند تمكين التكرار في منطقة التوفر (AZ)، يضمن Azure Cosmos DB وضع النسخ المتماثلة للبيانات عبر مناطق AZ متعددة للحماية من حالات الفشل المناطقية.

    • يتم تطبيق بروتوكول توافق Paxos لتحقيق الحصة عبر النسخ المتماثلة داخل منطقة.

  • يمكن بسهولة تكوين حساب Azure Cosmos DB لنسخ البيانات نسخا متماثلا عبر مناطق متعددة للتخفيف من مخاطر عدم توفر منطقة واحدة.

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

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

  • يوفر Azure Cosmos DB نهجين لحل التعارض، يمكن تطبيقهما لمعالجة التعارضات تلقائيا.

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

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

    • يوفر النظام الأساسي مخزنا مؤقتا للرسائل لتعارضات الكتابة داخل منطقة المركز لتحميل مستوى وتوفير التكرار للأخطاء العابرة.
      • المخزن المؤقت قادر على تخزين تحديثات الكتابة التي تتطلب توافقا في الآراء لبضع دقائق.

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

  • يتم تحديد منطقة "المركز" الأساسية بواسطة المنطقة الأولى التي تم تكوين Azure Cosmos DB داخلها.

    • يتم تكوين ترتيب الأولوية لمناطق نشر الأقمار الصناعية الإضافية لأغراض تجاوز الفشل.

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

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

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

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

الاتجاه الاستراتيجي للنظام الأساسي Azure Cosmos DB هو تقليل RTO إلى ~5 دقائق عن طريق السماح بتجاوز الفشل على مستوى القسم.

  • أهداف نقطة الاسترداد (RPO) وأهداف وقت الاسترداد (RTO) قابلة للتكوين عبر مستويات التناسق، مع مفاضلة بين متانة البيانات ومعدل النقل.

    • يوفر Azure Cosmos DB الحد الأدنى من RTO من 0 لمستوى تناسق مريح مع عمليات الكتابة متعددة المناطق أو RPO من 0 للاتساق القوي مع منطقة الكتابة الواحدة.

  • يوفر Azure Cosmos DB اتفاقية مستوى الخدمة بنسبة 99.999٪ لكل من توفر القراءة والكتابة لحسابات قاعدة البيانات التي تم تكوينها مع مناطق Azure متعددة على أنها قابلة للكتابة.

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

  • يوفر Azure Cosmos DB اتفاقية مستوى الخدمة بنسبة 99.99٪ لمعدل النقل والاتساق والتوافر وزمن الانتقال لحسابات قاعدة البيانات التي تم تحديد نطاقها لمنطقة Azure واحدة عند تكوينها مع أي من مستويات التناسق الخمسة.

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

  • هناك نوعان من معدل النقل التي يمكن توفيرها في Azure Cosmos DB، القياسية والتحجيم التلقائي، والتي يتم قياسها باستخدام وحدات الطلب في الثانية (RU/s).

    • يخصص معدل النقل القياسي الموارد المطلوبة لضمان قيمة RU/s محددة.
      • تتم فوترة Standard كل ساعة مقابل معدل النقل المقدم.
    • يحدد التحجيم التلقائي الحد الأقصى لقيمة معدل النقل، وسيتوسع Azure Cosmos DB تلقائيا لأعلى أو لأسفل اعتمادا على تحميل التطبيق، بين الحد الأقصى لقيمة معدل النقل و10٪ كحد أدنى من قيمة الحد الأقصى لمعدل النقل.
      • تتم فوترة التحجيم التلقائي كل ساعة مقابل الحد الأقصى لمعدل النقل المستهلك.

  • قد يؤدي معدل النقل الثابت المتوفر مع حمل عمل متغير إلى أخطاء تقييد، مما سيؤثر على توفر التطبيق المتصور.

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

  • عند نسخ Azure Cosmos DB عبر مناطق متعددة، تتم فوترة وحدات الطلب (RUs) المتوفرة لكل منطقة.

  • هناك دلتا تكلفة كبيرة بين تكوين الكتابة متعددة المناطق والكتابة في منطقة واحدة والتي في كثير من الحالات قد تجعل تكلفة النظام الأساسي لبيانات Azure Cosmos DB متعددة المستويات باهظة.

قراءة/كتابة منطقة واحدة كتابة منطقة واحدة - قراءة المنطقة المزدوجة قراءة/كتابة المنطقة المزدوجة
وحدة الطلب 2 وحدة طلب 4 وحدات طلب

دلتا بين الكتابة في منطقة واحدة والكتابة متعددة المناطق هي في الواقع أقل من نسبة 1:2 المنعكسة في الجدول أعلاه. وبشكل أكثر تحديدا، هناك رسوم نقل بيانات عبر المناطق مرتبطة بتحديثات الكتابة في تكوين كتابة واحدة، والتي لا يتم التقاطها ضمن تكاليف RU كما هو الحال مع تكوين الكتابة متعدد المناطق.

  • تتم فوترة التخزين المستهلك كمعدل ثابت لمقدار التخزين الإجمالي (GB) المستهلك لاستضافة البيانات والفهارس لمدة ساعة معينة.

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

  • يدعم Azure Cosmos DB المصادقة عبر هوية Microsoft Entra أو مفاتيح Azure Cosmos DB والرموز المميزة للموارد، والتي توفر إمكانات متداخلة.

قدرات الوصول إلى Azure Cosmos DB قدرات

  • من الممكن تعطيل عمليات إدارة الموارد باستخدام المفاتيح أو الرموز المميزة للموارد للحد من المفاتيح والرموز المميزة للموارد لعمليات البيانات فقط، ما يسمح بالتحكم الدقيق في الوصول إلى الموارد باستخدام Microsoft Entra التحكم في الوصول المستند إلى الدور (RBAC).

    • سيؤدي تقييد الوصول إلى مستوى التحكم عبر المفاتيح أو الرموز المميزة للموارد إلى تعطيل عمليات وحدة التحكم للعملاء الذين يستخدمون Azure Cosmos DB SDKs وبالتالي يجب تقييمها واختبارها بدقة.
    • disableKeyBasedMetadataWriteAccess يمكن تكوين الإعداد عبر تعريفات ARM Template IaC، أو عبر نهج Azure المضمن.

  • ينطبق دعم التحكم في الوصول استنادا إلى الدور Microsoft Entra في Azure Cosmos DB على عمليات إدارة وحدة التحكم في الحساب والموارد.

  • يمكن حماية موارد Azure Cosmos DB (الحسابات وقواعد البيانات والحاويات) من التعديل أو الحذف غير الصحيح باستخدام تأمين الموارد.

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

  • يوفر موجز تغيير Azure Cosmos DB موجزا مرتبا زمنيا للتغييرات على البيانات في حاوية Azure Cosmos DB.

    • يتضمن موجز التغيير فقط عمليات الإدراج والتحديث إلى حاوية Azure Cosmos DB المصدر؛ لا يتضمن عمليات الحذف.

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

    • يمكن استخدام موجز التغيير لملء مخزن ثانوي لتكرار النظام الأساسي للبيانات الإضافي أو للسيناريوهات التحليلية اللاحقة.

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

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

  • يمكن تكوين Azure Cosmos DB كمخزن تحليلي، والذي يطبق تنسيق عمود للاستعلامات التحليلية المحسنة لمعالجة تحديات التعقيد وزمن الانتقال التي تحدث مع مسارات ETL التقليدية.

  • يقوم Azure Cosmos DB تلقائيا بنسخ البيانات احتياطيا على فترات منتظمة دون التأثير على الأداء أو التوفر، ودون استهلاك RU/s.

  • يمكن تكوين Azure Cosmos DB وفقا لوضعين متميزين للنسخ الاحتياطي.

    • الدوري هو وضع النسخ الاحتياطي الافتراضي لجميع الحسابات، حيث يتم أخذ النسخ الاحتياطية في فاصل زمني دوري وتتم استعادة البيانات عن طريق إنشاء طلب مع فريق الدعم.
      • فترة الاحتفاظ بالنسخ الاحتياطي الدورية الافتراضية هي ثماني ساعات والفاصل الزمني الافتراضي للنسخ الاحتياطي هو أربع ساعات، ما يعني أنه يتم تخزين أحدث نسختين احتياطيتين بشكل افتراضي.
      • الفاصل الزمني للنسخ الاحتياطي وفترة الاستبقاء قابلة للتكوين داخل الحساب.
        • يمتد الحد الأقصى لفترة الاستبقاء إلى شهر مع حد أدنى للفاصل الزمني للنسخ الاحتياطي لمدة ساعة واحدة.
        • مطلوب تعيين دور إلى Azure "دور قارئ حساب Cosmos DB" لتكوين تكرار تخزين النسخ الاحتياطي.
      • يتم تضمين نسختين احتياطيتين دون أي تكلفة إضافية، ولكن النسخ الاحتياطية الإضافية تتحمل تكاليف إضافية.
      • بشكل افتراضي، يتم تخزين النسخ الاحتياطية الدورية داخل تخزين Geo-Redundant منفصل (GRS) لا يمكن الوصول إليه مباشرة.
        • يوجد تخزين النسخ الاحتياطي داخل منطقة "المركز" الأساسية ويتم نسخه نسخا متماثلا إلى المنطقة المقترنة من خلال النسخ المتماثل للتخزين الأساسي.
        • تكوين التكرار لحساب تخزين النسخ الاحتياطي الأساسي قابل للتكوين إلى التخزين المتكرر في المنطقة أو تخزين Locally-Redundant.
      • يتطلب تنفيذ عملية استعادة طلب دعم حيث لا يمكن للعملاء إجراء استعادة مباشرة.
        • قبل فتح تذكرة دعم، يجب زيادة فترة استبقاء النسخ الاحتياطي إلى سبعة أيام على الأقل في غضون ثماني ساعات من حدث فقدان البيانات.
      • تنشئ عملية الاستعادة حساب Azure Cosmos DB جديدا حيث يتم استرداد البيانات.
        • لا يمكن استخدام حساب Azure Cosmos DB موجود للاستعادة
        • بشكل افتراضي، سيتم استخدام حساب Azure Cosmos DB جديد باسم <Azure_Cosmos_account_original_name>-restored<n> .
          • يمكن تعديل هذا الاسم، مثل إعادة استخدام الاسم الموجود إذا تم حذف الحساب الأصلي.
      • إذا تم توفير معدل النقل على مستوى قاعدة البيانات، سيحدث النسخ الاحتياطي والاستعادة على مستوى قاعدة البيانات
        • لا يمكن تحديد مجموعة فرعية من الحاويات لاستعادتها.
    • يسمح وضع النسخ الاحتياطي المستمر بالاستعادة إلى أي نقطة زمنية خلال آخر 30 يوما.
      • يمكن إجراء عمليات الاستعادة للعودة إلى نقطة زمنية محددة (PITR) بدقة ثانية واحدة.
      • النافذة المتوفرة لعمليات الاستعادة تصل إلى 30 يوما.
        • من الممكن أيضا الاستعادة إلى حالة إنشاء مثيل المورد.
      • يتم أخذ النسخ الاحتياطية المستمرة داخل كل منطقة Azure حيث يوجد حساب Azure Cosmos DB.
        • يتم تخزين النسخ الاحتياطية المستمرة داخل نفس منطقة Azure مثل كل نسخة متماثلة من Azure Cosmos DB، باستخدام Locally-Redundant Storage (LRS) أو التخزين المتكرر للمنطقة (ZRS) داخل المناطق التي تدعم مناطق التوفر.
      • يمكن إجراء استعادة الخدمة الذاتية باستخدام مدخل Microsoft Azure أو البيانات الاصطناعية IaC مثل قوالب ARM.
      • هناك العديد من القيود مع النسخ الاحتياطي المستمر.
        • وضع النسخ الاحتياطي المستمر غير متوفر حاليا في تكوين الكتابة متعدد المناطق.
        • يمكن تكوين Azure Cosmos DB ل NoSQL وAzure Cosmos DB ل MongoDB فقط للنسخ الاحتياطي المستمر في الوقت الحالي.
        • إذا تم تكوين TTL للحاوية، فقد يتم حذف البيانات المستعادة التي تجاوزت TTL الخاصة بها على الفور
      • تقوم عملية الاستعادة بإنشاء حساب Azure Cosmos DB جديد للاستعادة في نقطة زمنية.
      • هناك تكلفة تخزين إضافية للنسخ الاحتياطية المستمرة وعمليات الاستعادة.

  • يمكن ترحيل حسابات Azure Cosmos DB الحالية من دورية إلى مستمرة، ولكن ليس من مستمر إلى دوري؛ الترحيل أحادي الاتجاه ولا يمكن عكسه.

  • تتكون كل نسخة احتياطية من Azure Cosmos DB من البيانات نفسها وتفاصيل التكوين لمعدل النقل المتوفر ونهج الفهرسة ومنطقة (مناطق) التوزيع وإعدادات TTL للحاوية.

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

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

  • تشير وثائق Azure Cosmos DB إلى خيارين محتملين لتنفيذ النسخ الاحتياطية المخصصة.

    • موجز تغيير Azure Cosmos DB لكتابة البيانات إلى منشأة تخزين منفصلة.
    • يمكن تنفيذ كل من النسخ الاحتياطية المخصصة المستمرة أو الدورية (المجمعة) باستخدام موجز التغيير.
    • لا يعكس موجز تغيير Azure Cosmos DB عمليات الحذف بعد، لذلك يجب تطبيق نمط الحذف المبدئي باستخدام خاصية منطقية وTL.
      • لن يكون هذا النمط مطلوبا عندما يوفر موجز التغيير تحديثات كاملة الدقة.
    • موصل Azure Data Factory ل Azure Cosmos DB (Azure Cosmos DB لموصلات NoSQL أو MongoDB API ) لنسخ البيانات.
      • يدعم Azure Data Factory (ADF) التنفيذ اليدوي والجدول الزمني ونافذة التدوير والمشغلات المستندة إلى الحدث .
        • يوفر الدعم لكل من التخزين وشبكة الأحداث.
      • ADF مناسب بشكل أساسي لتنفيذات النسخ الاحتياطي المخصصة الدورية بسبب تنسيقه الموجه نحو الدفعات.
        • إنها أقل ملاءمة لتنفيذات النسخ الاحتياطي المستمر مع الأحداث المتكررة بسبب حمل تنفيذ التنسيق.
      • يدعم ADF Azure Private Link لسيناريوهات أمان الشبكة العالية

يتم استخدام Azure Cosmos DB في تصميم العديد من خدمات Azure، لذلك سيكون للانقطاع الإقليمي الكبير ل Azure Cosmos DB تأثير متتالي عبر خدمات Azure المختلفة داخل تلك المنطقة. سيعتمد التأثير الدقيق على خدمة معينة بشكل كبير على كيفية استخدام تصميم الخدمة الأساسي ل Azure Cosmos DB.

توصيات التصميم

Azure Cosmos DB

  • استخدم Azure Cosmos DB كمنصة بيانات أساسية حيث تسمح المتطلبات.

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

    • قم بتكوين التطبيق لتحديد أولويات استخدام النسخة المتماثلة المحلية من Azure Cosmos DB للكتابات والقراءات لتحسين تحميل التطبيق والأداء واستهلاك RU/s الإقليمي.
    • يأتي تكوين الكتابة متعددة المناطق بتكلفة كبيرة ويجب تحديد أولوياته فقط لسيناريوهات حمل العمل التي تتطلب أقصى قدر من الموثوقية.

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

    • قم بتكوين التطبيق لاستخدام النسخة المتماثلة المحلية لقراءة Azure Cosmos DB لتحسين أداء القراءة.

  • حدد منطقة توزيع "مركز" مثالية حيث سيحدث حل التعارض في تكوين كتابة متعدد المناطق، وسيتم تنفيذ جميع عمليات الكتابة في تكوين كتابة منطقة واحدة.

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

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

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

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

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

يتم حساب Azure Cosmos DB SLA بواسطة متوسط الطلبات الفاشلة، والتي قد لا تتوافق مباشرة مع ميزانية خطأ طبقة الموثوقية بنسبة 99.999٪. عند التصميم ل SLO بنسبة 99.999٪، لذلك من الضروري التخطيط لعدم توفر الكتابة في Azure Cosmos DB إقليميا ومتعددة المناطق، ما يضمن وضع تقنية تخزين احتياطية في حالة حدوث فشل، مثل قائمة انتظار الرسائل المستمرة لإعادة التشغيل اللاحق.

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

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

  • حدد مفتاح قسم مثالي.

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

  • تعد الفهرسة أيضا أمرا بالغ الأهمية للأداء، لذا تأكد من استخدام استثناءات الفهرس لتقليل RU/s ومتطلبات التخزين.

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

  • استفد من قدرات معالجة الأخطاء المضمنة وإعادة المحاولة والموثوقية الأوسع ل Azure Cosmos DB SDK.

  • استخدم مفاتيح التشفير المدارة بواسطة الخدمة لتقليل تعقيد الإدارة.

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

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

  • تمكين Azure Monitor لجمع المقاييس الرئيسية وسجلات التشخيص، مثل معدل النقل المقدم (RU/s).

    • توجيه البيانات التشغيلية ل Azure Monitor إلى مساحة عمل Log Analytics مخصصة ل Azure Cosmos DB والموارد العمومية الأخرى ضمن تصميم التطبيق.
    • استخدم مقاييس Azure Monitor لتحديد ما إذا كانت أنماط نسبة استخدام الشبكة للتطبيق مناسبة للتحجيم التلقائي.

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

    • ضع في اعتبارك معدل النقل المخصص للتحجيم التلقائي لتلبية الطلب على حمل العمل تلقائيا.

  • تقييم نصائح أداء Microsoft ل Azure Cosmos DB لتحسين التكوين من جانب العميل والخادم لتحسين زمن الانتقال ومعدل النقل.

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

  • بالنسبة لعمليات توزيع منطقة الكتابة الواحدة، يوصى بشدة بتكوين Azure Cosmos DB لتجاوز الفشل التلقائي.

  • مستوى التحميل من خلال استخدام المراسلة غير المتزامنة غير المحظورة داخل تدفقات النظام، والتي تكتب التحديثات إلى Azure Cosmos DB.

  • قم بتكوين حساب Azure Cosmos DB للنسخ الاحتياطية المستمرة للحصول على دقة دقيقة لنقاط الاسترداد خلال آخر 30 يوما.

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

  • يوصى بشدة بممارسة إجراءات الاسترداد على الموارد والبيانات غير الإنتاجية، كجزء من إعداد عملية استمرارية الأعمال القياسية.

  • حدد البيانات الاصطناعية IaC لإعادة إنشاء إعدادات التكوين وقدرات استعادة النسخ الاحتياطي ل Azure Cosmos DB.

  • تقييم وتطبيق إرشادات التحكم في أساس أمان Azure للنسخ الاحتياطي والاسترداد في Azure Cosmos DB.

  • بالنسبة لأحمال العمل التحليلية التي تتطلب توفرا متعدد المناطق، استخدم مخزن Azure Cosmos DB التحليلي، الذي يطبق تنسيق عمود للاستعلامات التحليلية المحسنة.

تقنيات البيانات الارتباطية

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

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

اعتبارات التصميم

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

  • يمكن تطبيق التقسيم لتوزيع البيانات والمعالجة عبر قواعد بيانات منظمة متطابقة متعددة، وتقسيم قواعد البيانات أفقيا للتنقل في قيود النظام الأساسي.

    • على سبيل المثال، غالبا ما يتم تطبيق التقسيم في أنظمة SaaS الأساسية متعددة المستأجرين لعزل مجموعات المستأجرين في بنيات النظام الأساسي للبيانات المميزة.

قاعدة بيانات Azure SQL

  • توفر قاعدة بيانات Azure SQL محرك قاعدة بيانات مدار بالكامل يعمل دائما على أحدث إصدار مستقر من محرك قاعدة البيانات SQL Server ونظام التشغيل الأساسي.

    • يوفر ميزات ذكية مثل ضبط الأداء ومراقبة التهديدات وتقييمات الثغرات الأمنية.

  • توفر قاعدة بيانات Azure SQL توفرا إقليميا عاليا مضمنا ونسخا جغرافيا متماثلا تسليم المفتاح لتوزيع النسخ المتماثلة للقراءة عبر مناطق Azure.

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

  • توفر قاعدة بيانات Azure SQL مجموعات تجاوز الفشل التلقائي، والتي تنسخ قواعد البيانات إلى خادم ثانوي وتسمح بتجاوز الفشل الشفاف إذا حدث فشل.

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

  • يمكن توزيع النسخ المتماثلة لقاعدة بيانات طبقة الخدمة Premium أو Business Critical عبر مناطق التوفر دون أي تكلفة إضافية.

    • يتم أيضا تكرار حلقة التحكم عبر مناطق متعددة كثلاث حلقات بوابة (GW).
      • يتم التحكم في التوجيه إلى حلقة بوابة معينة بواسطة Azure Traffic Manager.
    • عند استخدام طبقة "الأعمال الحرجة"، يتوفر تكوين المنطقة المكرر فقط عند تحديد جهاز حاسب Gen5.

  • توفر قاعدة بيانات Azure SQL اتفاقية مستوى خدمة توفر أساسية بنسبة 99.99٪ عبر جميع مستويات الخدمة الخاصة بها، ولكنها توفر اتفاقية مستوى خدمة أعلى بنسبة 99.995٪ لمستويات الأعمال الحرجة أو المتميزة في المناطق التي تدعم مناطق التوفر.

    • مستويات Azure SQL Database Business Critical أو Premium غير المكونة لعمليات التوزيع المتكررة في المنطقة لها اتفاقية مستوى خدمة توفر بنسبة 99.99٪.

  • عند تكوينه باستخدام النسخ المتماثل الجغرافي، يوفر مستوى Azure SQL Database Business Critical هدف وقت الاسترداد (RTO) لمدة 30 ثانية لمدة 100٪ من الساعات المنشورة.

  • عند تكوينه باستخدام النسخ المتماثل الجغرافي، يحتوي المستوى Azure SQL Database Business Critical على هدف نقطة الاسترداد (RPO) لمدة 5 ثوان لمدة 100٪ من الساعات المنشورة.

  • طبقة Hyperscale لقاعدة بيانات Azure SQL، عند تكوينها باستخدام نسختين متماثلتين على الأقل، لديها اتفاقية مستوى خدمة توفر بنسبة 99.99٪.

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

    • لا يمكن تطبيق السعة المحجوزة لقواعد البيانات المستندة إلى DTU.

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

  • يمكن استخدام الاستعادة الجغرافية لاسترداد قاعدة بيانات من نسخة احتياطية جغرافية زائدة عن الحاجة.

قاعدة بيانات Azure ل PostgreSQL

  • يتم تقديم قاعدة بيانات Azure ل PostgreSQL في ثلاثة خيارات توزيع مختلفة:

    • خادم واحد، اتفاقية مستوى الخدمة 99.99٪
    • الخادم المرن، الذي يوفر تكرار منطقة التوفر، SLA 99.99٪
    • Hyperscale (Citus)، SLA 99.95٪ عند تمكين وضع قابلية الوصول العالية.

  • يوفر Hyperscale (Citus) قابلية توسع ديناميكية من خلال التقسيم دون تغييرات التطبيق.

    • يعد توزيع صفوف الجدول عبر خوادم PostgreSQL المتعددة أمرا أساسيا لضمان استعلامات قابلة للتطوير في Hyperscale (Citus).
    • يمكن أن تحتوي العقد المتعددة بشكل جماعي على بيانات أكثر من قاعدة البيانات التقليدية، وفي كثير من الحالات يمكن استخدام وحدات المعالجة المركزية العاملة بالتوازي لتحسين التكاليف.

  • يمكن تكوين التحجيم التلقائي من خلال أتمتة دفتر التشغيل لضمان المرونة استجابة لأنماط نسبة استخدام الشبكة المتغيرة.

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

  • لا توجد رسوم إضافية لتخزين النسخ الاحتياطي لما يصل إلى 100٪ من إجمالي تخزين الخادم المقدم.

    • يتم فرض رسوم على الاستهلاك الإضافي لتخزين النسخ الاحتياطي وفقا للجيجابايت/الشهر المستهلك.

  • يمكن تقليل تكاليف الحوسبة المرتبطة بقاعدة بيانات Azure ل PostgreSQL باستخدام خصم حجز خادم واحد أو خصم حجز Hyperscale (Citus).

توصيات التصميم

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

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

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

قاعدة بيانات Azure SQL

  • استخدم مستوى خدمة Business-Critical لزيادة الموثوقية والتوافر إلى أقصى حد، بما في ذلك الوصول إلى قدرات المرونة الحرجة.

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

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

  • قم بتكوين نموذج توزيع Zone-Redundant لنشر النسخ المتماثلة لقاعدة بيانات Business Critical داخل نفس المنطقة عبر مناطق التوفر.

  • استخدم النسخ المتماثل الجغرافي النشط لنشر النسخ المتماثلة القابلة للقراءة داخل جميع مناطق التوزيع (حتى أربعة).

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

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

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

هام

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

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

  • استخدم Azure Monitor وAzure SQL Analytics للحصول على رؤى تشغيلية في الوقت الفعلي تقريبا في Azure SQL DB للكشف عن حوادث الموثوقية.

  • استخدم Azure Monitor لتقييم الاستخدام لجميع قواعد البيانات لتحديد ما إذا كان قد تم تغيير حجمها بشكل مناسب.

    • تأكد من أن مسارات CD تفكر في اختبار التحميل ضمن مستويات التحميل التمثيلية للتحقق من صحة سلوك النظام الأساسي للبيانات المناسب.

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

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

  • تحسين الاستعلامات والجداول وقواعد البيانات باستخدام Query Performance Insightsوتوصيات الأداء الشائعة التي توفرها Microsoft.

  • تنفيذ منطق إعادة المحاولة باستخدام SDK للتخفيف من الأخطاء العابرة التي تؤثر على اتصال قاعدة بيانات Azure SQL.

  • تحديد أولويات استخدام المفاتيح المدارة بواسطة الخدمة عند تطبيق تشفير البيانات الشفافة من جانب الخادم (TDE) للتشفير الثابت.

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

  • ضع في اعتبارك استخدام الاستعادة في نقطة زمنية كدليل مبادئ تشغيلي للتعافي من أخطاء التكوين الحادة.

قاعدة بيانات Azure ل PostgreSQL

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

  • عند استخدام Hyperscale (Citus) لأحمال العمل المهمة للأعمال، قم بتمكين وضع قابلية الوصول العالية لتلقي ضمان اتفاقية مستوى الخدمة بنسبة 99.95٪ .

  • استخدم تكوين خادم Hyperscale (Citus) لتحقيق أقصى قدر من التوفر عبر عقد متعددة.

  • حدد نموذج سعة للتطبيق لإعلام متطلبات موارد الحوسبة والتخزين داخل النظام الأساسي للبيانات.

التخزين المؤقت لبيانات الطبقة الساخنة

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

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

الاعتبارات المتعلقة بالتصميم

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

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

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

  • ذاكرة التخزين المؤقت Redis هي نظام تخزين مصدر مفتوح قيمة مفتاح NoSQL في الذاكرة.

  • يمكن نشر مستويات Enterprise وEnterprise Flash في تكوين نشط-نشط عبر مناطق التوفر داخل منطقة ومناطق Azure مختلفة من خلال النسخ المتماثل الجغرافي.

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

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

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

  • لا تتضمن ميزة التحديثات المجدولة تحديثات Azure أو التحديثات المطبقة على نظام تشغيل الجهاز الظاهري الأساسي.

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

توصيات التصميم

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

  • تطبيق النهج المناسبة لانتهاء صلاحية ذاكرة التخزين المؤقت والصيانة المنزلية لتجنب نمو البيانات الهاربة.

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

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

  • استخدم Premium أو Enterprise SKU لزيادة الموثوقية والأداء إلى أقصى حد.

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

  • نشر مثيلات النسخ المتماثلة باستخدام النسخ المتماثل الجغرافي في تكوين نشط عبر جميع مناطق النشر المدروسة.

  • تأكد من نشر مثيلات النسخ المتماثلة عبر مناطق التوفر داخل كل منطقة Azure مراعية.

  • استخدم Azure Monitor لتقييم Azure Cache for Redis.

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

  • تحسين مرونة الاتصال من خلال تنفيذ منطق إعادة المحاولة والمهلات واستخدام تنفيذ أحادي لمضاعف اتصال Redis.

  • تكوين التحديثات المجدولة لوصف الأيام والأوقات التي يتم فيها تطبيق تحديثات Redis Server على ذاكرة التخزين المؤقت.

السيناريوهات التحليلية

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

تتطلب أحمال العمل التحليلية وأحمال العمل للمعاملات قدرات وتحسينات مختلفة للنظام الأساسي للبيانات للأداء المقبول داخل سياقات كل منها.

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

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

الاعتبارات المتعلقة بالتصميم

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

Azure Cosmos DB

  • عادة ما يتم تجميع الاستعلامات التحليلية التي تعمل على بيانات معاملات Azure Cosmos DB عبر الأقسام على كميات كبيرة من البيانات، مما يستهلك معدل نقل كبير لوحدة الطلب (RU)، مما يمكن أن يؤثر على أداء أحمال عمل المعاملات المحيطة.

  • يوفر مخزن Azure Cosmos DB التحليلي مخزن بيانات مخطط ومعزول بالكامل موجه للعمود يتيح تحليلات واسعة النطاق على بيانات Azure Cosmos DB من Azure Synapse دون التأثير على أحمال عمل معاملات Azure Cosmos DB.

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

  • باستخدام Azure Synapse Link، يمكن الاستعلام عن مخزن Azure Cosmos DB التحليلي مباشرة من Azure Synapse. يتيح ذلك معالجة Transactional-Analytical المختلط (HTAP) من Synapse، بحيث يمكن الاستعلام عن بيانات Azure Cosmos DB مع أحمال العمل التحليلية الأخرى من Synapse في الوقت الفعلي تقريبا.

  • لا يتم تقسيم مخزن Azure Cosmos DB التحليلي بشكل افتراضي.

    • بالنسبة لسيناريوهات استعلام معينة، سيتحسن الأداء عن طريق تقسيم بيانات المخزن التحليلي باستخدام المفاتيح التي تستخدم بشكل متكرر في دالات تقييم الاستعلام.
    • يتم تشغيل التقسيم بواسطة وظيفة في Azure Synapse تقوم بتشغيل دفتر ملاحظات Spark باستخدام Synapse Link، والذي يقوم بتحميل البيانات من مخزن Azure Cosmos DB التحليلي وكتابتها في مخزن Synapse المقسم في حساب التخزين الأساسي لمساحة عمل Synapse.

  • يمكن لتجمعات Azure Synapse Analytics SQL Serverless الاستعلام عن المخزن التحليلي من خلال طرق العرض المحدثة تلقائيا أو عبر SELECT / OPENROWSET الأوامر.

  • يمكن لتجمعات Azure Synapse Analytics Spark الاستعلام عن المخزن التحليلي من خلال جداول Spark المحدثة spark.read تلقائيا أو الأمر .

  • يمكن أيضا نسخ البيانات من مخزن Azure Cosmos DB التحليلي إلى تجمع Synapse SQL مخصص باستخدام Spark، بحيث يمكن استخدام موارد تجمع Azure Synapse SQL المتوفرة.

  • يمكن الاستعلام عن بيانات مخزن Azure Cosmos DB التحليلي باستخدام Azure Synapse Spark.

    • تسمح دفاتر ملاحظات Spark لمجموعات إطار بيانات Spark بتجميع وتحويل البيانات التحليلية ل Azure Cosmos DB مع مجموعات البيانات الأخرى، واستخدام وظائف Synapse Spark المتقدمة الأخرى بما في ذلك كتابة البيانات المحولة إلى مخازن أخرى أو تدريب نماذج التعلم الآلي من AIOps.

مخزن الأعمدة التحليلية ل Azure Cosmos DB Azure

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

Azure Synapse

  • يجمع Azure Synapse إمكانات التحليلات بما في ذلك تخزين بيانات SQL وبيانات Spark الضخمة ومستكشف البيانات لتحليلات السجل والسلاسل الزمنية.

    • يستخدم Azure Synapse الخدمات المرتبطة لتعريف الاتصالات بخدمات أخرى، مثل Azure Storage.
    • يمكن استيعاب البيانات في Synapse Analytics عبر نشاط النسخ من المصادر المدعومة. يسمح هذا لتحليل البيانات في Synapse دون التأثير على مخزن البيانات المصدر، ولكنه يضيف الوقت والتكلفة وزمن الانتقال الزائد بسبب نقل البيانات.
    • يمكن أيضا الاستعلام عن البيانات في مكانها في مخازن خارجية مدعومة، ما يتجنب الحمل الزائد لاستيعاب البيانات وحركتها. تخزين Azure مع Data Lake Gen2 هو مخزن مدعوم للبيانات المصدرة Synapse وLog Analytics يمكن الاستعلام عن طريق Synapse Spark.

  • يوحد Azure Synapse Studio مهام الاستيعاب والاستعلام.

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

Azure Synapse Analytics

توصيات التصميم

  • تأكد من أن أحمال العمل التحليلية لا تؤثر على أحمال عمل تطبيق المعاملات للحفاظ على أداء المعاملات.

تحليلات التطبيق

AIOps والتحليلات التشغيلية

  • إنشاء مساحة عمل Azure Synapse واحدة مع الخدمات المرتبطة ومجموعات البيانات لكل حساب تخزين Azure مصدر حيث يتم إرسال البيانات التشغيلية من الموارد إليها.

  • إنشاء حساب Azure Storage مخصص واستخدامه كحساب تخزين أساسي لمساحة العمل لتخزين بيانات كتالوج مساحة عمل Synapse وبيانات التعريف. قم بتكوينه باستخدام مساحة اسم هرمية لتمكين Azure Data Lake Gen2.

    • الحفاظ على الفصل بين البيانات التحليلية المصدر وبيانات مساحة عمل Synapse وبيانات التعريف.
      • لا تستخدم أحد حسابات Azure Storage الإقليمية أو العالمية حيث يتم إرسال البيانات التشغيلية.

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

راجع اعتبارات اعتبارات الشبكات.

الشبكة والاتصال