PG12: دزينة من تصحيحات Postgres Professional

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

1. دعم JSONPath

(في ملاحظات الإصدار ، هذا يبدو وكأنه إضافة دعم للغة مسار SQL / JSON (نيكيتا Glukhov ، تيودور سيغايف ، ألكسندر كوروتكوف ، أوليغ بارتونوف ، ليودميلا مانتروفا)

تمت مناقشة هذا التصحيح نفسه وميزات JSONPath وتاريخ المشكلة بالتفصيل في مقالة منفصلة هنا على المحور JSONPath هو إنجاز رئيسي لـ Postgres Professional وواحد من الابتكارات الرئيسية لـ PostgreSQL 12 بشكل عام.

في عام 2014 ، طور A. Korotkov و O. Bartunov و F. Sigaev امتداد jsquery ، والذي تم تضمينه كنتيجة في Postgres Pro Standard 9.5 (وفي الإصدارات الأحدث من Standard و Enterprise). يوفر ميزات إضافية واسعة جدًا للعمل مع json (b).

عندما ظهر معيار SQL: 2016 ، اتضح أن دلالاته لا تختلف كثيرًا عن دلالاتنا في ملحق jsquery. من الممكن أن يلقي مؤلفو المعيار نظرة سريعة على jsquery ، واخترعوا JSONPath. كان على فريقنا أن ينفذ بطريقة مختلفة قليلاً ما لدينا بالفعل ، وبالطبع الكثير من الأشياء الجديدة أيضًا.

على الرغم من أنه لم يتم الالتزام بعد بتصحيح خاص مع وظائف ، فإن تصحيح JSONPath يحتوي بالفعل على وظائف أساسية للعمل مع JSON (B) ، على سبيل المثال:

jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)')  3, 4, 5 jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)')  0  

بالإضافة إلى ذلك ، تم تحسين بعض الوظائف التي عملت بالفعل مع JSON من قبل. وقد تم ذلك بنجاح من قبل نيكيتا Glukhov.

على سبيل المثال ، المشغل #>> ، المتوافق مع الدالتين jsonb_each_text() و jsonb_array_elements_text() ، يستخدم لتحويل JsonbValue بسرعة إلى نص ، لكنه يعمل ببطء مع الأنواع الأخرى. الآن كل شيء يعمل بسرعة.

2. دعم للبحث السريع عن أقرب الجيران في فهارس SP-GiST (KNN)

(إضافة دعم لعمليات البحث عن أقرب جار (KNN) لمؤشرات SP-GiST. نيكيتا جلوخوف ، ألكسندر كوروتكوف ، فلاد سترزهانوف)

واصل نيكيتا جلوخوف وألكسندر كوروتكوف من شركتنا العمل الذي بدأه فلاد سترزهانوف من مينسك (المعروف أيضًا باسم Quadrocube). كان Postgres أول DBMS يبحث عن أقرب جيرانه - أوراكل و MS سابقًا ، وبطريقة مباشرة وأكثر ملاءمة - وهذا يرجع إلى Oleg Bartunov وفريقه. فكرة هذا البحث هي في خوارزمية اجتياز الشجرة الأصلية ، والتي في معظم الحالات تعطي مكسبًا كبيرًا. يتم استخدام البحث عن أقرب الجيران كثيرًا ، ولكن من الشائع بشكل خاص في نظام المعلومات الجغرافية.

قام فلاد بتصحيح بحث KNN للعمل مع الفهارس المكانية SP-GiST للأشجار الرباعية ، عندما تنقسم الطائرة إلى مربعات ذات حجم ثابت ، وبالنسبة لأشجار KD ، أي الأشجار ثلاثية الأبعاد.

واصل ألكساندر كوروتكوف ، مرشد فلاد GSoC (Google Summer of Code) ، التطوير مع زميل من Postgres Professional Nikita Glukhov. تم تحسين الوظيفة بشكل خطير: تم تحسين التخزين المؤقت للبيانات الداخلية عند إضافة الشجرة ، وفئات المشغلين للدوائر والمضلعات مع الطلب عن بعد.

لاستخدام أقرب خوارزمية البحث المجاورة ، ما عليك سوى كتابة ORDER BY [, ] ، وبعد ذلك سيقوم المحسن بتوصيل هذه الخوارزمية تلقائيًا. على سبيل المثال

 SELECT * FROM polygons ORDER BY poly <-> point '(0,0)'; 

يمكن رؤية بقع نيكيتا Glukhov على جيثب .

3. الأمثل من الأقفال لتسريع الإدراج في مؤشرات B- شجرة

(في ملاحظات الإصدار ، هذا هو تحسين سرعة إدخالات مؤشر btree من خلال تقليل تأمين الحمل. الكسندر كوروتكوف)

