PostgreSQL *

PostgreSQL 10 был выпущен еще в начале октября 2017го, почти год назад.

Одна из наиболее интересных новых “фич” — это безусловно декларативное партиционирование. Но что, если вы не спешите апгрейдится до 10ки? Вот Amazon, к примеру, не торопится, и ввел поддержку PostgreSQL 10 только в последних числах февраля 2018-го.

Тогда на помощь приходит старое-доброе партиционирование через наследование. Я — software architect финансового отдела в компании занимающейся такси, так что все примеры будут так или иначе связаны с поездками (проблемы связанные с деньгами оставим на другой раз).

Поскольку мы начали переписывать нашу финансовую систему в 2015ом, когда я только присоединился к компании, ни о каком декларативном партиционировании речи не шло. Так что и по сей день успешно используется методика описанная ниже.

Изначальной причиной написания статьи стало то, что большинство примеров partitioning’а в PostgreSQL с которыми я сталкивался были очень базовыми. Вот таблица, вот одна колонка, на которую мы смотрим, и быть может даже заранее знаем, какие значения в ней лежат. Казалось бы, все просто. Но реальная жизнь вносит свои коррективы.

Читая многочисленные статьи на хабре об успешной миграции с Oracle на PostgreSQL у неискушенного читателя может создаться впечатление что PostgreSQL ничем не хуже, а даже лучше Oracle. И выбор очевиден. А Сотни тысяч компаний, которые в итоге платят миллиарды долларов компании Oracle, просто тратят деньги на ветер. Но постараюсь вас разуверить, где-где, а в больших компаниях умеют считать деньги. И их решения отнюдь не ошибочны.

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

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

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

Сегодня будем смотреть как и почему может распухать Write-Ahead Log (WAL) постгреса. Как обычно — примеры из реальной жизни в картинках.

Это четвертая и последняя часть статьи, которая описывает пользовательские функции для работы с системными каталогами: pg_class, pg_attribute, pg_constraints и т.д. Первая, вторая и третья части статьи опубликованы ранее.

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

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

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

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

select gs::date
from generate_series('2018-01-31', '2018-05-31', interval '1 month') as gs;

gs
31.01.2018
28.02.2018
28.03.2018
28.04.2018
28.05.2018

15 сентября в офисе Авито состоится встреча, посвященная масштабированию приложений на PostgreSQL. Поговорим об алгоритмах и нюансах реализации транзакционности в языках программирования, построении бизнес-транзакций в сервисах с паттерном database per service, как устроена OZO — асинхронная типобезопасная header-only библиотека-клиент PostgreSQL для C++17, и уровнях изоляции транзакций PostgreSQL. С докладами выступят Стас Кельвич (Postgres Professional), Сергей Хандриков (Яндекс), Константин Евтеев (Авито) и Михаил Тюрин. Регистрируйтесь на встречу и приглашайте коллег. Под катом — тезисы выступлений докладчиков, ссылка на регистрацию и информация по трансляции митапа.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. Между этим выпуском и #8 прошло больше времени, чем обычно, поэтому он будет более объемным.

---

Релизы

PostgreSQL 11 Beta 3
Этот релиз отличается исправленными багами — и общими для серии релизов, о которых дальше, и специфическими для версии 11. Подробности об исправленных (и не только) багах можно узнать здесь. Общая информация о beta здесь.

PostgreSQL 10.5
Исправлены серьезные баги. Например, обнаружена и исправлена проблема в libpq: она не восстанавливала в начальное состояние все переменные состояния соединения при попытке повторного соединения. Не восстанавливалась переменная, которая задавала, нужен ли пароль, из-за чего, используя dblink или postgres_fdw, можно было получить незаконный доступ к серверам.
Всего в релизе около 20 исправлений и улучшений, касающихся самых разных механизмов СУБД: VACUUM, WAL, GIN-индексы, POSIX-семафоров и многого другого. В том числе для работы под Windows. Они расписаны тут.

