Рубрика «postgresql»

Введение

Привет!

Хочу поделиться опытом написания миграций для postgres и django. Речь в основном пойдёт про postgres, django же здесь хорошо дополняет, так как из коробки имеет автоматическую миграцию схемы данных по изменениям модельки, то есть имеет довольно полный список рабочих операций по изменению схемы. Django можно заменить на любой любимый фрэймворк/библиотеку — подходы скорее всего будут похожи.

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

Перед тем как пойти дальше позволю себе сделать следующие предположения.

Можно разделить логику работы с базой данных большинства приложений на 3 части:

  1. Миграции — изменение схемы базы данных (таблиц), предположим мы всегда запускаем их в один поток.
  2. Бизнес логика — непосредственная работа с данными (в пользовательских таблицах), работает с одними и теми же данными постоянно и конкурентно.
  3. Миграции данных — не изменяют схемы данных, работают по сути как бизнес логика, по умолчанию, когда будем говорить про бизнес логику, будем также подразумевать и миграции данных.

Даунтайм — это состояние, когда часть нашей бизнес логики не доступна/падает/грузится на заметное для пользователя время, предположим это пару секунд.

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

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

image

Читать полностью »

Дайджест новостей из мира PostgreSQL. Выпуск №10 - 1

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

PostgreSQL 11 Beta 4
В этом релизе починили баги, выявленные после выхода Beta 3. В том числе:

  • теперь отключена по умолчанию JIT-компиляция.
  • имена в constraint-ах должны быть уникальны.
  • убрали утечку памяти при обращении к XMLTABLE
  • исправили ошибки в хранимых процедурах
  • доработали секционирование, в том числе выбор секций в момент исполнения (runtime partition pruning)

Подробнее здесь.

PostgreSQL 10.5
В этом релизе несколько десятков исправлений, касающихся WAL, libpq, VACUUM и FREEZE, индексов GIN, распараллеливания запросов, OpenSSL. Вот их список.

Postgres Pro Enterprise 10.5.2.
В этой версии есть следующие нововведения по отношению к Postgres Pro Enterprise 10.5.1, они касаются pgbench:

  • pgbench теперь поддерживает составные команды;
  • с помощью параметра --latency-limit теперь можно ограничить время, отведённое на повторение транзакций. Если при использовании данного параметра значение --max-tries=0, транзакции могут повторяться неограниченное число раз, пока не истечёт время, заданное параметром --latency-limit;
  • при вычислении количества обработанных транзакций и скорости выполнения (TPS) пропущенные и неуспешные транзакции больше не учитываются.

Напомним, за время между нашими выпусками вышел релиз Postgres Pro Enterprise 10.5.1.. Там есть существенные изменения, о них можно прочитать здесь.
Читать полностью »

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

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

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

Приглашаем на Voronezh Game Dev Meetup - 1

17 октября в воронежском офисе Mail.Ru Group пройдёт митап по разработке игр. Разработчики Mail.Ru Group расскажут об интересных методах и инструментах, с которыми им довелось работать, и у вас будет время для обсуждения всех выступлений и обмена опытом.

Участие бесплатное, регистрация обязательна.
Читать полностью »

15 сентября в Авито прошёл митап, на котором мы говорили о масштабировании приложений на PostgreSQL. Сегодня я хочу поделиться материалами с него — видеозаписями, презентациями от докладчиков, показать фото. Также под катом публикую разбор вопросов викторины, которую мы проводили здесь, на Хабре, перед митапом. И рассказываю о своих впечатлениях от встречи.

Материалы с встречи #RuPostgres — видеозаписи, презентации, разбор викторины и фотоотчёт - 1

Читать полностью »

Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме - 1

Масштабирование СУБД – это непрерывно наступающее будущее. СУБД совершенствуются и лучше масштабируются на аппаратных платформах, а сами аппаратные платформы наращивают производительность, число ядер, памяти — Ахиллес догоняет черепаху, но все еще не догнал. Проблема масштабирования СУБД стоит во весь рост.

Компании Postgres Professional с проблемой масштабирования довелось столкнуться не только теоретически, но и практически: у своих заказчиков. И не раз. Об одном из таких случаев и пойдёт речь в этой статье.

PostgreSQL неплохо масштабируется на NUMA-системах, если это одна материнская плата с несколькими процессорами и несколькими шинами данных. О некоторых оптимизациях можно почитать здесь и здесь. Однако есть и другой класс систем, у них несколько материнских плат, обмен данными между которыми осуществляется с помощью интерконнекта, при этом на них работает один экземпляр ОС и для пользователя такая конструкция выглядит как единая машина. И хотя формально такие системы можно также отнести к NUMA, но по своей сути они ближе к суперкомпьютерам, т.к. доступ к локальной памяти узла и доступ к памяти соседнего узла отличаются радикально. В сообществе PostgreSQL считают, что единственный экземпляр Postgrs, работающий на таких архитектурах, это источник проблем, и системного подхода к их решению пока нет.
Читать полностью »

В некотором царстве, в некотором государстве... понадобилось мне добавить триггер в модель на pgModeler. Что сделать достаточно легко. А вот добавить триггерную функцию… Тоже легко, но пришлось немного поразбираться с параметрами, предлагаемыми для заполнения/выбора в интерфейсе.

pgModeler — это весьма неплохой инструмент для проектирования баз данных, который умеет генерировать sql-скрипты для PostgreSQL. Подробно об этом инструменте и его возможностях можно почитать на официальном сайте.
Читать полностью »

Когда то видел реализацию «истории записей» — версионирования, на стороне программы, работающей с SQL базой. Перед изменением записи, из базы получалась старая версия, записывалась в XML и полученная строка XML записывалась в отдельную таблицу версий.

Изначально, в своей программе планировал версионирование сделать когда нибудь потом, какой то срочной необходимости не было. Помню, было желание где-то использовать тип данных jsonb, как только додумался до простой и лаконичной реализации версионирования на стороне SQL, не сделать не смог. Всего лишь одна таблица версий с 5 колонками и одна триггерная функция в 3 строчки кода.

Для описания реализации одной таблицы версий мало, поэтому придется описать еще несколько таблиц для примера.

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

Пример таблицы пользователей:

image

Последние два поля на картинке, нужны для таблицы версий, также их можно назвать «автор версии» и «дата версии», но, при желании, можно обойтись без них.
Читать полностью »

Однажды в студёную зимнюю... день понадобился мне бесплатный инструмент для проектирования баз данных. Такой, который бы ещё и скрипты умел генерировать. Очень нравится Visual Paradigm, но стоит он, конечно, как самолёт. Поэтому, вооружившись гуглом и советами знакомых разработчиков, отправился я на поиски.

В итоге набрёл на весьма неплохой инструмент pgModeler. Единственное, не очень понравилось, что sql-скрипты он умеет генерировать только для PostgreSQL. Но т.к. на тот момент (да и сейчас, а то и потом) использовалась эта база данных, то этого инструмента было вполне достаточно.
Читать полностью »