Обновить
149.05

PostgreSQL *

Свободная объектно-реляционная СУБД

Сначала показывать
Порог рейтинга
Уровень сложности

Выжимаем максимум из Postgres на RTABench Q0

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели6.5K

Время от времени приходится слышать мнение, что Postgres никуда не годится для решения задач аналитики. При при этом, в качестве аргументации приводятся в пример результаты тестирования на TPC‑H или ClickBench. Что ж, когда стоит простая задача перебрать 100 млн строк на диске и посчитать набор агрегатов над ними — формат хранения и распараллеливания действительно сильно ограничивают нас в возможностях оптимизации СУБД. Однако когда запросы высоко селективны, им по факту требуется не так много строк таблицы и фокус внимания смещается на порядок JOINов, кэширование промежуточных результатов и минимизацию операций сортировки. В этом случае Postgres, имеющий весьма широкий выбор различных стратегий выполнения запроса, может получить преимущество...

Читать далее

Shardman и Citus: как масштабировать СУБД Postgres Pro

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели9.7K

Когда ресурсы сервера уже на пределе, вертикальное масштабирование рано или поздно перестаёт работать — остаётся горизонтальный подход. В этой статье подробно разбираем два способа шардирования в Postgres Pro: Shardman и внешнее расширение Citus. Сравним архитектуры, межузловое взаимодействие, схемы распределения данных и сценарии, в которых каждое решение раскрывается по‑максимуму.

Читать далее

Резервные копии PostgreSQL: сравнение скорости pg_dump в разных форматах и с разными уровнями сжатия

Уровень сложностиСредний
Время на прочтение33 мин
Охват и читатели9.3K

Я сделал резервную копию через pg_dump и восстановился из неё 22 раза. Резервные копии делал в 4 разных форматах с использованием от 1 до 7 уровней сжатия под каждый формат. Записал результаты и сделал сравнение разных видов, чтобы понимать, какие способы более эффективны для моего сценария использования.

Детали и замеры — ниже.

Читать далее

Немного о кластеризации СУБД в высоконагруженных системах 1С

Время на прочтение9 мин
Охват и читатели9.5K

Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.

Читать далее

Оценка подхода lock-free списков

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели6.1K

Привет, Хабр. Меня зовут Роман Ескин, я один из C разработчиков проекта Greengage DB. В этой статье я расскажу, как мы реализовали и протестировали lock-free подход в рамках масштабной работы по внедрению функции удаления брошенных файлов. Приглашаю вас заглянуть во внутреннюю кухню работы нашей команды при оценке этой функциональности.

Введение

Позвольте начать с краткой исторической справки: Greengage DB был запущен в 2024 году как open-source форк Greenplum — Massively Parallel Processing (MPP) аналитической системы управления базами данных, основанной на PostgreSQL. Мы начали этот проект, чтобы поддержать open-source сообщество Greenplum, который неожиданно стал проприетарным продуктом в мае 2024 года. Мы гарантируем дальнейшее развитие Greengage DB, следуя принципам открытости и прозрачности.

Так как Greengage DB основан на PostgreSQL, он унаследовал некоторые его известные особенности и проблемы. Одна из таких проблем, особенно актуальная в распределенных средах — это проблема "брошенных файлов" (orphaned files).

Эта проблема возникает, когда таблица создается и данные загружаются в рамках активной транзакции. Если происходит критический сбой до того, как транзакция будет закоммичена или отменена (например, внезапное отключение питания или неожиданное завершение работы узла базы данных), система проходит процесс восстановления после падения (crash recovery). При этом логическая таблица откатится, но физические файлы данных, связанные с этой незакоммиченной таблицей, могут остаться в файловой системе. Со временем такие брошенные файлы могут накапливаться, занимая место и приводя к ненужному расходу ресурсов. В настоящее время их удаление происходит вручную.

Недавно мы представили новый функционал, который позволяет автоматически удалять такие брошенные файлы. Полная информация об этой возможности доступна в статье Удаление брошенных файлов в Greengage DB.

Читать далее

Postgresso 5–6 (78–79)

Время на прочтение18 мин
Охват и читатели3.1K

Быки, коровы и квайны

Об олимпиаде незапамятных времён спонсорства Oracle рассказывал ещё bzq aka Евгений Бредня, возглавляющий сейчас техподдержку Postgres Professional, а тогда (2016–2017) он ещё готовил вопросы как сотрудник AT Consulting. Вот части I и II. У Евгения на хабре интересные статьи — и о причудливых задачках, и о техподдержке. Так писали мы в Postgresso № 6 (55). Там же рассказали и уже об актуальных на том момент (2023) задачах 2-го и 3-го этапов, которые готовил Егор Рогов, руководитель программ отдела образования Postgres Professional (задачи для первого готовил не он, а Евгений Моргунов, автор PostgreSQL. Основы языка SQL).

В прошлом году, как известно в том числе из Postgresso #5 (66), организаторы даже выложили огромное видео, в котором был доклад Егора Рогова — в качестве важных материалов, сопутствующих олимпиаде: XV Международная олимпиада в сфере информационных технологий «IT⁠‑⁠Планета 2024». 1-й этап — заочный теоретический тест по PostgreSQL, из почти 3000 человек отобрали примерно 200. Вопросы для этого этапа были подготовлены Евгением Давыдовым. 2-й этап — также заочный. Здесь участникам было предложено подумать над пятью задачами Егора Рогова. Их он и разбирает в этой статье. А финал (3-й этап) Олимпиады проходил очно в Архангельске.

