PostgreSQL *

Привет! Меня зовут Дима Татаринов, я занимаюсь бэкенд-разработкой в К2Тех. Мы живем в эпоху «великого переселения» СУБД с SQL Server, IBM DB2 и Oracle на отечественную СУБД Postgres Professional или аналоги. Подобные проекты «паровозиком» цепляют за собой потребность в модернизации бизнес-приложений, которые на них работали. Ранее зарубежные производители накладывали сильный вендор-лок с помощью экосистемы своих инструментов: от специализированного языка написания бизнес-логики (PL/SQL для Oracle) до сервера приложений. Именно поэтому особенно злободневной становится старая шутка про Oracle - «Oracle doesn't have clients. It has hostages» (У Oracle нет клиентов. Есть только заложники). 

Цена освобождения уже стала известна российским вендорам прикладного ПО, которые реализовали в своих продуктах миграцию на отечественные СУБД. Но что делать с тысячами так называемых «учетных систем», которые используют компании на момент принятия решения о миграции. Понятно, что затрат не избежать, но как сделать их предсказуемыми и не получить новый «вендор-лок» взамен старого?  

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

Компания Postgres Professional занимается разработкой и поддержкой СУБД с 2015 года. Это серьёзный срок для компании в ИТ-сфере, и за это время мы видели много случаев, когда клиенты сталкивались с неоптимальным выполнением запросов. Обычно оптимизатор PostgreSQL неплохо справляется и строит хорошие планы, если количества джойнов в запросе не больше 10 и данные в таблицах распределены равномерно. Однако в даже на изначально тщательно продуманной базе данных, оптимизатор может сгенерировать настолько неоптимальный план, что его время выполнения может увеличиться в разы. В некоторых особо экстремальных случаях даже практически невозможно дождаться окончания выполнения запроса и понять при помощи EXPLAIN ANALYZE, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL никак не запоминает допущенные ошибки выполнения. Построив неоптимальный план один раз, он с большей долей вероятности будет делать это снова и снова до тех пор, пока что-то не изменится: статистика, настройки оптимизатора или какое-то внутреннее состояние СУБД.

Другая не менее важная тенденция в области баз данных — уход в облака, где у DBA остается незначительный набор инструментов для исправления проблемных ситуаций и диагностики причин.

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

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

В прошлой части обзора изменений и нововведений Greenplum 7 мы рассмотрели миграцию движка Append Optimized таблиц на использование интерфейса табличных методов доступа, оптимизацию добавления столбцов в таблицы, а также изменения, связанные с поддержкой индексов.

Сегодня мы поговорим об ещё одном новом для Greenplum типе индексов и не только.

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

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

Сейчас мы строим и проектируем 820 тыс. кв. м жилой и коммерческой недвижимости в высших ценовых сегментах. Это 13 девелоперских проектов в престижных районах Москвы. Это колоссальный объём данных, поступающих из разных подразделений: от продуктологов до менеджеров по продажам. Чтобы систематизировать эту информацию и управлять бизнес-процессами, мы реализуем BI-систему для сбора, хранения, анализа и наглядного отображения данных. В этой серии статей рассказываем о том, как мы выстраиваем её в девелоперской компании.

Друзья, в прошлых своих публикациях я рассказывал о том, что почти в каждом своем проекте использую свой класс для работы с базой данных PostgreSQL. На днях этот класс перерос в полноценную библиотеку asynpg-lite на базе asyncpg, которую каждый из вас может прямо сейчас установить и начать использовать.

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

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

Для тестирования примеров, которые я приведу, вам потребуется база данных PostgreSQL. Она может быть установлена как на вашем локальном компьютере, так и располагаться удаленно, например, на VPS-сервере.

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

Система хранения Oracle была очень популярна в России: данные в ней хранили и обрабатывали даже компании из государственного сектора. И всем нам предстояло быстро решить, куда и каким образом перенести огромные объёмы ценной информации, ничего не потеряв в процессе переноса.

PostgreSQL: PostgreSQL 17 Beta 1 Released!

Вышла бета с 188 новшествами. Напомним, что Брюс Момджан недавно подчёркивал важность этого релиза из-за его некоторого уклона в оптимизацию, мол, большое число улучшений в оптимизации, это приятный сюрприз для меня.

В пояснительной записке к релизу тоже начинают с оптимизации. Первым делом рассказывают об изменениях в Vacuum. Там новая внутренняя структура, благодаря которой удалось сэкономить 20% памяти, а также сократить время самой очистки. Последний пункт касается редкой темы: в PostgreSQL 17 улучшена поддержка SIMD-инструкций.

Интересный, важный пункт - управление переключением при логической репликации (failover control for logical replication), важное для отказоустойчивых конфигураций.

В SQL/JSON появилась важнейшая вещь - JSON TABLE, это новый уровень работы с этим форматом. Также появились новые конструкторы и другие функции.

Привет, меня зовут Катя Моисеева, я руководитель направления качества данных в Data Office Tele2. Мы уже рассказывали о том, как с нуля строили процессы качества данных на различных площадках (выступления можно посмотреть по ссылке).

Сейчас для нас остро встал вопрос о ресурсах нашей команды, а точнее их «резиновости» — поток входящих инцидентов растет по мере подключения новых систем к проверкам качества, а команда остается в составе 3 сотрудников. Возникает вопрос — а какая она, идеальная команда качества данных, которая сможет создать процессы с нуля, внедрить и привить культуру внутренним заказчикам, свести к минимуму риски возникновения инцидентов, а еще минимизировать затраты компании?

