PostgreSQL *

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

Давным-давно команда Pangolin состояла из 15-20 человек. Документация по продукту была в зачаточном состоянии. Разработчики сами пилили фичи и сами же их описывали. Но потом Pangolin вырос, вышел на внешний рынок и нам стали нужны профессиональные технические писатели.

А мир техписов разнообразен: здесь есть и редакторы-корректоры, и технари, умеющие развернуть дистрибутив. Техписы без технического опыта не всегда готовы разбираться в сложном продукте. Но, как выяснилось на практике, и технарям, пришедшим в команду, не хватало погружения в тему СУБД, чтобы писать документацию. Попробовав разные варианты, мы нашли для себя такой выход: наши техписы обязательно проходят базовые курсы DBA, и мы берем в команду не только техписов, но и DBA, желающих писать доку.

Под катом расскажу, почему я считаю, что техпису обязательно погружаться в продукт настолько глубоко. Буду рад вашим мнениям.

Кластеризация необходима для большинства СУБД уровня Enterprise. Есть много способов создать или развернуть кластер: от бесплатных до дорогих, от простых до сложных. У разных вендоров свои приоритеты: одни делают настройку кластера в пару кликов (как в MS SQL), другие фокусируются на надежности и функциональности (Oracle).

В мире СУБД на базе PostgreSQL на сторону которых всё активнее переходит российский IT, тоже есть свои кластерные инструменты и решения: как бесплатные и открытые Patroni, Stolon, pacemaker/corosync, так и проприетарные. Лидер по популярности среди открытых решений – Patroni. Сегодня я расскажу, почему настраивать кластеризацию на нем руками весело только первые пару раз. Поговорим об особенностях поддержки Patroni в Proxima DB, снижении порога входа для новичков и повторяемости конфигураций. 

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

За информацию из этой статьи, я был готов заплатить деньги, убить или сходить на концерт Шамана.

Уверен, что мой рассказ будет полезен не только пользователям Superset, но и всем аналитикам, которые используют SQL в своей работе и учёбе.

Не буду рассказывать про базовое построение таблиц на BI системе Superset, с этим прекрасно справятся тонны видео на ютубе и бесполезные курсы (про которые я писал ранее). Но сразу скажу, что суперсет в отличие от некоторых других BI систем начинает раскрываться только если ты знаешь SQL, так что хотим мы этого или нет – погружаться в тонкости языка придётся.

Больше двух недель на поиск оптимального решения, ошибки, костыли и элегантный финал.

Итак, Что такое «Вес в приросте» и чем он отличается от обычного «Прироста», и в чем собственно говоря — сложность?

Разберёмся на примере:

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

Привет, Хабр! Меня зовут Артур Титаев, я аналитик департамента проектирования и разработки IBS. Недавно наша команда занималась масштабным импортозамещением компонентов системы поддержки принятия решений для крупного российского заказчика. После переезда с Oracle и MySQL на PostgreSQL мы определили, что время выполнения SQL-запросов для показателей хозяйственно-экономической деятельности клиента в PostgreSQL заметно больше, чем время выполнения тех же запросов для тех же показателей в Oracle. Для «тяжелых» показателей разница во времени выполнения запроса могла достигать 20–30 минут. И это несмотря на то, что база данных Oracle не была проиндексированной!

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

Миграция ZABBIX с Oracle в PostgreSQL с помощью Ora2pg

Привет, Хабр. Я являюсь действующим АБД в крупной технологической компании. Основное направление работы - это Oracle, PostgreSQL и различные кластерные решения на основе СУБД PostgreSQL. Думаю многим будет полезен опыт миграции БД ZABBIX с Oracle в PostgreSQL, т.к. сам задавшись данным вопросом, не нашел конкретных шагов реализации данной задачи, а пришлось многие моменты реализовывать самому.

Исходные данные: Zabbix 6.0.26, OL8, single instance Oracle 19.12, размер БД - 3 TB.

Конечный результат: Zabbix 6.0.26, OL8, ванильный СУБД PostgreSQL 14.10,смигрированная БД со всеми данными (допускалось отсутствие детализированной информации за время перелива основной пачки данных таблиц history,history_log,history_str,history_text,history_uint,trends,trends_uint).

Инструмент миграции данных - Ora2pg.

Добрый день, коллеги! Как известно, компания "Postgres Professional" более не рекомендует использовать секционирование с использованием pg_pathman, а рекомендует использовать вместо него декларативное секционирование. Однако помимо синтаксического сахара и утилитарного кода по поддержке интервального (в стиле Oracle) секционирования, я обнаружил для себя ещё одну проблему в такой миграции (переходе). Надеюсь, коллеги из PGPro доработают декларативное секционирование к моменту окончательного выпиливания pg_pathman.

