الترقية إلى الكسلان: كيف تحسن PostgreSQL 12 الأداء

الترقية إلى الكسلان: كيف تحسن PostgreSQL 12 الأداء

PostgreSQL 12، الإصدار الأخير من "أفضل قاعدة بيانات علائقية مفتوحة المصدر في العالم" ، سيصدر في غضون أسبوعين (إذا سارت الأمور وفقًا للخطة). يتبع هذا الجدول الزمني المعتاد - يتم إصدار إصدار جديد به الكثير من الميزات الجديدة مرة واحدة في السنة ، وبصراحة ، إنه مثير للإعجاب. لهذا السبب أصبحت عضوًا نشطًا في مجتمع PostgreSQL.

في رأيي ، على عكس الإصدارات السابقة ، لا تحتوي PostgreSQL 12 على ميزة ثورية واحدة أو اثنتين (مثل التقسيم أو استعلام التوازي). لقد مزحت ذات مرة أن الميزة الرئيسية لـ PostgreSQL 12 هي زيادة الاستقرار. أليس هذا ما تحتاجه عند إدارة البيانات الهامة لعملك؟

لكن PostgreSQL 12 لا يقتصر على هذا: مع الميزات والتحسينات الجديدة ، ستعمل التطبيقات بشكل أفضل ، كل ما عليك فعله هو الترقية!

(حسنًا ، ربما حتى نعيد بناء الفهارس ، لكن في هذا الإصدار ليس الأمر مخيفًا كما اعتدنا.)

سيكون من الرائع ترقية PostgreSQL والاستمتاع فورًا بالتحسينات المهمة دون إيماءات غير ضرورية. قبل عدة سنوات ، قمت بتحليل الترقية من PostgreSQL 9.4 إلى PostgreSQL 10 ورأيت مدى سرعة التطبيق بسبب توازي الاستعلام المحسن في PostgreSQL 10. والأهم من ذلك ، لم يكن مطلوبًا مني أي شيء تقريبًا (فقط قم بتعيين معلمة التكوين max_parallel_workers).

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

وكيف تجعلك الترقية البسيطة إلى PostgreSQL 12 سعيدًا؟ الآن سأخبرك.

تحسينات كبيرة في الفهرسة

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

نحن فقط نستخدم عامل التشغيل CREATE INDEX ON some_table (some_column)، وتقوم PostgreSQL بعمل رائع في الحفاظ على الفهرس محدثًا أثناء قيامنا بإدراج القيم وتحديثها وحذفها باستمرار. كل شيء يعمل من تلقاء نفسه ، مثل السحر.

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

تحسن PostgreSQL 12 أداء فهارس B-tree بشكل كبير ، وقد أظهرت التجارب مع اختبارات مثل TPC-C أن المساحة تُستخدم الآن ، في المتوسط ​​، أقل بنسبة 40٪. الآن نقضي وقتًا أقل ليس فقط في الحفاظ على فهارس B-tree (أي عمليات الكتابة) ، ولكن أيضًا في استرداد البيانات ، لأن الفهارس أصبحت أصغر بكثير.

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

تتطلب بعض استراتيجيات الترقية إعادة بناء فهارس B-tree للاستفادة من هذه الفوائد (على سبيل المثال ، pg_upgrade لن يعيد بناء الفهارس تلقائيًا). في الإصدارات السابقة من PostgreSQL ، أدت إعادة بناء الفهارس الكبيرة على الجداول إلى توقف كبير لأنه لا يمكن إجراء أي تغييرات خلال ذلك الوقت. لكن لدى PostgreSQL 12 ميزة أخرى رائعة: يمكنك الآن إعادة بناء الفهارس بالتوازي مع الأمر رينديكس بشكل متزامنلتفادي التوقف تمامًا.

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

قلل PostgreSQL 12 الحمل الزائد لسجلات WAL التي تم إنشاؤها بواسطة فهارس GiST و GIN و SP-GiST عند إنشاء فهرس. هذا له العديد من الفوائد الملموسة: تشغل سجلات WAL مساحة أقل على القرص ، ويتم إعادة تشغيل البيانات بشكل أسرع ، مثل أثناء تجاوز الفشل أو الاسترداد في وقت واحد. إذا كنت تستخدم مثل هذه الفهارس في تطبيقاتك (على سبيل المثال ، تستخدم التطبيقات الجغرافية المكانية المستندة إلى PostGIS مؤشر GiST كثيرًا) ، فهذه ميزة أخرى ستعمل على تحسين الأداء بشكل كبير دون بذل أي جهد من جانبك.

