Приветстваме всички в петък! Остава все по-малко време до старта на курса , затова днес споделяме превод на още един полезен материал по темата.
В процеса на разработка беше извършена впечатляваща работа по подобряване на секционирането на таблиците. Секциониране на таблици — това е функция, която съществуваше в PostgreSQL достатъчно дълго време, но всъщност беше почти несъществуваща до версия 10, в която стана много полезна функция. По-рано заявявахме, че наследяването на таблици е нашето изпълнение на секционирането, и това е истина. Само че този подход ви принуждаваше да свършите по-голямата част от работата ръчно. Например, ако искате кортежите да се вставят в секциите по време на INSERT операциите, трябваше да настроите тригери, за да го направят вместо вас. Секционирането чрез наследяване беше много бавно и трудно за разработване на допълнителни функции върху него.
В PostgreSQL 10 видяхме раждането на „декларативното секциониране“ — функция, предназначена да реши много от проблемите, които бяха неразрешими при използването на стария метод с наследяване. Това доведе до появата на много по-мощен инструмент, който позволява да разделяме данните хоризонтално!
Сравнение на функциите
В PostgreSQL 11 се появи впечатляващ набор от нови функции, които помагат за повишаване на производителността и правят секционираните таблици по-прозрачни за приложенията.
1. Използване на ограничителни изключения
2. Добавя само възли
3. Само за секционирана таблица, която ссылается на несекционирана
4. Индексите трябва да съдържат всички ключови колони на секцията
5. Ограничението за секцията от двете страни трябва да съвпада
Производителност
Тук имаме и добри новини! Добавен е нов метод . Този нов алгоритъм може да идентифицира подходящите секции, преглеждайки условията на заявката WHERE. Предишният алгоритъм, от своя страна, проверяваше всяка секция, за да определи дали може да отговаря на условията WHERE. Това водеше до допълнително увеличение на времето за планиране с увеличаването на броя на секциите.
В 9.6, с секционированием с наследованием, маршрутизация кортежей в секции обычно выполнялась путем написания триггерной функции, которая содержала серию операторов IF для вставки кортежа в правильную секцию. Эти функции могли быть очень медленными при выполнении. С декларативным секционированием, добавленным в 10 версии, это стало работать намного быстрее.
Использвайки секционираната таблица с 100 секции, можем да оценим производителността на зареждане на 10 милиона реда в таблица от 1 колона BIGINT и 5 колони INT.
Производителността на заявката към тази таблица за търсене на един индексован запис и изпълнение на DML за манипулиране на един запис (използвайки само 1 процесор):
Тук виждаме, че производителността на всяка операция значително се е увеличила след PG 9.6. Заявките SELECT изглеждат много по-добре, особено тези, които могат да изключват множество секции по време на планирането на заявките. Това означава, че планировщикът може да пропуска голяма част от работата, която трябваше да върши преди. Например, вече не се изграждат пътища за ненужни секции.
Заключение
Секционирането на таблиците започва да става много мощна функция в PostgreSQL. То позволява бързо извеждане на данни онлайн и трансформирането им в офлайн, без да се чака завършването на бавни масивни DML операции.Това също така означава, че свързаните данни могат да се съхраняват заедно, т.е. до необходимите данни може да се получи достъп много по-ефективно. Подобренията, направени в тази версия, биха били невъзможни без разработчиците, рецензентите и комитърите, които неуморно работят над всички тези функции.
Благодаря им всички! PostgreSQL 11 изглежда просто фантастично!
Ето такава кратка, но доста интересна статия. Споделете коментарите си, а също така не забравяйте да се запишете за , в рамките на който детайлно ще бъде изложена програмата на курса.
Източник: habr.com