Вместе с 10.5 и Beta 3 вышли соответствующие обновления 9.6.10, 9.5.14, 9.4.19, 9.3.24. Скачать можно, как обычно, отсюда.

Postgres Pro Standard 9.5.14.1, 9.6.10.1 и 10.5.1
Релизы Postgres Pro Standard 9.5.14.1 и 10.5.1 созданы Postgres Professional на базе соответствующих версий PostgreSQL (без последней цифры в номере релиза, напр PostgreSQL 10.5) и соответствующих предыдущих версий Postgres Pro Standard.

Предистория

Одним прекрасным днём мне понадобилось развернуть среду разработки для своего проекта. Vagrant уже порядком поднадоел и хотелось иметь единую среду разработки для всех участников проекта которая была бы идентичной production серверу. Соответственно наслушавшись информации про хипстерский docker, я решил начать с ним разбираться. Далее я постараюсь максимально подробно описать все шаги начиная от установки докера на локалке вплоть до разворачивания продуктива на KVM.

Исходный стек технологий:

— Docker
— Symfony 4
— nginx
— php-fpm
— postgresql
— elasticsearch
— rabbitmq
— jenkins

Железо:

— ноутбук под ОС Ubuntu 16.04
— продакшн сервер на хостинге KVM

Почему кроме технологического стека я перечислил ещё и стек железа?

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

Первый и наверно самый важный аспект при начале работы с докером — это операционная система вашего ноутбука. Проще всего работать с докером именно на linux системах. Если вы работаете на Windows или Mac то у вас 100 % будут некоторые сложности, но эти сложности не будут являться критическими и при желании «нагуглить» как это исправляется не составит никаких проблем.

Второй вопрос — это хостинг. Зачем нужен Hosting именно с типом виртуализации KVM? Причина в том, что виртуализация VPS разительно отличается от KVM и установить сам docker на VPS у вас попросту не выйдет, так как VPS распределяет ресурсы сервера динамически.

Подитог: для самого быстрого старта на докере резоннее всего выбирать Ubuntu в качестве локальной операционки и KVM хостинг (либо собственный сервер). Далее рассказ пойдёт опираясь именно на эти две составляющие.

Это третья часть статьи, которая описывает пользовательские функции для работы с системными каталогами: pg_class, pg_attribute, pg_constraints и т.д.

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

Привет! Меня зовут Константин Евтеев, я работаю в Авито руководителем юнита DBA. Наша команда развивает системы хранения данных Авито, помогает в выборе или выдаче баз данных и сопутствующей инфраструктуры, поддерживает Service Level Objective для серверов баз данных, а еще мы отвечаем за эффективность использования ресурсов и мониторинг, консультируем по проектированию, а возможно и разрабатываем микросервисы, сильно завязанные на системы хранения, или сервисы для развития платформы в контексте хранилищ.

Я хочу рассказать, как мы решили один из вызовов микросервисной архитектуры — проведение бизнес-транзакций в инфраструктуре сервисов, построенных с помощью паттерна Database per service. С докладом на эту тему я выступал на конференции Highload++ Siberia 2018.

Привет! Этот пост о том, что нового в DataGrip 2018.2. C этой версии поддержка баз данных есть в CLion и AppCode. В WebStorm её можно включить, если вы параллельно используете DataGrip.



— Лог всех запросов
— Новый форматер кода
— Запуск хранимых процедур
— Миграция исходников
— План запроса в виде диаграммы
— Редактирование SQL
— Редактор данных
— Улучшения в пользовательском интерфейсе

Это история о том, почему вы никогда не должны замалчивать ошибки, когда вы внутри транзакции в базе данных. Узнайте, о том как правильно использовать транзакции и что делать, когда их использовать — не вариант. Спойлер: речь пойдёт об advisory locks в PostgreSQL!

