أفضل الممارسات لتجمعات 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')أفضل طريقة اعتمادا على احتياجاتك. ومع ذلك ، إذا كنت بحاجة إلى تحميل الآلاف أو الملايين من الصفوف على مدار اليوم ، فمن المحتمل أن تكون INSERTS المفردة ليست مثالية.

تتمثل إحدى طرق حل هذه المشكلة في تطوير عملية واحدة تكتب إلى ملف ، ثم عملية أخرى لتحميل هذا الملف بشكل دوري. راجع مقالة 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 blob وتخزين Azure Data Lake فقط. لا تحتوي هذه الملفات على أي موارد حوسبة تدعمها. ونتيجة لذلك، لا يمكن لتجمعات SQL المخصصة إلغاء تحميل هذا العمل ويجب قراءة الملف بأكمله عن طريق تحميله tempdb حتى يتمكن من قراءة البيانات.

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

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

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

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

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

تلميح

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

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

لا تفرط في التقسيم

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

يمكن أن يؤدي وجود عدد كبير جدا من الأقسام إلى تقليل فعالية فهارس columnstore متفاوتة المسافات إذا كان كل قسم يحتوي على أقل من 1 مليون صف. تقوم تجمعات SQL المخصصة تلقائيا بتقسيم بياناتك إلى 60 قاعدة بيانات. لذلك ، إذا قمت بإنشاء جدول يحتوي على أقسام 100 ، فستكون النتيجة 6000 قسم. يختلف كل عبء عمل عن الآخر ، لذا فإن أفضل نصيحة هي تجربة التقسيم لمعرفة ما هو الأفضل لعبء العمل الخاص بك.

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

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

تقليل أحجام المعاملات

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

تلميح

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تلميح

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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