توصية بتكوينات قواعد البيانات

مكتمل

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

قارن نماذج الموارد

يدعم Azure SQL Database نموذجين للموارد: vCore و DTU. يقيسون ويحسب الفوترة بطرق مختلفة، لذا فهم الفرق يساعدك على اتخاذ القرار الصحيح من البداية.

نموذج vCore يمنحك تحكما مباشرا في النوى الافتراضية، والذاكرة، والتخزين. تختار توليد الأجهزة، ومستوى الخدمة، ومستوى الحوسبة بشكل مستقل. إذا كنت تنتقل من SQL Server المحلي، فإن هذا النموذج يتوافق بشكل واضح مع وحدة المعالجة المركزية والذاكرة الفعلية، مما يجعل تخطيط السعة أكثر وضوحا. كما يدعم تسعير النسخ المحجوزة وميزة Azure Hybrid Benefit لتوفير التكاليف.

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

بالنسبة لمعظم النشرات الجديدة، توصي مايكروسوفت بنموذج vCore. يوفر حدود موارد أعلى، وتفصيلا أكبر في التوسع، ومرونة أكبر في التسعير.

فهم مستويات الخدمة في نموذج vCore

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

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

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

تدمج بيزنس كريتيكال الحوسبة والتخزين على كل عقدة. يستخدم محرك قاعدة البيانات وملفات البيانات SSD محليا في مجموعة توفر Always On مع ثلاث نسخ ثانوية. هذا التصميم يمنحك أقل زمن استجابة للإدخال والإخراج (من 1 إلى 2 مللي ثانية في المتوسط)، وأعلى IOPS (عمليات إدخال/إخراج في الثانية)، ونسخة مجانية للقراءة فقط يمكنك استخدامها للإبلاغ عن الاستعلامات. المقابل هو التكلفة، حوالي 2.7 ضعف السعر العام لنفس عدد vCore. بالنسبة لفريق التجارة الإلكترونية، فإن Business Critical منطقي إذا كانت معاملات الدفع لديهم تحتاج إلى زمن استجابة ثابت أقل من 2 مللي ثانية.

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

يلخص الجدول التالي الاختلافات الرئيسية:

الميزة	General Purpose	الأعمال الحرجة	التوسع الفائق
نوع التخزين	Remote (Azure Blob Storage)	SSD محلي	منفصل عن ذاكرة SSD المحلية
أقصى سعة تخزين	4 تيرابايت	4 تيرابايت	128 تيرابايت
أقصى IOPS لكل vCore	320	4,000	5,500 (SSD محلي)
نسخ التوفر	1 (لا توجد نسخ مقروءة)	نسخة قراءة 3 + 1	من 0 إلى 4 (قابل للتكوين)
الأفضل ل	أعباء العمل الموجهة للميزانية	زمن استجابة منخفض، إدخال/إخراج مرتفع	قواعد بيانات كبيرة، توسع مرن

اختر مستوى الحوسبة

داخل نموذج vCore، تختار أيضا بين مستويين للحوسبة: مزود بالحاجة إلى الخادم وبدون خادم.

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

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

طابق التكوين مع عبء عملك

الآن بعد أن فهمت الخيارات، كيف تقرر؟ قيم عبء عملك بناء على هذه العوامل:

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

نصيحة

عند الانتقال من SQL Server المحلي، استخدم نموذج vCore لأنه يعكس مباشرة وحدة المعالجة المركزية والذاكرة الفعلية. نموذج DTU لا يكشف عن أبعاد الموارد الفردية، مما يجعل تخطيط القدرات للهجرات أصعب في التعاملات.

تكوين إعدادات قاعدة البيانات

اخترت المستوى ونموذج الحوسبة. الآن انظر داخل قاعدة البيانات نفسها. تؤثر عدة إعدادات على كيفية تعامل Azure SQL Database مع التوازي، وتحسين الاستعلام، والاسترداد. تقوم بتعديل هذه الإعدادات دون تغيير مستوى الخدمة الخاص بك.

التوازي بين التحكم وMAXDOP

أقصى درجة من التوازي (MAXDOP) تتحكم في عدد خيوط المعالج التي يعينها المحرك لاستعلام واحد. قاعدة بيانات Azure SQL توضع افتراضيا على 8، وهذا يعمل لأكبر مجموعة من الأحمال العملية. قبل سبتمبر 2020، كانت قواعد البيانات الجديدة تتوقف افتراضيا إلى 0، أي توازي غير محدود، وهذا تسبب في مشاكل. استعلام تحليلي واحد قد يستهلك كل خيط متاح، مما يحرم تدفق الدفع من المعالج.