تمكن ألكساندر كوروتكوف ، كبير مهندسي الأنظمة في Postgres Professional ، من التوصل إلى خوارزمية تأمين معقولة عند إدراجها في فهارس B-tree. يكون الكسب بعد تطبيق هذا التصحيح ملحوظًا في الحالات التي يحدث فيها الإدراج أكثر أو أقل "على التوالي". أظهرت القياسات على خادم 72 النواة أن المكسب يصل في هذه الحالة إلى 50 ٪. مع الإدراج الفوضوي ، فإن المكسب ليس ملحوظًا جدًا.

4. الاقتصادية وول

(قم بتقليل النفقات العامة على كتابة WAL لإنشاء فهرس GiST و GIN و SP-GiST. Anastasia Lubennikova و Andrey V. Lepikhov)

تقلل هذه السلسلة من التصحيحات حركة مرور WAL الناتجة عند إنشاء فهارس GiST و GIN و SP-GiST. يمكنك الآن تسجيل صفحات هذه الفهارس مرة واحدة فقط - في النهاية ، عندما يتم إنشاء الفهرس بالفعل. وفي حالة حدوث خطأ عند إنشاء فهرس الإدخالات في WAL ، لن تظهر المحاولات الفاشلة على الإطلاق. في السابق ، كان هذا ممكنًا فقط عند إنشاء شجرة B و RUM. استخدام تصحيحات آلية WAL العامة .

يتم xlog البرامج النصية للتحقق من حجم xlog . اختبار على قاعدة بيانات IMDB (تنسيق JSON) ، حيث أظهرت سجلات 4M + التي تشغل 4GB:

 CREATE INDEX ON imdb USING gin(jb jsonb_path_ops); 

الطريقة القديمة نفذت 205 ثانية ، WAL 3.2 جيجابايت ، والخوارزمية الجديدة أعطت 133 ثانية ، و 0.4 WAL.

5. الأمثل من المسح الضوئي فقط مؤشر في حالة العديد من الأعمدة.

(اسمح بمسح الفهرس فقط أن يكون أكثر فاعلية في الفهارس التي تحتوي على العديد من الأعمدة. Konstantin Knizhnik)

عند تحليل تشغيل قاعدة بيانات أحد عملاء شركتنا ، تم العثور على أن نفس الاستعلام يتم تنفيذه في بعض الحالات لمدة أطول بنسبة 25٪ مع مسح الفهرس فقط مقارنة بمسح الفهرس (enable_indexonlyscan = off).
حدث هذا عندما تم تنفيذ SELECT في العديد من الحقول ، والتي كانت بشكل أساسي من النوع bytea ، ولم يتم تخزين الإزاحة مؤقتًا ، نظرًا لأن هذه الحقول لا تحتوي على إزاحة ثابتة (انظر أيضًا تقرير نيكولاي شابلوف "What Inside It" ). لتفريغ سمة k-th ، يجب عليك فك حزمة k-1 السابقة. يتطلب تفريغ سجل بسمة واحدة وقت O (N * N) ، حيث N هو عدد الحقول. هذه 25 ٪ حدث بالفعل في 10 حقول.

استخدم Konstantin Knizhnik الخوارزمية المستخدمة عند العمل مع hip: عند الوصول إلى سمة k-th ، يتم أخذ k-1s السابقة وتذكرها ، وينمو الوقت بشكل خطي مع عدد الحقول. بعد تطبيق التصحيح ، يكون وقت التشغيل مع مسح الفهرس وفهرسة المسح هو نفسه من الناحية العملية.

6. السيطرة على الإغراق شرائح WAL إلى القرص

(أضف حدث انتظار لـ fsync of WAL مقاطع. قسطنطين Knizhnik)

تراقب نواة PostgreSQL الكتابة إلى WAL ، ولكنها لا تراقب تدفق مقاطع WAL من الذاكرة إلى القرص ، أي fsync . K. Knizhnik قام بعمل تصحيح يقوم بإنشاء نوع جديد من الأحداث ، يسمى الآن WALSync (الاسم الداخلي للمتغير هو WAIT_EVENT_WAL_SYNC). يمكنك رؤيته في ملصق حدث PG مع شرح "انتظار إلقاء ملف WAL على وحدة تخزين موثوقة". نوقشت هذه المشكلة في قائمة المتسللين البريدية.

عادة ما تكون المدة التي تستغرقها إعادة التعيين غير معروفة: لا يعرف PostgreSQL القياسي كيفية تجميع هذه الإحصاءات. ولكن هناك ملحق pg_wait_sampling مكتوبًا في Postgres Professional. يمكن أن نتحدث عن الأحداث التي تقضيها بوستجرس الوقت. الآن بعد إضافة الحدث ، يمكنك متابعة fsync .

7. دعم لغات جديدة في قواميس stemmer

(تحديث قواميس Snowball الجذعية مع دعم لغات جديدة. آرثر زاكيروف)

