أفضل ممارسات تجمعات SQL المخصصة في Azure Synapse Analytics

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

تحميل تجمعات SQL المخصصة

للحصول على إرشادات تحميل تجمعات SQL المخصصة، راجع إرشادات تحميل البيانات.

تقليل التكلفة مع الإيقاف المؤقت والتحجيم

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

إحصائيات الصيانة

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

نوصي بتمكين AUTO_CREATE_STATISTICS لقواعد بياناتك والحفاظ على تحديث الإحصائيات يومياً أو بعد كل تحميل للتأكد من أن الإحصائيات على الأعمدة المستخدَمة في استعلاماتك محدثة دائماً.

لتقليل وقت صيانة الإحصائيات، كن انتقائياً بشأن الأعمدة التي تحتوي على إحصائيات، أو تحتاج إلى التحديث الأكثر تكراراً. على سبيل المثال، قد تحتاج إلى تحديث أعمدة التاريخ، حيث يمكن إضافة قيم جديدة، بشكلٍ يومي. يمكنك التركيز على وجود إحصائيات حول الأعمدة المتضمنة في الصلات، والأعمدة المستخدمة في عبارة WHERE، والأعمدة الموجودة في GROUP BY.

يمكن العثور على معلومات إضافية حول الإحصائيات في مقالات إدارة إحصائيات الجدول وإنشاء الإحصائيات وتحديث الإحصائيات.

ضبط أداء الاستعلام

تجميع عبارات INSERT في دفعات

قد يكون التحميل لمرة واحدة إلى جدول صغير مع عبارة INSERT مثل INSERT INTO MyLookup VALUES (1, 'Type 1')أفضل نهج اعتماداً على احتياجاتك. ومع ذلك، إذا كنت بحاجة إلى تحميل آلاف أو ملايين الصفوف على مدار اليوم، فعلى الأرجح أن عبارات INSERT لقاعدة البيانات الأحادية ليست هي الطريقة المثلى.

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

استخدام PolyBase لتحميل البيانات وتصديرها بسرعة

يدعم تجمع SQL المخصص تحميل البيانات وتصديرها من خلال العديد من الأدوات بما في ذلك Azure Data Factory وPolyBase وBCP. بالنسبة إلى كميات صغيرة من البيانات حيث لا يكون الأداء مهماً، قد تكون أي أداة كافية لاحتياجاتك.

إشعار

PolyBase هو الخيار الأفضل عند تحميل أو تصدير كميات كبيرة من البيانات، أو تحتاج إلى أداء أسرع.

يمكن تشغيل أحمال PolyBase باستخدام CTAS أو INSERT INTO. سيقلل CTAS من تسجيل المعاملات وهو أسرع طريقة لتحميل بياناتك. يدعم Azure Data Factory أيضاً أحمال PolyBase ويمكن أن يحقق أداءً مشابهاً لـ CTAS. يدعم PolyBase تنسيقات الملفات المختلفة بما في ذلك ملفات Gzip.

لزيادة معدل النقل عند استخدام ملفات Gzip النصية، قسّم الملفات إلى 60 ملفاً أو أكثر لزيادة توازي التحميل إلى أقصى حد. للحصول على معدل نقل إجمالي أسرع، ضع في اعتبارك تحميل البيانات بشكلٍ متزامن. يتم تضمين معلومات إضافية ذات صلة بهذا القسم في المقالات التالية:

التحميل ثم الاستعلام عن الجداول الخارجية

PolyBase ليس الأمثل للاستعلامات. تدعم جداول PolyBase لتجمعات SQL المخصصة حالياً ملفات الكائنات الثنائية كبيرة الحجم في Azure وتخزين Azure Data Lake فقط. لا تحتوي هذه الملفات على أي موارد حساب تدعمها. ونتيجة لذلك، لا يمكن لتجمعات SQL المخصصة إلغاء تحميل هذا العمل ويجب قراءة الملف بأكمله عن طريق تحميله إلى tempdb حتى يتمكن من قراءة البيانات.

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

تجزئة توزيع الجداول الكبيرة

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

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

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

تلميح

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

ستمنحك ارتباطات المقالة الواردة أدناه تفاصيل إضافية حول تحسين الأداء عن طريق تحديد عمود توزيع. ستجد أيضاً معلومات حول كيفية تعريف جدول موزع في عبارة WITH من عبارة CREATE TABLE:

عدم الإفراط في التقسيم

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

يمكن أن يؤدي وجود عدد كبير للغاية من الأقسام إلى تقليل فعالية فهارس تخزين الأعمدة المجمعة إذا كان لكل قسم أقل من مليون صف. تقسّم تجمعات SQL المخصصة بياناتك تلقائياً إلى 60 قاعدة بيانات. لذلك، إذا أنشأت جدول بعدد 100 أقسام، ستكون النتيجة 6000 قسم. يختلف كل حمل عمل، لذلك فإن أفضل نصيحة هي تجربة التقسيم لمعرفة ما يصلح بشكلٍ أفضل لحمل العمل الخاص بك.

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