تقوم بتعيين MAXDOP على مستوى قاعدة البيانات باستخدام ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP. يمكنك أيضا تعيين قيمة مختلفة للنسخ الثانوية عندما تكون أحمال العمل للقراءة والكتابة والقراءة فقط لديك احتياجات التزامن مختلفة. لاستفسار محدد، استخدم التلميح OPTION (MAXDOP) . القاعدة الوحيدة: تجنب MAXDOP 0 في الإنتاج. التوازي غير المحدود يؤدي إلى استنفاد الموارد، وانتهاء مهلات الاستعلام، وانقطاعات التطبيقات.

دع الضبط التلقائي يلتقط الانحدارات

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

تدعم قاعدة بيانات Azure SQL ثلاثة خيارات:

• يكتشف FORCE_LAST_GOOD_PLAN تراجعات الخطة ويجبر الخطة السريعة السابقة. ممكَّن بشكل افتراضي.
• CREATE_INDEX يحدد الفهارس المفقودة، وينشئها، ويتحقق من التحسين. معطل بشكل افتراضي.
• DROP_INDEX تزيل الفهارس غير المستخدمة والمكررة. معطل بشكل افتراضي. الفهارس الفريدة، بما في ذلك الفهارس التي تدعم المفتاح الأساسي والقيود الفريدة، لا تسقط أبدا.

كل تغيير يمر عبر نافذة تحقق، من 30 دقيقة إلى 72 ساعة حسب تكرار الاستعلام. إذا ساءت الأداء، يتم التراجع عن التغيير تلقائيا.

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON,
                      CREATE_INDEX = ON,
                      DROP_INDEX = OFF);

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

ميزات المحسن بمستوى التوافق

كل قاعدة بيانات لديها مستوى توافق يحدد سلوكيات تحسين الاستعلام المتاحة. قواعد البيانات الجديدة في قاعدة بيانات Azure SQL تكون افتراضيا للمستوى 170، أو أعلى مستوى متاح. كل مستوى يفتح مجموعة من ميزات معالجة الاستعلامات الذكية (IQP):

• المستوى 150: وضع الدفعة في مخزن الصفوف، تجميع متغير الجدول المؤجل، التسطين القياسي للوظيفة المعرفة من قبل المستخدم (UDF).
• المستوى 160: تحسين الخطط الحساسة للمعلمات (PSP)، تغذية راجعة تقدير الكاردينالية.
• المستوى 170: تحسين خطة المعلمات اختياريا.

يمكن لقواعد البيانات الحالية أن تعمل بمستوى توافق أقل لأن مايكروسوفت لا تقوم بترقية هذا الإعداد تلقائيا. قاعدة البيانات التي تم إنشاؤها عندما كان هناك إعداد افتراضي أقل تحتفظ بمستواها الأصلي. على سبيل المثال، إذا أنشأت قاعدة بيانات Azure SQL في عام 2024، فإن قاعدة البيانات لا تزال عند المستوى 160 إذا لم يتم تحديث المستوى يدويا. وبالمثل، إذا استوردت قاعدة بيانات عبر ملف BACPAC، فإن مستوى توافق قاعدة البيانات المستوردة يعتمد على مستوى توافق قاعدة البيانات المصدر. للترقية:

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 170;

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

تقليل زيادة ذاكرة التخزين المؤقت للخطة باستخدام OPTIMIZE_FOR_AD_HOC_WORKLOADS

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

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

ALTER DATABASE SCOPED CONFIGURATION
SET OPTIMIZE_FOR_AD_HOC_WORKLOADS = ON;

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

فهم استعادة قاعدة البيانات المعجلة

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

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

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

النقاط الموجزة الأساسية

يوفر لك Azure SQL Database نموذجين للموارد، وثلاث مستويات خدمة، ومستويان للحوسبة. نموذج vCore مع الأغراض العامة يغطي معظم أعباء العمل. يضيف بيزنس كريتيكال زمن تأخير أقل من 2 مللي ثانية. Hyperscale يزيل حدود التخزين والتكبير. داخل قاعدة البيانات، MAXDOP 8 هو الافتراضي الآمن، حيث يكتشف الضبط التلقائي انحدارات الخطط، وترقية مستوى التوافق تفتح أحدث ميزات معالجة الاستعلامات الذكية (IQP). تمكين OPTIMIZE_FOR_AD_HOC_WORKLOADS للحفاظ على نظافة ذاكرة التخزين المؤقت للخطة، ومراقبة استخدام تخزين PVS من ADR باستخدام sys.dm_tran_persistent_version_store_stats، خاصة في السيناريوهات التي تتطلب الكثير من الكتابة. بعد ذلك، تستكشف كيف تؤثر مستويات العزل والتحكم في التزامن على الاستعلامات التي تعمل داخل هذه البنية التحتية.