, последната версия на "най-добрата в света релационна база данни с отворен код" ще излезе след няколко седмици (ако всичко върви по план). Това отговаря на обичайния график — нова версия с множество нови възможности излиза веднъж годишно и, честно казано, това е впечатляващо. Затова се присъединих активно към общността на 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-дерево индексите, а експериментите с тестове като TPC-C показват, че пространството сега се използва, средно, с 40% по-малко. Сега харчим по-малко време не само за поддръжка на B-дерево индексите (тоест, върху операциите за запис), но и за извличане на данни, тъй като индексите станаха значително по-малки.
Приложенията, които активно обновяват своите таблици — обикновено OLTP-приложения () — ще използват диска значително по-ефективно и ще обработват заявки. Колкото повече място има на диска, толкова по-голямо пространство има базата данни за разрастване без ъпгрейд на инфраструктурата.
Някои стратегии за ъпгрейд изискват повторно строителство на B-дерево индексите, за да се възползват от тези предимства (например, не повтаря индексите автоматично). В предишните версии на PostgreSQL, повторното строителство на големи индекси в таблиците водеше до значителен престой, тъй като в това време не можеха да се извършват промени. Но в PostgreSQL 12 има още едно страхотно нововъведение: сега индексите могат да се строят паралелно с командата , за да се избегне напълно престоят.
В PostgreSQL 12 има и други подобрения в инфраструктурата на индексите. Още едно нещо, където няма как без магия, е , известен още като WAL (журнал на предварителните записи). Журналът на предварителната запис записва всяка транзакция в PostgreSQL за случай на сбой и репликация. Приложенията го използват за архивиране и . Разбира се, журналът на предварителните записи се записва на диска, а това може да повлияе на производителността.
В PostgreSQL 12 разходите за записите WAL, създавани от индексите GiST, GIN и SP-GiST, бяха намалени при изграждането на индекс. Това предоставя няколко осезаеми предимства: записите WAL заемат по-малко място на диска и данните се възпроизвеждат по-бързо, например при възстановяване след срив или възстановяване в определен момент. Ако използвате такива индекси в приложенията си (напр. геопространствени приложения, които много използват индекс GiST на базата на PostGIS), това е още една функция, която значително ще подобри работата без никакви усилия от ваша страна.
Секционирането — повече, по-добре, по-бързо
В PostgreSQL 10 се появи . В PostgreSQL 11 стана много по-лесно за употреба. В PostgreSQL 12 можете да променяте мащаба на секциите.
В PostgreSQL 12 производителността на системата за секциониране стана значително по-добра, особено ако в таблицата има хиляди секции. Например, ако заявката засяга само няколко секции в таблица, в която има хиляди, тя ще се изпълнява много по-бързо. Производителността е подобрена не само за такива типове заявки. Ще забележите и как ускорените операции INSERT в таблици с множество секции.
Записването на данни с — между другото, това е отличен начин и ето пример — в секционирани таблици в PostgreSQL 12 също стана по-ефективно. С COPY всичко беше бързо, а в PostgreSQL 12 наистина лети.
Благодарение на тези предимства в PostgreSQL можете да съхранявате набори от данни с още по-голям размер, а извлечението им стана по-лесно. И без никакви усилия от ваша страна. Ако приложението има много секции, например, ако записва данни за времеви редове, просто актуализиране значително ще подобри производителността му.
И макар това подобрение да не е точно от категорията „надгради и се радвай“, в PostgreSQL 12 можете да създавате външни ключове, които се отнасят към секционирани таблици, така че работата с секционирането да е удоволствие.
Запитванията WITH станаха много по-добри
Когато (също известни като CTE, също известни като запитвания WITH), не можех да дочековам да напиша статия за това, . Това е една от тези функции, които ще ускорят приложението. Разбира се, ако използвате CTE.
Често забелязвам, че начинаещите в SQL обичат да използват CTE: ако ги напишете по определен начин, веднага усещате, че пишете императивна програма. Лично на мен ми беше приятно да пренаписвам тези заявки, за да избегна без CTE и да увелича производителността. Сега всичко е различно.
PostgreSQL 12 позволява вграждането на определен тип CTE без странични ефекти (SELECT), който се използва само веднъж в края на заявката. Ако водех статистика на заявките с CTE, които пренаписвах, повечето от тях щяха да попаднат в тази категория. Това помага на разработчиците да пишат разбираем код, който сега работи бързо.
Още повече, PostgreSQL 12 оптимизира изпълнението на SQL сам, не е нужно да правите нищо. И въпреки че сега вероятно няма да ми се налага да оптимизирам такива заявки, е чудесно, че PostgreSQL продължава да работи по оптимизацията на заявките.
Just-in-Time (JIT) — сега по подразбиране
В системите PostgreSQL 12 с поддръжка JIT-компилацията е включена по подразбиране. На първо място, получавате поддръжка за някои вътрешни операции, а на второ място, изразите в списъците с избор (най-простият пример е x + y), агрегатите, изразите с клаузи 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 вече е по-стабилен от това, което предполагаше, не се ленете да тествате приложенията качествено преди да ги пуснете в продукция.
Източник: habr.com