Я работал над проектом, в котором пользователи могут импортировать большое количество тяжёлых сущностей (назовём их товарами — products) из внешнего сервиса в наше приложение. К каждому товару при этом загружается ещё больше разнообразных связанных с ним данных с внешних API. Нередка ситуация, когда пользователю нужно загрузить сотни товаров вместе со всеми-всеми зависимостями, в итоге импорт одного товара занимает ощутимое время (30-60 секунд), а весь процесс может порядочно так затянуться. Пользователю может надоесть ждать результата и у него есть право нажать кнопку «Отмена» в любой момент и приложение должно быть полезным с тем количеством товаров, которые удалось загрузить к этому моменту.

Это вторая лекция с Я.Субботника по базам данных — первую мы опубликовали пару недель назад.

Руководитель группы СУБД общего назначения Дмитрий Сарафанников рассказал об эволюции хранилища данных в Яндексе: о том, как мы решили делать S3-совместимый интерфейс, почему выбрали PostgreSQL, на какие грабли наступили и как с ними справились.


— Всем привет! Меня зовут Дима, в Яндексе я занимаюсь базами данных.

Компания pgsentinel выпустила одноимённое расширение pgsentinel (репозиторий github), добавляющее в PostgreSQL представление pg_active_session_history — историю активных сессий (по аналогии с оракловой v$active_session_history).

По сути, это просто-напросто ежесекундные снимки из pg_stat_activity, но есть важные моменты:

1. Вся накопленная информация хранится только в оперативной памяти, а потребляемый объём памяти регулируется количеством последних хранимых записей.
2. Добавляется поле queryid — тот самый queryid из расширения pg_stat_statements (требуется предварительная установка).
3. Добавляется поле top_level_query — текст запроса, из которого был вызван текущий запрос (в случае использования pl/pgsql)

Разбил много кружек в поисках решения для быстрого получения длинных историй цен для большого количества активов в Python. Ещё имел смелость желать работать с ценами в numpy-массивах, а лучше сразу в pandas.

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

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

Слоны

Саймон Риггс, глава 2ndQuadrant, призывает компании поучаствовать в защите слонов, в том числе сообщая о случаях онлайновой торговли слоновой костью.

Релизы

PostgreSQL 11 Beta 2 Released
Выход этого релиза в том числе связан с обнаруженной проблеме со SCRAM. В Beta 1 появилась мажорная фича Channel Binding for SCRAM Authentication (привязка канала) для предотвращения атак с «человеком посередине» (man-in-the-middle). Но при тестировании выяснилось, что libpq не в состоянии гарантировать channel binding. В Beta 2 сама фича не удалена, но удалена документация к ней, а фича потеряла статус мажорной.Подробней о релизе можно прочитать здесь, а скачать Beta 2 можно здесь.

Это вторая часть статьи, которая описывает пользовательские функции для работы с системными каталогами: pg_class, pg_attribute, pg_constraints и т.д.

В этой части статьи обсуждаются функции, возвращающие характеристики ограничений и индексов.

За время работы с PostgreSQL накопилось больше ста функций для работы с системными каталогами: pg_class, pg_attribute, pg_constraints и т.д.


Что с ними делать? Используются они относительно редко. Включить в какой-нибудь проект? Красноярский заказчик за такую «ерунду» платить не будет. И все же, а вдруг они полезны еще кому-то кроме автора. И решил выложить их, как прочитанные книги в общедоступный шкаф для желающих.

В первой части мы рассказали об основных нововведениях и изменениях в PostgreSQL 11. На этот раз чуть подробнее обсудим некоторые моменты в формате вопрос/ответ, которые поднимались на meetup.

Привет! Сегодня я выпустил новую версию ThinkingHome.Migrator — инструмента для версионной миграции схемы базы данных под платформу .NET Core.

Пакеты опубликованы в NuGet, написана подробная документация. Вы уже можете пользоваться новеньким мигратором, а я расскажу, как он появился, почему у него номер версии 3.0.0 (хотя это первый релиз) и зачем он нужен, когда есть EF Migrations и FluentMigrator.