نصيحة حول كيفية توسيع نطاق أوقات تنفيذ "الاستعلام المحوري" وتحسينه على جدول يضم مليار صف، وزيادة مليون صف في اليوم

Question

تقوم شركتنا بتطوير مشروع داخلي لتحليل الملفات النصية.تتكون هذه الملفات النصية من بيانات وصفية يتم استخراجها باستخدام التعبيرات العادية.تقوم عشرة أجهزة كمبيوتر بتحليل الملفات النصية على مدار الساعة طوال أيام الأسبوع وتغذية قاعدة بيانات Intel Xeon SQL Server 2005 المتطورة بالبيانات التعريفية المستخرجة.

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

أغراض

| Id | Name   |
|----|--------|
| 1  | Sample |

Items_Attributes

| ItemId | AttributeId |
|--------|-------------|
| 1      | 1           |
| 1      | 2           |

صفات

| Id | AttributeTypeId | Value |
|----|-----------------|-------|
| 1  | 1               | 500mB |
| 2  | 2               | 1.0.0 |

أنواع السمات

| Id | Name    |
|----|---------|
| 1  | Size    |
| 2  | Version |

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

Items_Attributes اسمح لنا بتجنب التكرار Attribute القيم التي تتجنب زيادة حجم قاعدة البيانات x^10.

يتيح لنا هذا المخطط المحدد إضافة تعبيرات عادية جديدة ديناميكيًا والحصول على بيانات تعريف جديدة من الملفات المعالجة الجديدة بغض النظر عن البنية الداخلية لها.

بالإضافة إلى ذلك، يسمح لنا هذا بتصفية البيانات والحصول على تقارير ديناميكية بناءً على معايير المستخدم.نحن نقوم بالتصفية حسب Attribute ثم قم بتدوير مجموعة النتائج (http://msdn.microsoft.com/en-us/library/ms177410.aspx).لذلك هذا المثال استعلام SQL الزائف

SELECT FROM Items WHERE Size = @A AND Version = @B

سوف يعود جدول محوري مثل هذا

| ItemName | Size  | Version |
|----------|-------|---------|
| Sample   | 500mB | 1.0.0   |

The application has been running for months and performance decreased terribly at the point is no longer usable. Reports should take no more than 2 seconds and Items_Attributes يزيد الجدول بمعدل 10.000.000 صف في الأسبوع.تمت فهرسة كل شيء بشكل صحيح وأمضينا وقتًا طويلاً في تحليل خطط تنفيذ الاستعلام وتحسينها.

لذا فإن سؤالي هو، كيف يمكنك توسيع نطاق ذلك لتقليل أوقات تنفيذ التقرير؟

لقد جئنا مع هذه الحلول الممكنة:

• شراء المزيد من الأجهزة وإعداد مجموعة SQL Server.(نحتاج إلى نصيحة بشأن استراتيجية "التجميع" المناسبة)
• استخدم قاعدة بيانات مفتاح/قيمة مثل HBase (لا نعرف حقًا ما إذا كان سيحل مشكلتنا)
• استخدم ODBMS بدلاً من RDBMS (لقد كنا نفكر في db4o)
• انقل برامجنا إلى السحابة (ليس لدينا أي خبرة)
• إنشاء التقارير بشكل ثابت في وقت التشغيل.(نحن لا نريد حقا)
• طرق العرض المفهرسة الثابتة للتقارير المشتركة (الأداء هو نفسه تقريبًا)
• إلغاء تطبيع المخطط (تتضمن بعض تقاريرنا ما يصل إلى 50 جدولًا في استعلام واحد)

Answer 1

ربما يمكن أن تساعد هذه الوثيقة التقنية التي أعدها فريق SQL Server CAT حول مخاطر نموذج قاعدة البيانات Entity-Attribute-Value: http://sqlcat.com/whitepapers/archive/2008/09/03/best-practices-for-semantic-data-modeling-for-performance-and-scalability.aspx

Answer 2

سأبدأ بنشر بيانات تعريف الجداول الدقيقة (مع تفاصيل الفهرسة) ونص الاستعلام الدقيق وخطة التنفيذ.

باستخدام تخطيط الجدول الحالي، يكون الاستعلام مشابهًا لما يلي:

SELECT FROM Items WHERE Size = @A AND Version = @B

لا يمكن الاستفادة من استخدام فهرس مركب على (Size, Version), لأنه من المستحيل بناء مثل هذا الفهرس.

لا يمكنك حتى إنشاء طريقة عرض مفهرسة، لأنها قد تحتوي على انضمام ذاتي attributes.

ربما يكون القرار الأفضل هو إلغاء تسوية الجدول على النحو التالي:

id  name  size  version

وإنشاء فهرس على (size, version)

Answer 3

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

| ItemName | Size | Version | |----------|-------|---------| | Sample | 500mB | 1.0.0 |

ثم لا تحتاج إلى المحور.راجع للشغل، من فضلك لا تسمي مخطط EAV الأصلي الخاص بك بأنه "مطبيع" - فهو غير طبيعي.

Answer 4

يبدو لي أنه يتم إصدار بعض استعلامات OLAP على قاعدة بيانات محسنة لمعاملات OLTP.إذا كنت لا تعرف التفاصيل، فإنني أوصي ببناء "مستودع بيانات" منفصل محسّن لنوع الاستعلامات التي تجريها.قد يتضمن ذلك تجميع البيانات (إن أمكن)، وإزالة الطبيعة وأيضًا وجود قاعدة بيانات عمرها يوم واحد أو نحو ذلك.يمكنك تحديث البيانات بشكل تدريجي كل يوم أو في أي فترة زمنية ترغب فيها.

Answer 5

يرجى نشر DDL والفهارس الدقيقة، إذا كان لديك فهارس في أعمدة المعرفات، فسيؤدي استعلامك إلى إجراء فحص

بدلا من شيء من هذا القبيل

SELECT FROM Items WHERE Size = @A AND Version = @B

عليك أن تفعل هذا

SELECT FROM Items WHERE ID = 1

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

ربما تكون فكرة جيدة أيضًا النظر إلى وظيفة التقسيم لتوزيع بياناتك

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

Answer 6

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

هذا على افتراض أنك لا تحاول الإبلاغ عن الجميع ItemIdمرة واحدة.

Answer 7

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

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

أيضًا (هذا قليلًا) لا تحدد إصدار خادم SQL الذي تستخدمه؛ولكن إذا كنت تستخدم SQL 2005، ونظرًا لعدد الجداول المضمنة في تقاريرك وحجم البيانات، فمن المفيد التحقق من تصحيح خادم SQL الخاص بك إلى SP2 على الأقل.

لقد عملت في مشروع ETL باستخدام جداول يبلغ عدد صفوفها مئات الملايين، حيث وجدنا أن مُحسِّن الاستعلامات في SQL 2005 RTM/SP1 لا يمكنه إنتاج خطط فعالة بشكل متسق للاستعلامات التي تربط أكثر من 5 جداول حيث تم إدراج جدول واحد أو أكثر من هذا المقياس.تم حل هذه المشكلة في SP2.