Сложилось так исторически, что мы долго не обновляли PostgreSQL и застряли на версии 12. Но пришло время обновлять зависимости проекта и оказалось, что Django 5.1 версию 12 PostgreSQL уже не поддерживает и это мотивировало меня провести обновление до новейшей 16 версии.

На момент написания у нас всё организовано достаточно просто — все необходимые компоненты запускаются в Docker-контейнерах через Docker Compose.

У меня было два варианта, как произвести миграцию:

Из жизни малышей и гигантов

PGlite 0.2

Опенсорсный проект ElectricSQL явил маленькое чудо. Совсем маленькое: сервер PostgreSQL уместился в архив 3МБ.

Сервер сделан как клиентская библиотека TypeScript/JavaScript, PostgreSQL можно запускать в браузере, Node.js и Bun, ничего больше инсталлировать не надо, всё есть. Есть и некий API "live query", для реакции на изменения данных в таблицах. Утверждают, что обычные CRUD-запросы исполняются за 0.3 мс.

Ресурсы:

сайт;

репо;

доки

каталог расширений (22 расширения Postgres, в том числе pgvector, и 1 плагин для PGlite - live);

первые бенчмарки.

Более того: компания Supabase уже запустила сайт postgres.new, построенный поверх PGlite, мол, have fun.

Отчасти это действенный совет, отчасти — вопрос к читателям.

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

В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк –  мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?

Привет, Хабр! Меня зовут Семен Попов, я отвечаю за разработку хранилища клиентских данных в Сбере. Расскажу, как мы в эксплуатации перешли с одной базы данных на другую — а именно, с Oracle на Platform V Pangolin, разработку СберТеха на основе PostgreSQL, доработанного в области безопасности, надёжности и производительности.

Думаю, вы знаете, что поиск эффективных решений – это половина успеха. Я сам прошел через все эти тернии, когда работа с данными казалась слишком сложной и запутанной. И именно тогда я открыл для себя потрясающие возможности PostgreSQL, которые значительно упростили мою жизнь.

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

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

База данных будет подниматься через Docker Compose.

Миграции пишутся вручную и запускаются через Flyway мигратор.

Приложение имеет свой логин и пароль, который отличается от рутового.

Конфигурации для Docker Compose и Flyway генерируются через запуск NestJS-mod в режиме инфраструктуры.

Данная статья является продолжением: PostgreSQL 16. Страницы и версии строк. Часть 3.

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

Хочу поделиться примером‑инструкцией как получить инсайты из геоданных без регистрации, смс (только open‑source и бесплатные инструменты: OSM, python, Портал открытых данных Правительства Москвы, DataLens).

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

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

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

СУБД Postgres Pro – сложный механизм, который можно гибко настраивать под конкретный тип нагрузки. Для этого в нём имеется множество параметров и инструментов. Например, одним из главных потребителей ресурсов CPU является оптимизатор/планировщик запросов, который отвечает за построение оптимального плана выполнения. Существует большое количество параметров, которые прямо или косвенно влияют на работу планировщика, но к их изменению надо подходить очень осторожно, т. к. возможен обратный эффект. Например, параметры _collapse_limit могут и помочь оптимизатору рассмотреть большее количество вариантов планов, и негативно повлиять на время планирования.

Сегодня я расскажу, как мы решали реальную проблему производительности и высокой (> 90%) утилизации ресурсов CPU на промышленном «боевом» сервере с СУБД Postgres Pro Enterprise 15, обслуживающем запросы бизнес-приложения, какие для этого использовали инструменты и что мы изменили в настройках СУБД.

Продолжаем делиться полезными инсайтами с наших корпоративных митапов. Сегодняшний спикер, старший бэкенд-разработчик Factory5 Роман Гордиенко рассказывает об основных понятиях реляционных баз данных и о том, как использовать индексы в PostgreSQL. Информация будет полезна всем, кто работает с реляционными базами данных или планирует это делать в будущем.

Всем привет!

В прошлой статье мы с вами разобрались, как устроена MPP-архитектура Greenplum. Сегодня мы в сотрудничестве с @imzorin углубимся и разберемся, что представляет из себя DDL в этом хранилище. Также постараемся выделить основные моменты, на которые стоит обращать внимание при выборе типа таблиц, дистрибуции и прочего.

Данная статья является продолжением: PostgreSQL 16. Изоляция транзакций. Часть 2.

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