التقسيم - أكبر وأفضل وأسرع

طرح PostgreSQL 10 التقسيم التصريحي. في PostgreSQL 11 ، أصبح استخدامه أسهل بكثير. في PostgreSQL 12 ، يمكنك قياس الأقسام.

في PostgreSQL 12 ، تحسن أداء نظام التقسيم بشكل ملحوظ ، خاصة إذا كان هناك آلاف الأقسام في الجدول. على سبيل المثال ، إذا كان استعلام ما يؤثر فقط على عدد قليل من الأقسام في جدول يحتوي على الآلاف منها ، فسيتم تشغيله بشكل أسرع. لا تقتصر تحسينات الأداء على هذه الأنواع من الاستعلامات. ستلاحظ أيضًا مدى سرعة عمليات INSERT على الجداول التي تحتوي على العديد من الأقسام.

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

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

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

مع الاستفسارات أصبحت أفضل كثيرًا

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

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

يسمح لك PostgreSQL 12 بتضمين نوع معين من الاعتلال الدماغي الرضحي المزمن دون آثار جانبية (SELECT) ، والذي يتم استخدامه مرة واحدة فقط بالقرب من نهاية الطلب. إذا تابعت استفسارات CTE التي أعدت كتابتها ، فسيقع معظمها في هذه الفئة. يساعد هذا المطورين على كتابة تعليمات برمجية واضحة أصبحت الآن سريعة أيضًا.

علاوة على ذلك ، يعمل PostgreSQL 12 على تحسين تنفيذ SQL نفسه ، ولا يتعين عليك فعل أي شيء. على الرغم من أنني ربما لن أحتاج إلى تحسين مثل هذه الاستعلامات الآن ، إلا أنه من الرائع أن تواصل PostgreSQL العمل على تحسين الاستعلام.

Just-in-Time (JIT) - الآن الافتراضي

على أنظمة PostgreSQL 12 مع الدعم LLVM يتم تمكين تجميع JIT افتراضيًا. أولاً ، تحصل على الدعم JIT بالنسبة لبعض العمليات الداخلية ، وثانيًا ، الاستعلامات ذات التعبيرات (أبسط مثال هو x + y) في قوائم التحديد (التي لديك بعد SELECT) ، يمكن للتجميعات والتعبيرات التي تحتوي على عبارات WHERE وغيرها استخدام JIT لتحسين الأداء.

نظرًا لأن JIT يتم تمكينه افتراضيًا في PostgreSQL 12 ، فإن الأداء سيتحسن من تلقاء نفسه ، لكنني أقترح اختبار التطبيق في PostgreSQL 11 ، حيث تم تقديم JIT لأول مرة ، لقياس أداء الاستعلام ومعرفة ما إذا كان أي شيء يحتاج إلى تعديل.

ولكن ماذا عن باقي الميزات الجديدة لـ PostgreSQL 12؟

يتمتع PostgreSQL 12 بالعديد من الميزات الجديدة الرائعة ، بدءًا من القدرة على فحص بيانات JSON باستخدام تعبيرات توجيه SQL / JSON القياسية إلى المصادقة متعددة العوامل باستخدام clientcert=verify-fullوالأعمدة المُنشأة والمزيد. يكفي لوظيفة منفصلة.

مثل PostgreSQL 10 ، ستعمل PostgreSQL 12 على تحسين الأداء العام فورًا بعد الترقية. بالطبع ، يمكن أن يكون لديك طريقتك الخاصة - اختبر التطبيق في ظل ظروف مماثلة على نظام إنتاج قبل تمكين التحسينات ، كما فعلت مع PostgreSQL 10. حتى لو كانت PostgreSQL 12 بالفعل أكثر استقرارًا مما توقعت ، فلا تكن كسولًا لاختبار التطبيقات حسنًا ، قبل إطلاقها في الإنتاج.

المصدر: www.habr.com

إضافة تعليق