Прекарах една седмица във великолепния град Лисабон, присъствайки на годишната европейска PostgeSQL конференция. Това отбеляза 10-ата годишнина от първата европейска PostgreSQL конференция и шестото ми присъствие.
Първи впечатления
Градът беше страхотен, атмосферата беше страхотна и изглеждаше, че ще бъде една много продуктивна и информативна седмица, пълна с интересни разговори с интелигентни и приятелски настроени хора. Така че основно първото страхотно нещо, което научих в Лисабон, е колко страхотни са Лисабон и Португалия, но предполагам, че сте дошли тук за останалата част от историята!
Споделени буфери
Присъствахме на обучителна сесия „PostgreSQL DBA toolbelt за ежедневни операции“
от Kaarel Moppel (Cybertec) . Едно нещо, което отбелязах, беше настройката на shared_buffers. Тъй като shared_buffers всъщност се конкурира или допълва кеша на системата, той не трябва да се задава на стойност между 25% и 75% от общата налична RAM памет. Така че, докато като цяло препоръчителната настройка за типични натоварвания е 25% RAM, тя може да бъде зададена на>=75% за специални случаи, но не и между тях.
Други неща, които научихме в тази сесия:
- за съжаление лесното онлайн (или офлайн) активиране/активиране на контролните суми за данни все още не е в 11 (initdb/логическата репликация остава единствената опция)
- пазете се от vm.overcommit_memory, по-добре го деактивирайте, като го зададете на 2. Задайте vm.overcommit_ratio на около 80.
Разширено логическо репликация
В разговора на Петър Йелинек (2-ри квадрант) , първоначалните автори на логическа репликация, научихме за по-усъвършенствани приложения на тази нова вълнуваща технология:
- Централизирано събиране на данни:може да имаме множество издатели и след това централна система с абонат за всеки от тези издатели, което прави данни от различни източници достъпни в централна система. (типична употреба:OLAP)
- Споделени глобални данни или с други думи централна система за поддържане на глобални данни и параметри (като валути, акции, пазарни/стокови стойности, време и др.), която се публикува на един или повече абонати. Тогава тези данни се поддържат само в една система, но са достъпни за всички абонати.
- Логическата репликация може да бъде асинхронна, но също и синхронна (гарантирано при комит)
- Нови възможности с логическо декодиране:
- интеграция с Debezium/Kafka чрез плъгини за логическо декодиране
- плъгин за wal2json
- Двупосочна репликация
- Надстройки с почти нулев престой:
- настройте логическа репликация на новия сървър (евентуално initdb с активиране на контролни суми за данни)
- изчакайте, докато изоставането стане сравнително малко
- от pgbouncer поставя на пауза базата(ите)
- изчакайте, докато изоставането стане нула
- променете конфигурацията на pgbouncer, за да сочи към новия сървър, презаредете conf на pgbouncer
- от pgbouncer възобнови базата(ите)(и)
Какво е новото в PostgreSQL 11
В тази вълнуваща презентация, Магнус Хагандер (Redpill Linpro AB) ни запозна с чудесата на PostgreSQL 11:
- pg_stat_statements поддържа 64-битов queryid.
- pg_prewarm (метод за затопляне на кеша на системата или споделените буфери):добавяне на нови конфигурационни параметри
- Нови роли по подразбиране, които улесняват отдалечаването от postgres (потребителя имам предвид :) )
- Съхранени процедури с xaction контрол
- Подобрено пълно текстово търсене
- Логическата репликация поддържа TRUNCATE
- Базовите архиви (pg_basebackup) потвърждават контролните суми
- Няколко подобрения в паралелизирането на заявки
- Разделянето на дялове е дори по-прецизно, отколкото в 10
- дял по подразбиране
- актуализации между дялове (премества ред от един дял в друг)
- индекси на локални дялове
- уникален ключ във всички дялове (все още не може да се препраща)
- хеш разделяне
- съединявания на дялове
- агрегати по дялове
- дяловете може да са чужди таблици в различни чужди сървъри. Това отваря страхотни възможности за по-фино раздробяване.
- JIT компилация
zheap:Отговор на проблемите с PostgreSQL надуването
Това все още не е в 11, но звучи толкова обещаващо, че трябваше да го включа в списъка с готини неща. Презентацията беше изнесена от Амит Капила (EnterpriseDB) един от основните автори на тази нова технология, която има за цел евентуално да бъде интегрирана в ядрото на PostgreSQL като алтернативен вид купчина. Това ще бъде интегрирано с новия API за Pluggable Storage в PostgreSQL, който ще поддържа множество методи за достъп до таблица (по същия начин като различните [Индексни] методи за достъп, разгледани в първия ми блог).
Това ще се опита да разреши хроничните недостатъци на PostgreSQL с:
- подуване на масата
- нужда от (автоматично) вакуумиране
- потенциално заобикаляне на идентификатор на транзакция
Всички те не са проблем за средния среден до голям бизнес (въпреки че това е много относително), ние познаваме банки и други финансови институции, които управляват PostgreSQL с десетки TB данни и няколко 1000 транзакции/сек без проблеми. Раздуването на таблицата се обработва чрез автоматично вакуумиране и замразяването на редове решава проблема с обвиването на идентификатора на транзакции, но все пак това не е без поддръжка. Общността на PostgreSQL работи към база данни, която наистина не изисква поддръжка, поради което се предлага архитектурата zheap. Това ще донесе:
- нов дневник за отмяна
- Регистърът за отмяна ще направи данните видими за старите транзакции, виждайки старите версии
- UNDO ще се използва за отмяна на ефектите от прекратени транзакции
- промените се случват на място. Старите версии вече не се съхраняват във файловете с данни.
Цели от високо ниво:
- по-добър контрол на подуването
- по-малко записвания
- по-малки заглавки на кортежи
Това ще постави PostgreSQL наравно с MySql и Oracle в това отношение.
Паралелна заявка в PostgreSQL:Как да не я (зло)използвате?
В тази презентация от Амит Капила и Рафия Сабих (EnterpriseDB) научихме вътрешните битове на паралелизиране, както и съвети за избягване на често срещани грешки, както и някои препоръчителни настройки на GUC:
- паралелизмът поддържа само индекси на B-дърво
- max_parallel_workers_per_gather е зададено на 1→ 4 (в зависимост от наличните ядра)
- обърнете внимание на следните настройки:
- parallel_tuple_cost:цена за прехвърляне на един кортеж от паралелен работен процес към друг процес
- parallel_setup_cost:цена за стартиране на паралелни работници и инициализиране на динамична споделена памет
- min_parallel_table_scan_size:минималният размер на релациите, които трябва да се вземат предвид при сканиране на паралелна последователност
- min_parallel_index_scan_size:минималният размер на индекса, който трябва да се вземе предвид при паралелно сканиране
- random_page_cost:приблизителна цена за достъп до произволна страница на диск
