Здравствуйте, это Брюс Момджян.

Я рад приветствовать вас на PG BootCamp Russia. Три года назад первый PG BootCamp прошел в Москве, и вот мы снова здесь, с новой потрясающей программой докладов по PostgreSQL. В этом году впервые запланировано целых три трека, что, насколько я знаю, происходит впервые.

Как вы знаете, для специалистов из России сложно выезжать за пределы страны для участия в мероприятиях по PostgreSQL, и также сложно сейчас приезжать в Россию и выступать на конференциях. Поэтому я рад, что такие мероприятия проводятся, и сообщество PostgreSQL в России продолжает расти.

В России очень сильное сообщество разработчиков, вносящих вклад в исходный код PostgreSQL. На следующей неделе я приступаю к написанию примечаний к выпуску PostgreSQL 19, и я уверен, что в ней будет вклад многих выдающихся специалистов из России, поскольку мы продолжаем получать очень важные дополнения от них.

Я просмотрел фотографии с прошлогодней конференции в Екатеринбурге. Очень понравилось. Вспомнил множество мероприятий, которые я посещал в России, жаль, конечно, что не смогу присутствовать лично. Что же, наберемся терпения, и будем надеяться, что однажды сможем снова встретиться. А сейчас порадуемся предстоящей конференции.

Хотя я не могу приехать в Россию, я буду участвовать в PGDay Armenia 30 апреля, которая находится не так уж далеко от России.

В общем, работа в регионе продолжается. Еще раз хочу поблагодарить организаторов за то, что сделали это мероприятие возможным. Уверен, вы плодотворно проведете время!

• Архив WAL прекрасно решает задачу путешествия по данным в прошлое, как в облаках, так и для on-premise инсталляций. Идея разделений историй по Timeline отличает Postgres от MySQL или MongoDB и упрощает понимание изменений, которые были записаны высокодоступным кластером.

• Вместе с тем не хватает множества функций. Разработчики и админы больше всего скучают по flashback запросам в прошлое, удалённым во времена Postgres 7.

• Интерфейс архивации довольно старый, не удобный, а главное - последовательный, что влияет на производительность. Но современные системы управления архивом научились с этим справляться.

• Декодирование WAL в логический в разных контикстах - хотелось бы уметь делать это без запуска кластера.

В работе структурные доработки для того как работает archive_mode, предлагается создать новый archive_mode=shared чтобы улучшить архивацию во время failover высокодоступного кластера.

• Классика. Selinger DP (1979) оптимален, но только до 12 таблиц. IKKBZ быстр, но требует дерева. DPhyp (2008) понимает гиперграфы и строит bushy-планы — именно он в DuckDB и Umbra.

• Рандом. GEQO в PostgreSQL при более 12 таблиц — генетика. Минусы: недетерминизм, игнорирует startup_cost, скрещивание часто бесполезно. SAIO (имитация отжига) в 2010-м был быстрее, но не взлетел из-за грязного кода и ручных настроек.

• ML-эпоха. Neo предсказывает latency через нейросеть (+18% на JOB), но учится на ошибках PG и переобучается часами. Bao подсказывает hints и гарантирует, что не хуже vanilla PG (+38%). SkinnerDB учится прямо во время выполнения и единственный имеет математические гарантии.

Критика. В 2024 году вышла работа, которая показала: ML-методы достигли успеха из-за утечки данных и игнорирования времени инференса. На большом бенчмарке STACK PostgreSQL оказался стабильнее.

Итог. Генетика и ML — не замена классике, а дополнение. Selinger, DPhyp и эвристики работают здесь и сейчас. Обучаемые методы хороши в исследованиях, но в production пока уступают старой школе.

• Переполнение счетчика транзакций, потеря данных при failover, размножение повреждений через репликацию — всё ещё в работе.
• MVCC, process-per-connection, отсутствие hints и сжатия блоков — либо заброшены, либо живут в расширениях.
• Масштабирование требует полных копий данных на каждой реплике, а шардинг ломает транзакции и JOIN-ы.
Их решение:
Форк PolarDB (Alibaba) и его развитие, Tantor Polar, разделяют вычисления и хранение. Все узлы используют общее блочное устройство (RDMA, NVMe-oF). Реплики не хранят данные, а читают с общего хранилища. Репликация только метаданных (<PageID, LSN>) вместо WAL.
Ключевые доработки:
• PolarFS — распределённая файловая система с переписанным IPC, настоящим fsync() и группировкой POLL-запросов. Запись до 7х быстрее, чтение до 10.9х.
• CSN (Commit Sequence Number) — получение снимка за O(1) вместо сканирования ProcArray. Субтранзакции (SAVEPOINT) больше не убивают производительность.
• WAL Pipeline — конвейерная обработка WAL выделенными потоками, убрана конкуренция за блокировки.
• Shared Server — встроенный пул соединений, хранящий состояние сессии в shared memory. Prepared statements, LISTEN/NOTIFY, advisory locks работают без оверхейда.
• HTAP через ePQ — адаптированный планировщик Greenplum: любой узел становится координатором, аналитика на тех же данных без ETL.
• DataMax для DR — узлы-ретрансляторы с синхронным приёмом WAL (RPO=0) и асинхронной отдачей в другой ЦОД.

Итог:
PostgreSQL обретает экономически эффективное масштабирование, тысячи соединений без деградации, HTAP на одной копии данных и отказоустойчивость уровня enterprise — без переписывания приложений.

