PostgreSQL *

Опрос о состоянии PostgreSQL 2022 завершился несколько недель назад, и мы усердно работаем над очисткой и анализом данных, чтобы поделиться с сообществом PostgreSQL максимально полной информацией.

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

Японцы уже в 2018 году научили немецкий GraphHopper строить маршруты по дорогам хранящимся в PostgreSQL.

Как кастомизировать источник данных, и сохранять новые дороги в таблицу правильно?

Статья продолжает наш обзорный цикл о PostgreSQL-операторах для Kubernetes. В первой части мы рассматривали операторы Stolon, Crunchy Data и Zalando. Во второй — KubeDB и StackGres, а также объединили все пять операторов в сравнительную таблицу. В этот раз разбираем решение CloudNativePG, его возможности и особенности, а заодно актуализируем таблицу.

Данный материал был создан на основе одноимённого доклада на PGConf.Online, вошедшего в число самых популярных выступлений конференции. Поскольку тема ограничений по-прежнему сохраняет свою актуальность, а смотреть видео с мероприятий любят не все, появилась эта статья.

Концепция “тупого хранилища”

В последние годы разработчики ПО всё чаще утверждают, что база в их проекте “всего лишь тупое хранилище, и поэтому никакой логики в ней нет”. Откуда такой подход? Обычно он объясняется сложностями миграции, развёртывания, неудобствами при работе с системами контроля исходного кода. Не стоит списывать со счетов и простую человеческую лень: раз всё и так нормально, зачем связываться с логикой в СУБД? Создали таблицы (или, ещё лучше, пусть ORM их создаст!), и всё отлично.

NoSQL для документов

Случай с NoSQL ещё проще – не надо ничего создавать, контролировать и напрягать мозги, всё уже автоматизировано, оно само работает. Этого вполне достаточно, если из базы нужно просто доставать документы по идентификатору, но если требуется решать задачи посложнее, то всё-таки выбирают SQL СУБД. Их использование, однако, ограничивается созданием таблиц и индексов, логика на стороне СУБД и в этом случае видится избыточной.

СУБД: не только технология, но и бизнес-инструмент

Такой подход является очень распространённым (люди вообще ленивы!). Тем не менее, крайне наивно дистанцироваться от хороших возможностей только из-за нежелания заморачиваться и приобретать новые навыки. СУБД – это очень изощрённая система хранения (чтобы понять это, достаточно почитать про уровни изоляции или процедуры резервного копирования). СУБД помогает синхронизировать бизнес-процессы и избежать реальных убытков, иногда в очень крупном размере.

Сегодня я хочу поговорить с вами про такую замечательную вещь как Point in time recovery (PITR) в PostgreSQL.

Механизм восстановления на определенную точку во времени работает таким образом – у нас есть базовый бэкап, созданный при помощи какой-либо утилиты создания бэкапов (например pg_basebackup), а также набор журнальных файлов, постепенно применяя (накатывая) который, мы можем восстановиться до указанной точки.

Звучит это довольно просто, но, как водится, в каждой простой вещи есть какие-то нюансы, вот о них мы сегодня с вами и поговорим.

С этого сообщения в мессенджере началось мое масштабное расследование вопроса, который давно не дает спать многим айтишникам — можно ли вот так взять и переехать с Oracle на «свободную» СУБД PostgreSQL?

Этот вопрос сначала бередил умы только тех, кто был в курсе стоимости закупок лицензий. В крупных компаниях бюджет на это мог составлять несколько десятков миллионов долларов. А потом каждый год поддержка вендора «съедала» ещё 22% от стоимости лицензий. Теперь та финансовая боль сменилась другой, и у компаний поменялся запрос: а можно ли заменить? И главное, можно ли организовать это в разумные сроки и по адекватной стоимости? 

Скажу сразу, что в этом посте не будет технических аспектов миграции с СУБД Oracle на PostgreSQL. Как это делать и как обходить сложности — разберем в следующий раз. Тут же больше поговорим о целесообразности и возможности миграции. С этим мы разбирались в ходе одного проекта, а заодно развенчали строй существующих иллюзий. 

Эта статья завершает цикл о миграции с СУБД Oracle на СУБД PostgreSQL. В первых двух статьях рассматривались проблемы и устоявшиеся способы переноса данных из одной СУБД в другую (часть 1, часть 2). В третьей статье была представлена часть особенностей, которые нужно учесть при переводе хранимого кода с PL/SQL на PL/pgSQL. В сегодняшнем материале рассматривается оставшаяся часть особенностей, адаптация и конвертация кода, включая выбор средств для конвертации.

Глобальные структуры данных уровня пакета

Для таких структур рекомендуется использовать модуль pg_variables. Он позволяет сохранять как скалярные значения, так и множество записей, массивы

При этом нужно понимать, требуется ли собирать статистику для планировщика. Если да, то придётся пользоваться временными таблицами. По возможности, их лучше не использовать слишком интенсивно. Создание и удаление временных таблиц ведёт к изменениям в системном каталоге и сообщениям об инвалидации. Может возникнуть ситуация, когда серверным процессам для своей работы придётся многократно перечитывать системный каталог.

