PostgreSQL *

Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем:

-- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра;
-- Как GPLv2 помог найти эффективный алгоритм обхода соседей;
-- Как проиндексировали неиндексируемое гиперрёбра;
-- Планирование какого запроса смогли ускорить в 600 раз;
-- Какой изъян в работе существующего планировщика был найден.

Но главный сюжетный поворот — в конце...

Если вы работаете с базами данных, то вам определенно стоит иметь понимание о производительности кластера СУБД. Для этого можно использовать базовые метрики. А можно — метрики от DBaaS в сочетании с Grafana. Они позволяют строить кастомные графики, которые могут быть полезны в той или иной ситуации.

Привет! Меня зовут Рамиль Адильбеков, я DevOps-инженер в Selectel. В этой статье покажу, как можно настроить базовый стек Prometheus/Grafana, подключить метрики от кластера облачных баз данных и загрузить дашборд.

Если вы настраивали отказоустойчивый кластер Postgres, то сталкивались с необходимостью перенаправления пользовательского трафика на пишущий узел после аварии на основном узле и переключения на резервный. Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения.

Разработчик программного обеспечения Postgres Professional Тофиг Алиев расскажет, как мы делали Proxima, какие архитектурные решения заложены в расширение, почему мы выбрали именно такой подход. Разберет тонкости реализации, которые позволили нам обрабатывать более 10 тысяч одновременных клиентских сессий. Рассмотрит примеры использования и ответит на вопросы.

Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.

Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.

TL;DR Иногда «убить» самый тяжёлый JOIN — проще, чем кажется. Достаточно вынести агрегат в коррелированный под-запрос и дать движку опереться на индекс.

Однажды я столкнулся с проблемой, когда почти потерял коммерчески успешный пет-проект из-за устаревших резервных копий БД (ещё до того, как он стал коммерчески неуспешным). При этом, даже после частичного восстановления, все-таки потерял ~30% прибыли от проекта, много нервов и времени.

Это подтолкнуло меня на разработку своего открытого инструмента для бекапа PostgreSQL. С разными хранилищами, уведомлениями при сбоях и health check'ом. Собственно, о том, как я потерял деньги и затем разработал проект — хочу рассказать в статье ниже.

Привет, Хабр! На связи снова Антон Дятлов, инженер по защите информации в Selectel. Буквально несколько дней назад мы с вами рассмотрели установку и безопасную настройку pgcrypto и изучили его основные возможности. Пришло время перейти к практическому применению этих знаний.

В этой статье разберем конкретные сценарии использования pgcrypto в реальных проектах и углубимся в вопросы производительности и проблемы индексирования зашифрованных данных. Отдельно я сформулировал чек-лист лучших практик безопасности и сравнил pgcrypto с альтернативными подходами, чтобы вы могли сделать осознанный выбор для своей архитектуры. Прошу под кат!

Вы когда-нибудь задумывались, что делает Power BI таким быстрым и мощным с точки зрения производительности? Настолько мощным, что он выполняет сложные вычисления над миллионами строк за мгновение.

В этой статье мы подробно рассмотрим, что находится «под капотом» Power BI: как данные хранятся, сжимаются, запрашиваются и, наконец, возвращаются в отчёт. После прочтения, надеюсь, у вас появится лучшее понимание того, что происходит в фоновом режиме, и вы сможете оценить важность создания оптимальной модели данных для достижения максимальной производительности с использованием движка Power BI.

На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся.

Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.

Мы традиционно разрешали пользоваться всеми благами интернета, включая ИИ. На эту тему многие сейчас переживают, но, честно говоря, я пока не вижу причин для беспокойства. Вот если бы все участники показали одинаково прекрасный результат, пришлось бы что-то придумывать. И то, конечно, не запрещать ИИ, а делать задачи более сложными. Но результаты у всех разные, и без собственной головы на плечах их не удалось бы получить (я попробовал), поэтому пока все хорошо. Если финалисты меня читают, было бы интересно услышать комментарии от первого лица: пользовались ли вы ИИ, насколько он вам помог или, может быть, наоборот, только отвлекал?

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

