ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تعرف على كيفية الحصول على أفضل أداء أثناء العمل مع Azure Database for MySQL Flexible Server. نظرًا لأننا نضيف إمكانات جديدة إلى النظام الأساسي، فسنواصل تحسين توصياتنا في هذا القسم.
القرب الفعلي
تأكد من توزيع تطبيق وقاعدة البيانات في نفس المنطقة. الفحص السريع قبل بدء أي تشغيل لمعيار تقييم الأداء هو تحديد زمن انتقال الشبكة بين العميل وقاعدة البيانات باستخدام استعلام SELECT 1 بسيط.
عند تشغيل موارد مثل تطبيق ويب وقاعدة البيانات المرتبطة به في مناطق مختلفة، فقد يكون هناك زمن انتقال متزايد في الاتصال بين هذه الموارد. هناك تأثير جانبي آخر محتمل لوجود التطبيق وقاعدة البيانات في مناطق منفصلة يتعلق بتكاليف نقل البيانات الصادرة.
لتحسين أداء التطبيق وموثوقيته في توزيع محسن للتكلفة، يوصى بشدة بأن تكون خدمة تطبيق الويب ومورد Azure Database for MySQL Flexible Server في نفس المنطقة ومنطقة التوفر. هذا الموقع المشترك هو الأفضل للتطبيقات الحساسة لوقت الاستجابة، كما أنه يوفر أفضل معدل نقل، حيث يتم إقران الموارد بشكل وثيق.
شبكات مسرعة
استخدم شبكة مسرعة لخادم التطبيق إذا كنت تستخدم جهاز Azure الظاهري أو Azure Kubernetes أو خدمات التطبيقات. تُمكن الشبكات المُعجلة من افتراضية الجذر المفرد الإدخال/إخراج (SR-IOV) إلى جهاز ظاهري، ما يحسن أداء الشبكات بشكل كبير. يتخطى هذا المسار عالي الأداء المضيف من مسار البيانات، ما يقلل من زمن الوصول والارتعاش واستخدام وحدة المعالجة المركزية، للاستخدام مع أعباء عمل الشبكة الأكثر تطلبًا على أنواع VM المدعومة.
كفاءة الاتصال
إنشاء اتصال جديد هو دائماً مهمة مكلفة وتستغرق وقتاً طويلاً. عندما يطلب تطبيق اتصال قاعدة بيانات، فإنه يعطي الأولوية لتخصيص اتصالات قاعدة البيانات الخاملة الموجودة بدلاً من إنشاء اتصال جديد. فيما يلي بعض الخيارات لممارسات الاتصال الجيدة:
ProxySQL: استخدم ProxySQL الذي يوفر تجميع اتصال مضمن وموازنة تحميل حمل العمل الخاص بك إلى نسخ متماثلة متعددة للقراءة كما هو مطلوب عند الطلب مع أي تغييرات في التعليمات البرمجية للتطبيق.
وكيل بيانات Heimdall: بدلاً من ذلك، يمكنك أيضًا الاستفادة من وكيل بيانات Heimdall، وهو حل وكيل خاص محايد للمورد. وهو يدعم التخزين المؤقت للاستعلام وتقسيم القراءة/الكتابة مع الكشف عن تأخر النسخ المتماثل. يمكنك أيضاً الرجوع إلى كيفية تسريع أداء MySQL باستخدام وكيل Heimdall.
اتصال مستمر أو طويل الأجل: إذا كان التطبيق الخاص بك يحتوي على معاملات قصيرة أو استعلامات عادة مع وقت تنفيذ< 5-10 مللي ثانية، فاستبدل الاتصالات القصيرة باتصالات مستمرة. يتطلب استبدال الاتصالات القصيرة بالاتصالات المستمرة تغييرات طفيفة فقط على التعليمات البرمجية، ولكن له تأثير كبير من حيث تحسين الأداء في العديد من سيناريوهات التطبيق النموذجية. تأكد من تعيين المهلة أو الاتصال الوثيق عند اكتمال المعاملة.
النسخة المتماثلة: إذا كنت تستخدم النسخة المتماثلة، فاستخدم ProxySQL لموازنة التحميل بين الخادم الأساسي وخادم النسخة المتماثلة الثانوية القابلة للقراءة. تعرف على كيفية إعداد ProxySQL.
تجمّعات الاتصال
تجميع الاتصال هو آلية تدير إنشاء وتخصيص اتصالات قاعدة البيانات وتحمي قاعدة البيانات من زيادة الاتصال. ضع في اعتبارك تجميع الاتصالات إذا فتح التطبيق الخاص بك العديد من الاتصالات في وقت قصير نسبيًا وكانت الاتصالات قصيرة العمر. قد تحدث هذه الأنواع من الاتصالات، على سبيل المثال، على مدى مئات أو آلاف في الثانية، والوقت المستغرق لتأسيسها وإغلاقها مهم مقارنةً بإجمالي عمر الاتصال.
إذا كان إطار عمل تطوير التطبيق الخاص بك لا يدعم تجميع الاتصال، فاستخدم بدلا من ذلك وكيل اتصال، مثل ProxySQL أو Heimdall proxy، بين التطبيق وخادم قاعدة البيانات.
معالجة تحجيم الاتصال
من الأساليب الشائعة لتوسيع نطاق تطبيقات الويب لتلبية الطلب المتقلب إضافة خوادم التطبيقات وإزالتها. يمكن لكل خادم تطبيق استخدام تجمع اتصال مع قاعدة البيانات. يؤدي هذا الأسلوب إلى زيادة العدد الإجمالي للاتصالات على خادم قاعدة البيانات بالنسبة إلى عدد خوادم التطبيق. على سبيل المثال، إذا كان خادم قاعدة البيانات يحتوي على 10 خوادم تطبيق وتم تكوين كل منها لـ 100 اتصال قاعدة بيانات، فسيوفر ذلك 1000 اتصال بقاعدة البيانات. إذا كان حجم عمل التطبيق يتوسع بسبب زيادة نشاط المستخدم أو خلال ساعات الذروة وإذا تمت إضافة 50 خادم تطبيق إضافي، فسيبلغ إجمالي عدد اتصالات قاعدة البيانات 6000. عادةً، ستكون معظم هذه الاتصالات خاملة، بعد أن تولدها خوادم التطبيق. نظرا لأن الاتصالات الخاملة تستهلك الموارد (الذاكرة وCPU) للبقاء مفتوحة، فقد تتأثر قابلية توسع قاعدة البيانات.
تتضمن التحديات المحتملة الإضافية معالجة العدد الإجمالي للاتصالات بخادم قاعدة البيانات. يتم تحديد ذلك من خلال عدد خوادم التطبيقات المتصلة بخادم قاعدة البيانات، حيث يقوم كل منها بإنشاء مجموعة الاتصالات الخاصة به. في هذه السيناريوهات، ضع في اعتبارك تعديل تجمعات الاتصال على خوادم التطبيق. حاول تقليل عدد الاتصالات في كل تجمع إلى الحد الأدنى المقبول للتأكد من عدم وجود انتفاط في الاتصالات على جانب خادم قاعدة البيانات. اعتبر هذا علاجًا قصير المدى لمواجهة آثار توسيع نطاق خادم التطبيق بدلاً من حل دائم لمعالجة نمو التطبيق.
كحل طويل المدى، أدخل وكيل اتصال، مثل ProxySQL أو وكيل Heimdall، بين خادم قاعدة البيانات وخادم التطبيق. يساعد هذا لأن الوكيل سيقوم بما يلي:
- إنشاء اتصال بخادم قاعدة البيانات بعدد ثابت من الاتصالات.
- قبول اتصالات التطبيق والعمل كمخزن مؤقت لعواصف الاتصال المحتملة.
يمكن أن توفر الوكلاء ميزات أخرى مثل التخزين المؤقت للاستعلام والتخزين المؤقت للاتصال وإعادة كتابة / توجيه الاستعلام وموازنة التحميل. لمزيد من قابلية التوسع، ضع في اعتبارك استخدام مثيلات وكيل متعددة.
معالجة الاتصال للتسامح مع الخطأ واسترداد أسرع
عند تصميم التطبيقات والبيئة الخاصة بك للتسامح مع الخطأ واسترداد أسرع، ضع في اعتبارك أنه في بيئة قاعدة البيانات، من المحتمل أن تواجه انقطاعات في الاتصال أو فشل الأجهزة. تذكر أيضًا الحاجة إلى إجراءات تشغيلية مثل قياس أحجام المثيلات والتصحيح وتنفيذ تجاوز الفشل اليدوي.
على سبيل المثال، ضع في اعتبارك سيناريو يكمل فيه خادم قاعدة البيانات تجاوز الفشل في غضون دقيقة، ولكن التطبيق الخاص بك معطل لعدة دقائق أطول بسبب أشياء مثل DNS TTL الذي يكون طويلاً جدًا على جانب التطبيق. في هذه الحالات، سيؤدي تقليل قيمة TTL ببساطة إلى توفير استرداد أسرع، أو يمكن أن يساعد دمج وكيل اتصال بين التطبيق وخادم قاعدة البيانات في معالجة مثل هذه الإخفاقات.
القسم
عندما يستخدم حمل الإنتاج لديك جداول كبيرة للغاية، فإن التقسيم يعد طريقة رائعة لتحسين أداء قاعدة البيانات وتسهيل الصيانة. يجعل التقسيم من السهل إدارة الجداول الكبيرة، ويسمح لك هذا الأسلوب بإضافة أقسام وإفلاتها لإدارة الجداول الكبيرة بشكل فعال. يمكن أن يساعد التقسيم أيضًا على توسيع نطاق المحرك عن طريق التخفيف من التنازع الداخلي على الهيكل مثل الأقفال الداخلية لكل جدول أو لكل فهرس (على سبيل المثال، ضع في اعتبارك btr_search_latch في InnoDB).
بإضافة خمسة أقسام، على سبيل المثال، تقوم بشكل أساسي بتقسيم جدول كبير به نشاط كبير إلى خمسة جداول أصغر وأكثر كفاءة. سيساعد هذا بشكل أساسي في الحالات التي تكون فيها العملية الرئيسية هي عمليات البحث عن المفتاح الأساسي على الجدول، بحيث يمكن للاستعلامات الاستفادة من "تشذيب القسم". لكن التقسيم يمكن أن يساعد أيضًا من حيث فحص الجداول.
في حين أن التقسيم له فوائده، فإنه يحتوي أيضا على بعض القيود، مثل عدم وجود دعم للمفاتيح الخارجية في الجداول المقسمة، وعدم وجود ذاكرة التخزين المؤقت للاستعلام، وما إلى ذلك. للحصول على قائمة كاملة بهذه القيود، في الدليل المرجعي MySQL، راجع الفصل القيود والقيود على التقسيم.
فصل القراءات والكتابة
تقرأ معظم التطبيقات بشكل أساسي من قاعدة البيانات، مع وجود نسبة صغيرة فقط من التفاعلات التي تتضمن عمليات كتابة. من المحتمل أن يتضمن عدد الاتصالات النشطة على قاعدة البيانات الأساسية التي حسبناها لمجموعات الاتصال نسبة القراءة. يؤدي إلغاء تحميل أكبر عدد ممكن من الاستعلامات لقراءة النسخ المتماثلة قدر الإمكان والحفاظ على الوصول إلى المثيل الأساسي القابل للكتابة إلى زيادة مقدار نشاط قاعدة البيانات الإجمالي الذي تقوم به خوادم التطبيق دون زيادة الحمل على قاعدة البيانات الأساسية. إذا كنت لا تصل بالفعل إلى النسخ المتماثلة للقراءة على الأقل لاستعلامات أطول قيد التشغيل مثل التقارير، يجب أن تفكر في نقل التقارير أو التحليلات على الفور لقراءة النسخ المتماثلة.
قد يتطلب الاستخدام الأوسع نطاقا للنسخ المتماثلة للقراءة دراسة أكثر دقة، حيث تتخلف النسخ المتماثلة قليلا عن النسخة الأساسية بسبب الطبيعة غير المتزامنة للنسخ المتماثل. ابحث عن أكبر عدد ممكن من مناطق التطبيق التي يمكن تقديمها بقراءات من النسخ المتماثلة مع تغييرات طفيفة في التعليمات البرمجية. يجب عليك أيضًا تطبيق هذه الطريقة على مستويات أعلى فيما يتعلق بالتخزين المؤقت - تقديم المزيد من المحتوى للقراءة فقط أو تغيير المحتوى ببطء من طبقة تخزين مؤقت مخصصة مثل Azure Cache for Redis.
كتابة التحجيم والتقسيم
مع مرور الوقت، تتطور التطبيقات، وتضاف وظائف جديدة. بدافع الراحة أو الممارسة العامة، يتم إضافة الجداول إلى قاعدة البيانات الأساسية. للتعامل مع أحمال المرور المتزايدة على قاعدة بيانات، حدد مناطق التطبيق التي يمكن نقلها بسهولة إلى قواعد بيانات منفصلة وفكر في تجزئة قاعدة البيانات أفقيًا أو تقسيمها رأسيًا.
تعمل التجزئة الأفقية لقاعدة البيانات عن طريق إنشاء نسخ متعددة من مخطط التطبيق في قواعد بيانات منفصلة وفصل العملاء وجميع البيانات المرتبطة بناءً على معرف العميل أو الموقع الجغرافي أو بعض السمات الأخرى لكل عميل أو مستأجر. يعمل هذا بشكل جيد للغاية مع تطبيقات SaaS أو B2C حيث يكون العملاء الأفراد صغارًا ويكون الحمل على التطبيق ناتجًا عن الاستخدام الكلي لملايين العملاء. ومع ذلك، من الصعب مع تطبيقات B2B التي يكون فيها العملاء أحجاما مختلفة وقد يهيمن العملاء الكبار الفرديون على حمل نسبة استخدام الشبكة لجزء معين.
تقسيم الحمل عموديًا عن طريق تقسيم قاعدة البيانات وظيفيًا - نقل مجالات التطبيق المنفصلة (أو الخدمات الصغيرة) إلى قواعد البيانات الخاصة بهم. هذا يوزع الحمل من قاعدة البيانات الأساسية لفصل قواعد البيانات لكل خدمة. تتضمن الأمثلة البسيطة جدول التسجيل أو معلومات تكوين الموقع التي لا تحتاج إلى أن تكون في نفس قاعدة البيانات مثل جدول الطلبات المحملة بكثافة. تتضمن الأمثلة الأكثر تعقيدًا كسر مجالات العميل والحساب بصرف النظر عن مجالات الطلبات أو التنفيذ. في بعض الحالات، قد يتطلب هذا تغييرات في التطبيق، على سبيل المثال لتعديل قوائم انتظار مهام البريد الإلكتروني أو الخلفية لتكون قائمة بذاتها وعدم الاعتماد على الصلات مرة أخرى إلى عميل أو جدول طلب. يمكن تنفيذ نقل الجداول والبيانات الموجودة إلى قاعدة بيانات أساسية جديدة مع قاعدة بيانات Azure لخادم MySQL المرن وقراءة النسخ المتماثلة وتعزيز النسخة المتماثلة وتشير أجزاء من التطبيق إلى قاعدة البيانات القابلة للكتابة التي تم إنشاؤها حديثا. تحتاج قاعدة البيانات التي تم إنشاؤها حديثًا إلى تقييد الوصول إلى تجمعات الاتصال واستعلامات الضبط وتوزيع التحميل باستخدام النسخ المتماثلة الخاصة بها تمامًا مثل الأساسي الأصلي.
تكوينات استيراد البيانات
- يمكنك قياس المثيل مؤقتاُ إلى حجم وحدة حفظ المخزون أعلى قبل بدء عملية استيراد البيانات ثم قم بتحجيمه عند نجاح الاستيراد.
- يمكنك استيراد بياناتك بأقل وقت تعطل باستخدام ترحيل MySQL المحلي إلى قاعدة بيانات Azure ل MySQL للترحيل عبر الإنترنت أو دون اتصال.
توصيات ذاكرة الخادم المرن ل Azure Database for MySQL
أفضل ممارسة لأداء Azure Database for MySQL Flexible Server هي تخصيص ذاكرة وصول عشوائي كافية بحيث توجد مجموعة العمل الخاصة بك بالكامل تقريبا في الذاكرة.
- تحقق مما إذا كانت النسبة المئوية للذاكرة المستخدمة في الوصول إلى الحدود باستخدام مقاييس قاعدة بيانات Azure لخادم MySQL المرن.
- قم بإعداد التنبيهات على هذه الأرقام للتأكد من أنه كلما وصلت الخوادم إلى الحدود يمكنك اتخاذ إجراءات فورية لإصلاحها. استناداً إلى الحدود المحددة، تحقق مما إذا كان توسيع نطاق وحدة حفظ المخزون لقاعدة البيانات — إما إلى حجم حساب أعلى أو إلى طبقة أسعار أفضل، مما يؤدي إلى زيادة كبيرة في الأداء.
- يمكنك توسيع النطاق حتى لا تنخفض أرقام الأداء بشكل كبير بعد عملية التحجيم. للحصول على معلومات حول مراقبة مقاييس مثيل DB، راجع Azure Database for MySQL Flexible Server DB Metrics.
استخدام تجهيز مجموعة المخزن المؤقت لـ InnoDB
بعد إعادة تشغيل مثيل Azure Database for MySQL Flexible Server، يتم تحميل صفحات البيانات الموجودة في التخزين حيث يتم الاستعلام عن الجداول مما يؤدي إلى زيادة زمن الانتقال وأداء أبطأ للتنفيذ الأول للاستعلامات. قد لا يكون هذا مقبولا لأحمال العمل الحساسة لزمن الانتقال.
يؤدي استخدام تجهيز مجموعة المخزن المؤقت لـ InnoDB إلى تقصير فترة التجهيز عن طريق إعادة تحميل صفحات القرص التي كانت في مجموعة المخزن المؤقت قبل إعادة التشغيل بدلاً من انتظار عمليات DML أو SELECT للوصول إلى الصفوف المقابلة.
يمكنك تقليل فترة التجهيز بعد إعادة تشغيل مثيل Azure Database for MySQL Flexible Server، والذي يمثل ميزة أداء عن طريق تكوين معلمات خادم تجمع المخزن المؤقت InnoDB. يحفظ InnoDB نسبة مئوية من الصفحات المستخدمة مؤخراً لكل مجموعة المخزن المؤقت عند إيقاف تشغيل الخادم واستعادة هذه الصفحات عند بدء تشغيل الخادم.
من المهم أيضًا ملاحظة أن الأداء المحسن يأتي على حساب وقت بدء التشغيل الأطول للخادم. عند تمكين هذه المعلمة، من المتوقع أن يزداد وقت عملية بدء تشغيل الخادم وإعادة تشغيله، بناءً على عملية الإدخال/الإخراج في الثانية المتوفرة على الخادم.
نوصي باختبار وقت إعادة التشغيل ومراقبة هذا الوقت لضمان أن أداء بدء التشغيل/إعادة التشغيل مقبول لأن الخادم غير متوفر خلال ذلك الوقت. لا يوصى باستخدام هذه المعلمة مع أقل من 1000 IOPS مقدم (أو بعبارة أخرى، عندما تكون سعة التخزين المتوفرة أقل من 335 جيجابايت).
لحفظ حالة مجموعة المخزن المؤقت عند إيقاف تشغيل الخادم، قم بضبط معلمة الخادم innodb_buffer_pool_dump_at_shutdown إلى ON. وبالمثل، قم بضبط معلمة الخادم innodb_buffer_pool_load_at_startup إلى ON لاستعادة حالة مجموعة المخزن المؤقت عند بدء تشغيل الخادم. يمكنك التحكم في التأثير على وقت بدء التشغيل / إعادة التشغيل عن طريق خفض قيمة معلمة الخادم وضبطها innodb_buffer_pool_dump_pct. بشكلٍ افتراضي، يتم ضبط هذه المعلمة على 25.
إشعار
يتم دعم معلمات تجهيز مجموعة المخزن المؤقت فقط لـ InnoDB في خوادم التخزين للأغراض العامة مع تخزين يصل إلى 16 تيرابايت. لمزيد من المعلومات، راجع خيارات تخزين Azure Database for MySQL Flexible Server.