Пример: у одного клиента процессы Postgres тратили большое количество времени на планирование запросов, поскольку они многократно пытались прочитать данные pg_statistic и pg_class и при этом взять соответствующие блокировки на самые распространённые объекты. Соответственно, от создания и удаления временных таблиц на каждую транзакцию пришлось отказаться.

pg_variables можно использовать на реплике – работа с модулем не приводит к изменениям в системном каталоге. Временные таблицы использовать не получится, поскольку реплика не позволяет делать изменения в словаре данных.

В предыдущих статьях о миграции с Oracle на Postgres мы рассматривали перенос данных из одной системы управления базами данных в другую (часть 1, часть 2). Сегодня разговор пойдёт об особенностях работы с кодом приложения при необходимости смены СУБД. В частности, будут рассмотрены следующие вопросы:

Меня зовут Якупов Азат, я дата-архитектор Quadcode, и с вами продолжение саги о типах таблиц в PostgreSQL. В этой части речь пойдёт про кластеризованные, внешние, партицированные и наследуемые таблицы. Посмотрим на примеры их создания, области применения, плюсы и минусы их использования. 

Релизы и коммитфесты Postgres

PostgreSQL 15 Beta 3

В дни майского HighLoad++ Foundation 2022 наша компания объявила о выпуске Postgres Pro Enterprise 14.2.1. С тех пор вышло несколько обновлений, мы расскажем о наиболее свежем из них - Postgres Pro Enterprise 14.4.1, основанном на PostgreSQL 14.4. Этот выпуск включает все новые возможности, появившиеся в PostgreSQL 14, а также исправления ошибок, вошедшие в недавние корректирующие выпуски PostgreSQL. В данной статье мы рассмотрим ключевые возможности Postgres Pro Enterprise 14.4.1 и «ванильной» СУБД PostgreSQL, также доступные пользователям нашего форка.

В PostgreSQL существует большое количество разных типов таблиц. Каждая из них предназначена для решения конкретных задач. Самая распространённая и известная — heap table или стандартная таблица. Про её структуру я рассказывал в прошлой статье. Стандартная таблица позволяет хранить строки, обновлять данные, делать OLAP и OLTP-запросы.  

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

Август в релизном цикле PostgreSQL месяц особенный. Еще не вышла официально 15-я версия, но уже закончился первый коммитфест 16-й версии. И мы можем посмотреть на самые интересные изменения.

Собираем сервер из исходного кода и вперед!

\dconfig server_version

List of configuration parameters
   Parameter    |  Value  
----------------+---------
 server_version | 16devel

Поскольку тема «переезда» c СУБД Oracle на СУБД Postgres не теряет актуальности, продолжаем наш цикл о миграции. Это вторая статья о переносе данных из Oracle в Postgres (первая доступна по ссылке). На этот раз мы подробнее остановимся на секционировании и временных таблицах, а такжe рассмотрим существующий инструментарий для конвертации данных и сокращения времени простоя.

IOT-таблицы в Oracle

В СУБД Oracle есть так называемые IOT-таблицы, Index-Organized Tables. В обычных таблицах данные хранятся в любом порядке. IOT-таблицы хранят данные в структуре B-tree, которая логически отсортирована в порядке, указанном в полях первичного ключа. Данные лежат в листьях индекса и при его обходе и извлечении данных последние будут упорядочены. Стоит отметить, что этот порядок сохраняется. После добавления, обновления или удаления записей данные всё равно будут упорядочены.

В PostgreSQL есть "волшебный" тип индекса GiST, который позволяет быстро искать разные сложные вещи - от интервалов до массивов и даже реализовывать полнотекстовый поиск.

Про его внутреннее устройство и возможности подробно рассказывал Егор Рогов, а я в статье "PostgreSQL Antipatterns: работаем с отрезками в «кровавом энтерпрайзе»" показал, как с помощью расширения btree_gist он позволяет решать типовые бизнес-задачи.

Одной из таких задач является поиск отрезков внутри сегмента со скалярным идентификатором. И если для btree очевидно, что поле с меньшей кардинальностью должно стоять в индексе раньше - индекс от этого и меньше и быстрее (см. "DBA: находим бесполезные индексы"), то так ли это однозначно для btree_gist?

В этой статье я хочу рассказать о не совсем обычном использовании логов — о получении из лог-файлов метрик для Prometheus. Это может быть полезно, когда существующие экспортеры не предоставляют нужные метрики, а писать свой экспортер не хочется или очень затратно.

Привет, Хабр! Меня зовут Владимир Харчиков, я развиваю и сопровождаю Platform V Pangolin в СберТехе. Pangolin ― реляционная СУБД, созданная нами для хранения и обработки данных в высоконагруженных приложениях.

В статье я расскажу, как объединить высокую скорость обработки транзакций и безопасность хранения данных, а именно о реализации функции прозрачного шифрования данных внутри нашей СУБД. Кому эта тема интересна ― прошу под кат.