В свободное от работы время, я преподаю курс «Хранение и обработка больших объемов данных», где успел накопить немало наблюдений, кейсов и выводов, которые не хочется держать в столе. Поэтому всё самое полезное оформил в цикл статей на Хабре – рассказываю как строить базы данных с прицелом на рост и не сойти с ума под нагрузкой.

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

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!

Третья часть статьи посвященной трудностям миграции с Firebird на PostgreSQL. (1ая часть, 2я часть).

На апрельской конференции PG BootCamp 2025 в Екатеринбурге был представлен доклад Артёма Бугаенко о том, как сделать статистику Postgres более детализированной, не повышая DST. Однако если посмотреть на доклад под немного другим углом, то ему отлично подошло бы название «Пример создания патча для PostgreSQL». Примеры правки логики планировщика есть во многих патчах, но объяснение того, куда и какой код нужно вставлять в многочисленные файлы исходного кода PostgreSQL, встречается нечасто. Можно встретить примеры описания того, как добавить параметры конфигурации, а вот пример того, как добавить опцию в команду SQL, найти подчас затруднительно. Поэтому если вам требуется добавить в какую-либо команду свою опцию, можно использовать статью, доклад и предложенный докладчиком патч как руководство.

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

Не секрет, что в последние годы различные компании достаточно часто принимают решение о миграции работающей информационной системы с Firebird на PostgreSQL.

Типичная ситуация выглядит так:

Проект работает несколько лет. Заказчик «верит», что проблема не в проекте, а в СУБД. Firebird — «плохая» СУБД.

Привет, Хабр! На связи Антон Дятлов, инженер по защите информации в Selectel. Хранение конфиденциальных данных в PostgreSQL в открытом виде — мина замедленного действия. Неприятности в будущем становятся неизбежными. Достаточно одной успешной SQL‑инъекции, утечки резервной копии или компрометации доступа к серверу, чтобы вся чувствительная информация — от персональных данных пользователей до API-ключей — оказалась в руках злоумышленников.

Даже если все обошлось, то принимать меры защиты все равно придется. Исправлять БД постфактум — задача неблагодарная и крайне рискованная. Шифрование уже существующих данных потребует сложной миграции. Это долго, дорого и не всегда проходит гладко.

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

Новый релиз СУБД Tantor Postgres 17.5 насыщен обновлениями во всех основных аспектах: усиление безопасности, повышение общей производительности, новые расширения, а также инфраструктурные улучшения. Сегодня мы проведем обзор изменений, касающихся работы с высоконагруженными системами 1С. Релиз предлагает не просто несколько точечных исправлений, а целый арсенал специализированных функций, призванных существенно ускорить выполнение типичных для 1С операций, снизить нагрузку на инфраструктуру и упростить администрирование. Спектр улучшений распространился на многие ключевые узлы производительности от оптимизации работы с временными таблицами и сложными запросами RLS (row-level security) до ускорения критически важных процессов наподобие «Закрытия месяца». Обо всем этом и пойдет речь в статье.

Если на собеседовании по System Design не уделить внимание требованиям, это почти гарантированно приведёт к провалу — даже если ваше техническое решение идеально. Игнорирование требований — главная причина провала на собеседовании. Уделите этому 5-10 минут, и ваше решение сразу станет в разы сильнее. Расскажем, как собрать и зафиксировать требования чтобы повысить свои шансы при прохождении собеседования в IT-компанию.

Привет, Хабр!

Сегодня рассмотрим, как работает fillfactor в PostgreSQL — тот самый параметр, который никто не трогает, пока таблицы не начинают раздуваться как на дрожжах. Разберём, зачем он нужен, что происходит при UPDATE, когда стоит менять его вручную и как не наломать дров.

В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.

Типы данных PostgreSQL для работы с вещественными числами:

1) float4, синоним real, синоним float(1..24)

2) float8, синоним float, синоним double precision, синоним float(25..53)

3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.

Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.

Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.

float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:

Переезд крупных, высоконагруженных систем с одной СУБД на другую — всегда вызов, сравнимый с хирургической операцией на работающем сердце. Компания ОТР поделилась уникальным опытом миграции одной из таких систем с Oracle на отечественную Postgres Pro. Ирина Токарева и Сергей Кузнецов из ОТР рассказали о тернистом пути, противостоянии росту энтропии больших объёмов поступающих и изменяемых данных, достигнутых результатах.