يتم إصدار PostgreSQL 12 ، وهو أحدث إصدار من "أفضل قاعدة بيانات علائقية مفتوحة المصدر في العالم" ، في غضون أسبوعين (إذا سارت الأمور وفقًا للخطة). هذا يتوافق مع الجدول المعتاد - إصدار جديد مع الكثير من الميزات الجديدة يخرج مرة واحدة في السنة ، وبصراحة ، إنه مثير للإعجاب. لذلك ، أصبحت عضوًا نشطًا في مجتمع PostgreSQL.
في رأيي ، على عكس الإصدارات السابقة ، لا يحتوي PostgreSQL 12 على وظيفة أو وظيفتين ثوريتين (مثل تقسيم الاستعلامات أو تزامنها). لقد مازحت ذات مرة أن الميزة الرئيسية لبرنامج PostgreSQL 12 هي المزيد من الاستقرار. أليس هذا ما تحتاجه عند إدارة بيانات العمل الهامة؟
لكن PostgreSQL 12 لا يقتصر على هذا: مع الميزات والتحسينات الجديدة ، ستعمل التطبيقات بشكل أفضل ، وتحتاج فقط إلى الترقية!
(حسنًا ، ربما حتى تعيد بناء المؤشرات ، لكن في هذا الإصدار ليس مخيفًا كما اعتدنا.)
سيكون من الرائع ترقية PostgreSQL والتمتع على الفور بتحسينات كبيرة دون إيماءات غير ضرورية. قبل بضع سنوات ، قمت بتحليل الترقية من PostgreSQL 9.4 إلى PostgreSQL 10 ورأيت كيف تسارّع التطبيق بسبب توازي الاستعلام المحسن في PostgreSQL 10. والأهم من ذلك ، لم يكن هناك شيء مطلوب تقريبًا مني (فقط قم بتعيين max_parallel_workers تكوين max_parallel_workers ).
موافق ، إنه ملائم عندما تعمل التطبيقات مباشرة بشكل أفضل بعد الترقية. ونحن نحاول جاهدين إرضاء المستخدمين ، لأن PostgreSQL لديه الكثير منهم.
وكيف تجعلك الترقية البسيطة إلى PostgreSQL 12 سعيدة؟ سأخبرك الآن.
تحسينات الفهرسة الرئيسية
بدون فهرسة ، فإن قاعدة البيانات لن تذهب بعيدا. وكيف يمكن العثور بسرعة على المعلومات؟ يُطلق على نظام فهرسة PostgreSQL الأساسي اسم B-tree . تم تحسين هذا النوع من الفهرس لأنظمة التخزين.
نحن فقط نستخدم عبارة CREATE INDEX ON some_table (some_column) ، ويقوم PostgreSQL بعمل رائع للحفاظ على الفهرس محدثًا بينما نقوم باستمرار بإدراج القيم وتحديثها وحذفها. كل شيء يعمل من تلقاء نفسه ، كما لو كان بالسحر.
لكن فهارس PostgreSQL تواجه مشكلة واحدة - فهي تنتفخ وتحتل مساحة إضافية على القرص ، ويتم تقليل أداء استرداد البيانات وتحديثها. بعبارة "سخام" ، أعني الحفاظ على بنية الفهرس بطريقة غير فعالة. هذا قد يكون أو لا يكون بسبب tuples التي يزيلها VACUUM (شكرا للمعلومات لبيتر Geoghegan ). مؤشر سخام ملحوظ بشكل خاص في أعباء العمل حيث يتغير المؤشر بنشاط.
يعمل PostgreSQL 12 على تحسين أداء فهارس B-tree بشكل خطير ، وأظهرت التجارب التي أجريت مع اختبارات مثل TPC-C أن المساحة المستخدمة الآن ، في المتوسط ، أقل بنسبة 40٪. الآن نقضي وقتًا أقل ليس فقط في الحفاظ على فهارس B-tree (أي ، في عمليات الكتابة) ، ولكن أيضًا على استخراج البيانات ، لأن الفهارس أصبحت أصغر كثيرًا.
التطبيقات التي تعمل على تحديث جداولها بنشاط - عادةً تطبيقات OLTP ( معالجة المعاملات في الوقت الفعلي ) - تكون أكثر فاعلية بكثير في استخدام القرص ومعالجة الطلبات. كلما زادت مساحة القرص ، زادت مساحة قاعدة البيانات للنمو دون ترقية البنية التحتية.
تتطلب بعض استراتيجيات الترقية إعادة إنشاء فهارس B-tree للاستفادة من هذه (على سبيل المثال ، لن تقوم pg_upgrade بإعادة إنشاء الفهارس تلقائيًا). في الإصدارات السابقة من PostgreSQL ، أدت إعادة بناء الفهارس الكبيرة في الجداول إلى توقف كبير ، لأنه في ذلك الوقت كان من المستحيل إجراء تغييرات. لكن PostgreSQL 12 لديه خدعة رائعة أخرى: يمكنك الآن إعادة إنشاء الفهارس بالتوازي مع الأمر REINDEX CONCURRENTLY لتجنب التوقف التام.
يحتوي PostgreSQL 12 على تحسينات أخرى على البنية الأساسية للفهرسة. شيء آخر لا يمكن الاستغناء عنه هو سجل سجل الكتابة ، وهو أيضًا WAL (سجل كتابة التسجيل). يسجل سجل الكتابة المسبق كل معاملة في PostgreSQL في حالة الفشل والتكرار. تستخدمه التطبيقات للنسخ الاحتياطي والاستعادة في وقت ما . بالطبع ، يتم كتابة سجل الكتابة إلى القرص ، وهذا يمكن أن يؤثر على الأداء.
لقد قلل PostgreSQL 12 من حمولات WAL التي تم إنشاؤها بواسطة فهارس GiST و GIN و SP-GiST عند إنشاء الفهرس. يوفر هذا العديد من المزايا الملموسة: تشغل سجلات WAL مساحة أقل على القرص ، ويتم إعادة إنتاج البيانات بشكل أسرع ، على سبيل المثال ، أثناء الاسترداد من الفشل أو الاسترداد في وقت ما. إذا كنت تستخدم هذه الفهارس في تطبيقاتك (على سبيل المثال ، تستخدم التطبيقات الجغرافية المكانية المستندة إلى PostGIS فهرس GiST كثيرًا) ، فهذه ميزة أخرى من شأنها تحسين الأداء بشكل كبير دون أي جهد من جانبك.
التقسيم - أكبر ، أفضل ، أسرع
قدم بوستجرس 10 التقسيم التعريفي . PostgreSQL 11 جعله أسهل في الاستخدام. في PostgreSQL 12 ، يمكنك تغيير حجم الأقسام.
في PostgreSQL 12 ، يكون تقسيم أداء النظام أفضل بكثير ، خاصةً إذا كان هناك الآلاف من الأقسام في الجدول. على سبيل المثال ، إذا كان الاستعلام يؤثر على بضعة أقسام فقط في جدول ، حيث يوجد الآلاف منها ، فسيتم تشغيله بشكل أسرع. تم تحسين الأداء ليس فقط مع هذه الأنواع من الاستعلامات. ستلاحظ أيضًا كيف تسارعت عمليات INSERT في الجداول مع العديد من الأقسام.
كتابة البيانات باستخدام COPY - بالمناسبة ، هذه طريقة رائعة لتحميل البيانات بالجملة وهنا مثال على استلام JSON - في الجداول المقسمة في PostgreSQL 12 أصبحت أيضًا أكثر فاعلية. مع COPY ، كان كل شيء سريعًا ، لكن في برنامج PostgreSQL 12 ، أصبح سريعًا.
بفضل هذه المزايا ، يمكن لـ PostgreSQL تخزين مجموعات البيانات الكبيرة وجعل الاسترجاع أسهل. ولا جهد من جانبك. إذا كان التطبيق يحتوي على العديد من الأقسام ، على سبيل المثال ، فإنه يسجل بيانات السلاسل الزمنية ، ستؤدي الترقية البسيطة إلى تحسين أدائه بشكل كبير.
على الرغم من أن هذا التحسين لا ينتمي بالكامل إلى فئة "الترقية والترحيب" ، في PostgreSQL 12 ، يمكنك إنشاء مفاتيح خارجية تشير إلى الجداول المقسمة بحيث يكون العمل مع التقسيم أمرًا ممتعًا.
مع استفسارات أفضل بكثير
عندما تم تطبيق التصحيح على تعبيرات الجدول المعممة المضمنة (وهي CTE ، كما أنها مع استفسارات) ، كنت حريصًا على كتابة مقال حول كيف كان مطورو التطبيقات مع PostgreSQL سعداء . هذه هي واحدة من تلك الميزات التي سوف تسرع التطبيق. ما لم يكن ، بالطبع ، كنت تستخدم CTE.
كثيراً ما ألاحظ أن القادمين الجدد إلى SQL يرغبون في استخدام CTE: إذا كنت تكتبهم بطريقة معينة ، فأنت تشعر مباشرة أنك تكتب برنامجًا ضروريًا. شخصيا ، أحببت إعادة كتابة هذه الاستعلامات من أجل الاستغناء عن CTE وزيادة الأداء. الآن كل شيء مختلف.
يسمح لك PostgreSQL 12 بتضمين نوع معين من CTE بدون آثار جانبية ( SELECT ) ، والذي يتم استخدامه مرة واحدة فقط بالقرب من نهاية الاستعلام. إذا احتفظت بإحصائيات للطلبات المتعلقة بـ CTE التي أعيد كتابتها ، فستقع معظمها في هذه الفئة. هذا يساعد المطورين على كتابة تعليمات برمجية مفهومة تعمل الآن أيضًا بسرعة.
علاوة على ذلك ، فإن PostgreSQL 12 يعمل على تحسين تنفيذ SQL نفسه ، وليس عليك القيام بأي شيء. وعلى الرغم من أنني الآن ، على الأرجح ، لن أحتاج إلى تحسين مثل هذه الاستعلامات ، من الرائع أن يستمر برنامج PostgreSQL في العمل على تحسين الاستعلام.
فقط في الوقت المناسب (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 معلمة clientcert=verify-full ، وأعمدة تم إنشاؤها والمزيد. يكفي لمنصب منفصل.
مثل PostgreSQL 10 ، فإن PostgreSQL 12 سوف يحسن الأداء العام مباشرة بعد الترقية. بالطبع ، يمكن أن يكون لديك طريقتك الخاصة - اختبار التطبيق في ظل ظروف مماثلة في نظام العمل قبل تشغيل التحسينات ، كما فعلت مع PostgreSQL 10. حتى لو كان PostgreSQL 12 أكثر ثباتًا بالفعل مما كنت أتوقع ، فلا تكون كسولًا لاختبار جودة التطبيقات ، قبل إطلاقها في الإنتاج.