نظرًا لأن مؤتمرات Postgres تعقد في نيبال ، فمن الطبيعي جدًا إضافة اللغة النيبالية إلى قاعدة البيانات! لقد تم ذلك. بفضل جهود آرثر زاكيروف ، يمكنك الآن استخدام القاموس النيبالي الجذعي على Snowball .

8. أصبحت وظائف to_timestamp () / to_date () أكثر تسامحًا مع البيانات

(اضبط وظائف to_timestamp () / to_date () لتكون أكثر تسامحًا مع عدم تطابق القالب ، أرتور زاكيروف ، ألكسندر كوروتكوف ، ليودميلا مانتروفا)

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

9. يمكن تدوير السجلات عبر pg_ctl

(السماح بالتحكم في دوران ملف السجل عبر pg_ctl. Kyotaro Horiguchi و Alexander Kuzmenkov و Alexander Korotkov)

بمعنى آخر ، pg_ctl الأداة المساعدة pg_ctl على خيار جديد:

 pg_ctl logrotate [-D _] [-s] 

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

10. القدرة على إنشاء أنواع جديدة من الجداول (التخزين القابل للتوصيل)

(أضف أمر CREATE ACCESS METHOD لإنشاء أنواع جديدة من الجداول. Andres Freund ، Haribabu Kommi ، ألفارو هيريرا ، ألكسندر كوروتكوف ، ديمتري دولجوف)

يعد هذا التصحيح المهم جزءًا أساسيًا من البنية الأساسية لـ API القابلة للتخزين ، وبالتالي التكوين الدولي لمطوري التصحيح. تم تشغيل الأمر CREATE ACCESS METHOD على Postgres منذ الإصدار 9.6. ولكن حتى الثاني عشر ، يمكنك فقط إنشاء طرق الوصول إلى الفهرس. فيما يلي وثائق الإصدار الحادي عشر :

 CREATE ACCESS METHOD  TYPE __ HANDLER _ < ... > __       .      INDEX. 

وفي وثائق 12th قرأت بالفعل : حاليا معتمدة فقط TABLE و INDEX. بالمناسبة ، في الأمر 11th CREATE ACCESS METHOD تم توفيره بواسطة ملحق Postgres Pro ، وفي PostgreSQL الثاني عشر بالفعل.

يعتمد تنفيذ العملية على نوع طريقة الوصول ؛ إذا كان نوع TABLE ، فسوف يقوم table_am_handler ، وإذا كان نوع INDEX ، index_am_handler (سابقًا: بالنسبة لطرق الوصول من النوع INDEX ، يجب أن تكون index_am_handler ). لقد ظهر فصل كامل في وثائق أساليب الجدول.

عند إنشاء جدول ، يمكنك الآن تحديد نوعه:

 CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] _ ( [ < ... > [ USING  ] 

الطريقة من النوع TABLE - وهذا مرجع إلى التخزين القابل للتوصيل. الآن هو heap افتراضيا ، وقبل الآخر ، في الواقع ، لم يكن. حول فئات المشغل هنا

default_table_access_method (string)

تقوم هذه المعلمة بتعيين طريقة الوصول الافتراضية للجدول التي سيتم استخدامها عند إنشاء الجداول أو طرق العرض الملموسة إذا لم يتم تحديد طريقة الوصول بشكل صريح في أمر CREATE ، أو عند تنفيذ أمر SELECT ... INTO ، حيث لا يمكن تعيين طريقة الوصول بشكل صريح. القيمة الافتراضية هي heap . النقاش الكبير في المتسللين يساعد في الحصول على التفاصيل.

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

11. علة: خطأ في أحد الهياكل

quote_all_identifiers إضافية في _dumpOptions. آرثر زاكيروف)

بشكل عام ، لا يوجد شيء خاص ، تم العثور على خطأ في أحد الهياكل التي يستخدمها pg_dump - لقد فاته المترجم. لكن بروس Momjyan نفسه أشاد لهذا الاكتشاف.

يمكن العثور على مشاكل أخرى مع DumpOptions هنا .

12. الشوائب في النسخ المتماثل:

(xlogreader: لا تقرأ ملف كتلة مرتين. آرثر زاكيير)

اكتشف موظف آخر في شركتنا ، وهو مطور pg_probackup Grigory Smolkin ، أن إحدى أدواتنا تباطأت عندما يقرأ xlogreader أرشيف zlib. اتضح أنه في بعض الأحيان يقرأ كتل ملفات WAL مرتين.

إذا تمت قراءة الأرشيفات بطريقة غير متسقة ، فإن الأداء سيء. القراءة المتكررة للكتلة غير متناسقة دائمًا ، حيث يتعين عليك العودة إلى الموضع الذي تم تمريره عن طريق استدعاء وظيفة gzseek() . الآن لا داعي لإعادة القراءة لا يحدث.

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