Под катом поделились своим опытом борьбы с хаосом из потока входящих задач и запросов от бизнеса и о маленьком роботе‑спасителе, который экономит нам ежедневно 5 часов сотрудника DQ и внедрить которого по силам каждому.

Или, точнее, задача, поскольку в этом году мы попробовали другой формат: задача была всего одна, но большая. Требовалось написать SQL-запрос, играющий в крестики-нолики «пять в ряд».

- Что вы ожидаете от Greenplum 7?
- Postgres 12!

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

Как известно, Greenplum является одним из многочисленных форков Postgres, кодовая база которого наконец-то догнала ещё пока поддерживаемую версию Postgres (отмечу, что последний релиз Postgres 12 состоится в ноябре текущего года).

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

Привет, Хабр! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. В последнее время одним из наиболее распространенных способов миграции стала миграция при помощи свободного инструмента ora2pg. Однако многие отмечают его крайне низкую производительность, особенно если речь идет о базах Oracle размером под 1Тб и выше. Как ускорить миграцию и сократить время простоя при переносе проектов при помощи только oracle_fdw, либо в сочетании с ora2pg расскажу далее.

Привет, друзья!

За свою практику программирования я успел написать множество малых, средних и крупных проектов, преимущественно в формате Telegram-ботов. Моя история началась с популярной на то время версии aiogram 2.24 (тех, кто в теме, поймут), а сейчас я полностью перешел на версию 3.x, о чем нисколько не жалею.

В этом посте я хочу начать делиться с вами своим опытом разработки Telegram-ботов через библиотеку aiogram. Сейчас вы читаете вводный пост по этой обширной, но на самом деле не такой уж и сложной теме. Если я увижу положительный отклик, то пойму, что эта информация вам полезна, и мы будем углубляться в разработку ботов все дальше и дальше.

Сегодня мы научимся:

Перефразируя древнюю мудрость: все люди делятся на 10 типов: те, кто не знает, зачем нужны резервные копии, и те, кто делает резервные копии.
В данном обзоре я попробую мал-мала расшифровать свою давнюю табличку (внеся в неё некоторое количество изменений):
Обзор наиболее популярных средств для создания резервных копий PostgreSQL.
Ибо не вижу я ни подобных обзоров в информационном поле, ни грамотного, с технической точки зрения, подхода к выбору инструмента вообще, и для создания резервных копий (РК) СУБД PostgreSQL в тех организациях, куда заносит профессиональная деятельность, в частности. Основной аргумент выбора: знания и умения текущего системного администратора. Доводилось встречаться со сменой инструмента по причине того, что новый администратор баз данных не знал и не умел уже использовавшийся продукт. Причём использовался вполне себе достойный, но... (конкретики не будет, по причинам, например, секретным, увы мне).

В PostgreSQL есть довольно интересный функционал - диапазонные типы данных (range). Они весьма удобны в использовании. Для индексирования этих типов данных существует GIST индекс. Однако на практике часто требуется сочетание BTREE индекса с GIST, что реализуется расширением btree_gist. Насколько эффективно удобство, предоставляемое диапазонными типами данных в сочетании с btree_gist мы и разберем в этой статье.

Для ЛЛ - с производительностью при использовании btree_gist будет плохо.

Привет, Хабр. Сегодня я расскажу вам, как развернуть мощную и супер популярную SQL базу данных PostgreSQL. Для решения этой задачи существует множество способов, но я буду говорить о способе разворачивания при помощи Docker контейнера.

Для старта вам необходимо будет обзавестись VPS сервером (виртуальным или выделенным) с линуксом. Я обычно предпочитаю Ubunta, так что будем рассматривать на ее примере.

После покупки вам предложат способ входа. Обычно это SSH – значит и мы возьмем его за основу.

Допустим данные для входа это:

Спрос на российские СУБД ожидаемо вырос за последние три года.  В этом нет великого предвидения: такова жизнь и так сегодня работает «геополитика». Но в итоге мы очень рады, что начали разработку Proxima DB еще 5 лет назад. В этой статье я расскажу, чем Proxima DB отличается от PostgreSQL, в чем смысл использования нашей платформы, в каких случаях она будет полезна и какие преимущества она дает в конкретных сферах применения. Мы не будем касаться технических подробностей глубоко, потому что это первая ознакомительная статья, сегодня мы постараемся разобраться, когда Proxima DB может дать существенные преимущества, а когда вам будет достаточно ванильной PostgreSQL. А для тех, кто разглядит преимущества платформы для себя, позже я опубликую целую серию технических статей по Proxima DB.

Обычно, обновлением статистик таблиц PostgreSQL занимается демон AUTOVACUUM. Однако, после кардинальных изменений в таблице, к которой сразу же требуется обращаться в последующих запросах к БД, рекомендуется явно обновить статистики этой таблицы явным запуском ANALYZE <имя таблицы>. Команда ANALYZE в PostgreSQL доступна только владельцу таблицы, владельцу базы данных и суперпользователю. При этом иногда возникает необходимость предоставить возможность явного обновления статистик обычному пользователю, не являющемуся владельцем таблицы.

DISCLAIMER: посыл этой статьи не в том, что «PostgreSQL — гавно, не используйте PostgreSQL». Посыл в следующем: «Может быть я чего-то не понимаю в этой жизни? Пожалуйста, объясните, может быть я изменю своё мнение!»

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

«Написать свой собственный ORM» – неплохая задачка для тех, кто решил поглубже изучить некоторые языковые особенности Питона, но в данном случае задача была другая – написать не ORM, а не-ORM. Механизм, упорядочивающий и облегчающий доступ к базам данных, но который сам по себе ни в коей мере не является ORM-ом.