• PostgreSQL не поддерживает Read Uncommitted — этот уровень работает как Read Committed. Так что грязного чтения вы не дождётесь.
• Read Committed (по умолчанию) даёт хороший баланс, но внутри одной транзакции данные могут измениться — классическое неповторяющееся чтение.
• Repeatable Read в PostgreSQL сильнее стандарта: он защищает не только от неповторяющегося чтения, но и от фантомов. Однако остаются другие аномалии.
• Serializable — максимальная изоляция, транзакции выполняются так, будто идут одна за другой. Но плата — скорость работы и возможные ошибки сериализации, которые приложение должно обрабатывать.

На демо было видно, как при Read Committed повторный SELECT возвращает свежие данные закоммиченной транзакции, а Repeatable Read «замораживает» снимок на момент первого запроса.

Вывод: выбирайте уровень под задачу. Для большинства веб-приложений достаточно Read Committed по умолчанию. Если важна консистентность сложных отчётов — берите Repeatable Read. Для финансов — Serializable, но будьте готовы повторять упавшие транзакции.

Ответ: тип numeric позволяет хранить и индексировать числа со 131 072 десятичными цифрами до точки. Для больших чисел придется отыскать или сделать расширение.

Ответ: ESB — это зачастую сервер приложений, API которого может подстраиваться под целевые системы и преобразовывать данные между форматами разных систем. Реализация такого в Postgres видится не вполне целесообразной.

Ответ: вся инсталляция нативна, без бинарной транасляция, то есть чистый e2k. Потенциал производительности – да, теряем, но для этого существуют доработанные, т.е. не ванильные, версии PostgreSQL.

Ответ: Процесс разбора обнаруженной ошибки или инцидента производительности ведется внутри нашего же продукта Saby, который сочетает функции как трекера, так и системы внутреннего документооборота.

Ответ: Tantor Polar, как и PostgreSQL, для обеспечения долговечности данных вызывает сброс буферов на диск через аналог fsync() — в API PolarFS это pfsd_fsync() (и соответствующий вызов в libpfs). Без реальной реализации этого вызова нельзя гарантировать, что после сбоя питания или падения узла записанные данные действительно окажутся на постоянном носителе.

В оригинальной открытой реализации PolarFS вызовы pfsd_fsync() и pfs_fsync() были пустыми операциями (noop): они ничего не делали. Причины в коде не задокументированы. Возможные объяснения - в облачной версии PolarFS поверх PolarStore запись могла считаться «автоматически устойчивой» (например, семантика вроде O_SYNC на уровне хранилища). Для блочного устройства (бэкенд PFS_DEV_DISK), которое мы используем, это не применимо. Или же разработчики могли считать, что раз PolarFS использует только небуферизованный I/O (O_DIRECT), явный fsync() не нужен.

На деле O_DIRECT лишь обходит кэш страниц ОС и гарантирует попадание данных в кэш устройства, а не обязательно на энергонезависимый носитель. Считать запись устойчивой можно только если железо гарантирует защиту от потери питания (PLP), а в общем случае — и тем более в программно-определяемом хранилище — полагаться на это нельзя.

Поэтому в нашей доработанной PolarFS исправлено: при вызове pfsd_fsync() / pfs_fsync() теперь принудительно выполняется сброс кэша записи нижележащего блочного устройства (аналог flush на уровне диска). Поведение включается опцией конфигурации diskdev_flush_enable (по умолчанию включено). Это даёт Tantor Polar корректную гарантию долговечности при использовании PolarFS на произвольном блочном устройстве или кластере хранения.

Ответ: Patroni с DCS (etcd/Consul) – единый источник истины о том, кто сейчас мастер. Эпоха увеличивается при каждом failover. Shared storage с fencing – при переключении новый мастер получает эксклюзивное право на запись в общее хранилище. Даже если на реплике случайно или намеренно выполнить promote, эта операция провалится – реплика не сможет перемонтировать storage в режим RW, так как shared storage уже захвачен действующим мастером. HAProxy в этой схеме отвечает только за маршрутизацию клиентского трафика, но не за предотвращение split-brain – эту работу делают Patroni и shared storage. Так что потеря связи с HAProxy не позволяет старому мастеру навредить данным.

ProxySQL с группой репликации – в нашей архитектуре мы используем ProxySQL, в котором группа репликации допускает только один пишущий узел. Роли узлов периодически проверяются в отдельном потоке мониторнга. Это гарантирует, что даже если какой-то узел по ошибке считает себя мастером, пишущий трафик на него не пойдёт. Таким образом, даже при полной потере связи между компонентами, ни один узел не сможет несанкционированно писать в данные.

Ответ: Нет, мы не используем ИИ для анализа логов

Ответ: Если интересуют изменения, то всё-таки - log_statement=mod должно вам подойти - all будет включать в себя и запросы (SELECT), которые вряд ли будут интересовать безопасников. Возможно, отделу безопасности не хочется видеть абсолютно все изменения, а только изменения на каких-то конкретных таблицах? Ведь объём изменений в БД очень велик и со временем он начнёт превышать размер самой БД. Если можно ограничиться конкретными таблицами, то можно посмотреть в сторону дополнительных расширений типа pgaudit или рассмотреть создание триггеров, на интересующих их таблицах. В любом случае, нужно исходить именно от поставленной задачи.