يتم تفصيل مزيد من المعلومات حول التقسيم في مقالة تقسيم الجداول.

تصغير أحجام المعاملات

يتم تشغيل عبارات INSERT وUPDATE وDELETE في معاملة. عندما تفشل، عليك العودة إلى الحالة السابقة. لتقليل احتمالية العودة إلى الحالة السابقة، يمكنك تقليل أحجام المعاملات كلما أمكن ذلك. يمكن تقليل أحجام المعاملات عن طريق تقسيم عبارات INSERT وUPDATE وDELETE إلى أجزاء. على سبيل المثال، إذا كان لديك INSERT تتوقع أن يستغرق ساعة واحدة، يمكنك تقسيم INSERT إلى أربعة أجزاء. ثم سيتم تقصير كل عملية تشغيل إلى 15 دقيقة.

تلميح

استفد من حالات التسجيل الدنيا الخاصة، مثل CTAS أو TRUNCATE أو DROP TABLE أو INSERT إلى جداول فارغة لتقليل مخاطر العودة إلى الحالة السابقة.

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

بالنسبة للجداول غير المقسمة، يجب استخدام CTAS لكتابة البيانات التي تريد الاحتفاظ بها في جدول بدلاً من استخدام DELETE. إذا كان CTAS يستغرق نفس القدر من الوقت، فمن الآمن تشغيل لأنه يحتوي على الحد الأدنى من تسجيل المعاملات ويمكن إلغاؤه بسرعة إذا لزم الأمر.

يتم تضمين مزيد من المعلومات حول المحتوى المتعلق بهذا القسم في المقالات الواردة أدناه:

تقليل أحجام نتائج الاستعلام

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

استخدام أصغر حجم ممكن للعمود

عند تعريف DDL الخاص بك، استخدم أصغر نوع بيانات يدعم بياناتك أثناء تنفيذ ذلك ليؤدي إلى تحسين أداء الاستعلام. هذه التوصية مهمة بشكلٍ خاص لأعمدة CHAR وVARCHAR. على سبيل المثال، إذا كانت أطول قيمة هي 25 حرفاً، فحدد العمود الخاص بك على أنه VARCHAR (25). تجنب تحديد طول افتراضي كبير لأعمدة الأحرف. بالإضافة إلى ذلك، حدد الأعمدة على أنها VARCHAR عندما يكون هذا هو كل ما هو مطلوب بدلاً من استخدام NVARCHAR.

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

استخدام جداول كومة الذاكرة المؤقتة للبيانات العابرة

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

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

لمزيد من المعلومات، راجع مقالات الجداول المؤقتة وإنشاء جدول وإنشاء جدول كمحدد.

تحسين جداول تخزين الأعمدة المجمعة

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

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

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

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

تلميح

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

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

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

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

استخدام فئة موارد أكبر لتحسين أداء الاستعلام

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

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

للحصول على معلومات إضافية حول فئات الموارد، راجع مقالة فئات الموارد لإدارة حمل العمل.

استخدام فئة موارد أصغر لزيادة التزامن

إذا لاحظت تأخيراً طويلاً في استعلامات المستخدم، فقد يكون المستخدمون قيد التشغيل في فئات موارد أكبر. يعزز هذا السيناريو استهلاك فتحات التزامن، مما قد يتسبب في وضع الاستعلامات الأخرى في قائمة الانتظار. لتحديد ما إذا كانت استعلامات المستخدمين مدرجة في قائمة الانتظار، يمكنك التشغيل SELECT * FROM sys.dm_pdw_waits لمعرفة ما إذا تم إرجاع أي صفوف.

ستوفر لك فئات الموارد لإدارة حمل العمل ومقالات sys.dm_pdw_waits مزيداً من المعلومات.

استخدام DMVs لمراقبة الاستعلامات وتحسينها

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

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

راجع أيضاً مقالة استكشاف الأخطاء وإصلاحها للمشكلات والحلول الشائعة.

إذا كنت بحاجة إلى معلومات غير متوفرة في هذه المقالة، فابحث في صفحة سؤال Microsoft Q&A عن Azure Synapse وهو مكان يمكنك من طرح الأسئلة على المستخدمين الآخرين وإلى مجموعة منتجات Azure Synapse Analytics.

نحن نراقب هذا المنتدى بنشاط لضمان الإجابة على أسئلتك إما من قِبل مستخدم آخر أو أحدنا. إذا كنت تفضل طرح أسئلتك على Stack Overflow، فلدينا أيضاً منتدى Azure Synapse Analytics Stack Overflow.