Но это присказки.

Читать далее

Из Excel в SQL. Имеет место быть?

Время на прочтение4 мин
Охват и читатели5.8K

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

Итак, Excel-файл весит 500+ мегабайт, состоит из сотен тысяч строк, десятков листов и формул, которые «протягиваются» по 30+ столбцам — это не работа, а страдание. Именно с таким «монстром» я столкнулся, когда в компании собрались данные из разных отделов в один файл.

Вкратце структура файла — Лист «Массив» (Data_Lake — в левой части 34 столбца с которым работают специалисты и на котором отрабатывают основные формулы и правая часть с 46 столбцами, куда подтягиваются сырые данные, с которыми будет производиться обработка). И множеством листов со справочниками, правками.

Открытие этого Excel‑файла занимает 10 минут, а если обновить хотя бы часть формул — можно идти пить чай. Работать с такими данным и просто невозможно, особенно если тебе нужно анализировать их, строить отчёты или готовить выгрузки. Поэтому решил попробовать все перевести на PostgreSQL.

Для этого всего лишь требовалось переписать формулы с Excel на SQL. Хорошо, что большинство формул это условия ЕСЛИ, ИЛИ.

Вот самая простая формула:

Читать далее

Расширение jsquery для PostgreSQL — точные и быстрые выборки из JSONB

Уровень сложностиПростой
Время на прочтение14 мин
Охват и читатели4.1K

Привет, Хабр! Это Антон Дятлов, инженер по защите информации в Selectel. В современных базах данных JSON — де-факто стандарт для хранения полуструктурированных сведений. PostgreSQL предлагает два специализированных типа для работы с ним: json и jsonb. Первый хранит точную текстовую копию документа со всеми пробелами и порядком ключей. Второй применяет оптимизированный бинарный формат. 

Рассказываем про jsquery — расширение, которое предоставляет полноценный язык для формулирования выборок. Появляется возможность писать декларативные, понятные и очень быстрые инструкции для работы с jsonb-полями.

Читать далее

Как мы успешно прошли тест на 30 000 одновременных пользователей в 1C:ERP (и что мы подкрутили в PostgreSQL)

Уровень сложностиСредний
Время на прочтение19 мин
Охват и читатели10K

Уже давно стали обыденными внедрения решений на платформе 1С:Предприятие на тысячу одновременных пользователей. Есть внедрения и более масштабные. И масштаб внедрений растёт. Поэтому мы решили убедиться, что платформа выдержит нагрузку нашего самого востребованного на крупных внедрениях решения 1C:ERP на 30 000 одновременно работающих пользователях.

Почему именно 30 000 пользователей, как мы измеряли производительность и как добились желаемой производительности — под катом.

Читать далее

Как выжать из СУБД больше производительности? Подкручиваем параметры по урокам Майка Вазовски

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели4.5K

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

Администраторы БД часто ломают голову, как подобрать оптимальные настройки под задачи СУБД. И чтобы помочь им разобраться, мы обратились к опыту Майка Вазовски — тренера легендарного монстра Салли. Вдохновились секретами его тренировок и разработали утилиту Pangolin Tuner — аналог Вазовски для настройки параметров конфигурации. 

Я Кристина Демидович, DevOps-инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. В этой статье покажу на примерах, как всё работает. Прошу под кат.

Майк Вазовски объясняет

pg_dphyp: учим PostgreSQL соединять таблицы по-другому

Уровень сложностиСредний
Время на прочтение62 мин
Охват и читатели2.4K

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

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

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

Читать далее

Использование метрик для мониторинга облачных баз данных на примере PostgreSQL

Время на прочтение4 мин
Охват и читатели2.3K

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

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

Читать далее

Не Pgbouncer, но пулер. Не Odyssey, но с корутинами

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели2.1K

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

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

Читать далее

Ближайшие события

Архитектура Neon: как устроен cloud-native PostgreSQL в Kubernetes

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели2.7K

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

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

1000 Postgres в одном K8s

Когда JOIN тянет ко дну: как одно изменение ускорило запрос в 75 раз

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели2.3K

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

Читать далее

Как я пришёл в open source в 2025-м (с утилитой для бекапа PostgreSQL), чуть не потеряв проект на ~$1500\мес в 2023-м

Уровень сложностиСредний
Время на прочтение5 мин
Охват и читатели15K

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

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

Читать далее

Руководство по pgcrypto — шифрование внутри PostgreSQL. Часть 2

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели1.8K

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

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

Читать далее

Как уменьшить размер модели Power BI на 90%

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели2.8K

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

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

Читать далее

«IT-Планета 2025»: задачи третьего этапа по PostgreSQL

Время на прочтение12 мин
Охват и читатели2.5K

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

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

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

Итак, к задачам

Миграция с Firebird на PostgreSQL. Что может пойти не так? Часть 3

Время на прочтение10 мин
Охват и читатели1.3K

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

Читать далее

Вклад авторов