В любом современном интернет сервисе можно выделить всего две основные функции:

• Первая — это авторизация пользователей.
• Вторая — это моментальная отправка некоего события с сервера на клиент.

Первый пункт, думаю, в пояснении не нуждается.

Второй пункт, это клиент серверная технология, но наоборот. Клиент не делает периодически запрос на сервер — есть ли новые сообщения. Сервер, при появлении некоего события, отравляет сообщение сразу клиенту.

Для лучшего понимания сервис не некий сферичный в вакууме. Сервис можно представить как:

• Папка с файлами в облаке. Информация о изменении, добавлении и удалении пересылается другим пользователям или текущему пользователю, но на другие устройства.
• Компьютерная программа чтения логов сервера, при появлении записей «error» отсылающая содержимое записи пользователю на мобильный телефон.
• Видео-глазок (камера), делающий снимки при движении около двери квартиры.
• Сервис получающий телеметрию из приложения android-auto.
• Похожий на предыдущий пункт сервис, позволяющий узнать дошел ли ребенок до школы или пришел из школы домой.

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

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

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

Код скриптов сервера открыт и бесплатен

Привет друзья. Ни для кого не секрет, что работая на крупных проектах со сложной логикой, Active Record становится не помощником, а обузой. Представьте, что вам необходимо сделать очень сложный запрос для PostgreSQL нативным образом (на чистом SQL), где должно присутствовать некоторое количество переменных. Но в Rails есть одна неприятная мелочь, функционал выполнения нативных запросов не позволяет использовать именованные биндинги. Но решение есть :) Опробовано и успешно внедрено на проекте с Rails API 5.2 + Ruby 2.6.0 + Postgres 11.

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

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



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

PGConf.Russia 2019 не за горами — 4 февраля мастер-классы, 5-6го — доклады. В этом году, как и в прошлом, конференция проводится на экономическом факультете МГУ. Активность докладчиков в период сбора докладов была заметно выше, чем в прошлые годы, так что программа будет интересной. Даже молчаливые 1С-ники подтянулись: первый раз (вместе с Инфостартом) удалось собрать целую секцию на тему «Postgres для 1С». Итак, что нас ждёт?

The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет. В базе данных, которую сами англичане назвали «источником истины» для всего онлайн-контента, около 2,3 млн элементов. И в один прекрасный момент они осознали необходимость миграции с Mongo на Postgres SQL — после того, как одним жарким июльским днём в 2015 году процедуры аварийного переключения были подвергнуты суровому испытанию. Миграция заняла без малого 3 года!..

Мы перевели статью, в которой рассказывается, как проходил процесс миграции и с какими сложностями столкнулись администраторы. Процесс долгий, но резюме простое: приступая к большой задаче, смиритесь, что ошибки будут обязательно. Но в конечном итоге, 3 года спустя, британским коллегам удалось отпраздновать окончание миграции. И поспать.

Если одновременно выполняется много операций по изменению схемы БД, сервис не может корректно работать на запись. Разработчик Владимир Колясинский объяснил, какие операции в PostgreSQL требуют длительных блокировок и как команда Яндекс.Коннекта обеспечивает почти стопроцентную доступность сервиса на запись во время выполнения подобных операций. Кроме того, вы узнаете о библиотеке для Django, которая призвана автоматизировать часть описанных процессов.

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

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. В этом предновогоднем выпуске не будем утомлять вас длинным перечнем новостей. С Наступающим Новым Годом!

Релизы

pgAdmin4 3.6

В этой версии добавлены:

• из панели Properties можно дропать несколько объектов одновременно;
• можно импортировать из и экспортировать в определения серверов из базы и в базу данных конфигураций.

pgpoolAdmin 4.0.2

Можно скачать здесь, как и многочисленные предыдущие версии.

dbForge Studio for PostgreSQL v2.0

На этот раз devart выпустила Studio со Standard edition, в которой есть функциональность, не включенная в бесплатную версию Express. 30 дней можно пользоваться Standard edition бесплатно. О различиях Standard и Express можно почитать здесь.

VOPS-2.0

Вышла новая версия расширения PostgreSQL от Postgres Professional для эффективного исполнения векторных операций.

pg_probackup 2.0.25

Новая версия утилиты для бэкапа и восстановления, тоже от Postgres Professional

pgCluu 2.9

Новую версию этой программы на Perl для аудита производительности кластеров с PostgreSQL можно скачать здесь. pgCluu собирает статистику работы не только СУБД, но и системные ресурсы кластера.

postgres_dba 4.0

Вышла новая версия утилиты Николая Самохвалова для администрирования PostgreSQL. В ней появились три новых отчета: список расширений, настройка параметров PostgreSQL и Вакуум: что происходит прямо сейчас. И, конечно, доработки и исправления.

Что делать, когда имеется приложение с закрытым исходным кодом, которое обращается к БД не самым оптимальным образом? Как потюнить запросы, не меняя приложение, а возможно и саму БД?

Если вы не задавались такими вопросами — вы очень успешный и строгий DBA.

Ну а если задавались — позвольте поделиться страданиями и опытом.

В PostgreSQL начиная с очень давних времён аж версии 8.0 вышедшей в далёком 2005 году для восстановления в определённую точку времени использовался специальный файл конфигурации recovery.conf. Этот же файл впоследствии стал использоваться для режима standby и потоковой репликации.

Однако начиная со следующего релиза PostgreSQL 12 больше recovery.conf работать не будет: я его сломал.
Но зачем?

Вас когда-либо просили посчитать количество чего-то на основании данных в бд за последний месяц, сгруппировав результат по каким-то значениям и разбив всё это ещё по дням/часам?
Если да — то вы уже представляете, что вам придётся написать что-то вроде такого, только хуже

SELECT hour(datetime), somename, count(*), sum(somemetric)
from table
where datetime > :monthAgo
group by 1, 2
order by 1 desc, 2

Время от времени самые разнообразные подобные запросы начинают появляться, и если один раз стерпишь и поможешь — увы, обращения будут поступать и в будущем.

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

А что если я скажу, что прямо в PostgreSQL можно создать вьюху, которая на лету будет учитывать только новые поступающие данные в прямо подобном запросе, как выше?

Так вот — это умеет делать расширение PipelineDB

Привет! Это рассказ о том, что нового в нашем плагине для баз данных. Мы выпускаем его, как отдельный продукт DataGrip, и поставляем почти во все другие наши IDE. Будет много картинок и гифок. Для тех, кому лень их смотреть:

• Поддержка Cassandra
• Создание SQL-файлов из объектов схемы
• Новые инспекции
• Много новых штук в автодополнении
• Работа с источником данных через одно подключение
• Новый поиск
• Высококонтрастная цветовая схема

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

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

Релизы

PostgreSQL 11.1
Вместе с этой версией вышли также 10.6, 9.6.11, 9.5.15, 9.4.20 и 9.3.25 (это последний релиз 9.3). В этой версии есть изменения, связанные с безопасностью. Исправили выявленные ошибки. Прочитать о релизах можно здесь, а скачать здесь.


Postgres Pro Standard 11.1.1, 10.6.1, 9.6.11.1, 9.5.15.1, Postgres Pro Enterprise 10.6.1, 9.6.11.1

Эти релизы основаны на соответствующих ванильных версиях PostgreSQL и на предыдущих версиях Standard и Enterprise. В разделе «Замечания к выпуску» в соответствующей версии документации можно прочитать об отличиях от предыдущей версии семейства. Например, в Enterprise 10.6.1 и 9.6.11.1 добавлена поддержка операционной системы Astra Linux «Смоленск» 1.6 и улучшена стабильность автономных транзакций.

pgAdmin 4 version 3.5.

В этом релизе не только исправлены баги (11 штук), но и добавлены новые возможности. Среди них:

• Миграция с Bootstrap 3 на Bootstrap 4
• Можно останавливать сервисные процессы (Backup/Restore/Maintenance...)

Бинарники для Windows и macOS, а также для Python Wheel, Docker-контейнеры и тарболы с исходниками можно скачать отсюда. RPMы и DEBы должны появиться в репозиториях postgresql.org в ближайшие дни.

TimescaleDB 1.0

В анонсе говорится, что это версия годится для использования в промышленном режиме. Эта СУБД, ориентированная на работу с временнЫми рядами, выполнена как расширение для PostgreSQL. Можно запускать разные версии TimescaleDB с одним и тем же экземпляром PostgreSQL Ядро команды разработчиков — выпускники Принстонского Университета.

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

Как знают все хаброписатели, для оформления исходного кода используется специальный тег <source>, который подсвечивает синтаксис. Не секрет также, что подсветка не всегда получается идеальной, и тогда авторы (которым не все равно, как выглядят их статьи) вынуждены заниматься самодеятельностью — расцвечивать свой код с помощью <font color=...>.

Особенно печально все было с PostgreSQL, поскольку подсветка охватывала более или менее стандартный SQL и категорически не понимала специфики нашей СУБД. Шло время, Алексей boomburum старательно исправлял мои font-ы на source (а я — обратно), пока не стало очевидно, что подсветку надо чинить. Наконец Далер daleraliyorov подсказал выход: добавить поддержку PostgreSQL в библиотеку highlightjs, которой пользуется Хабр. И вот — готово, встречайте.

Буквально на днях Яндекс открыл доступ для beta-пользователей к своему новому сервису — Яндекс.Облако. Так вышло, что это событие совпало с необходимостью выбора облачной платформы для одного из наших внутренних проектов и я решил сразу протестировать производительность решений Яндекса.

Для теста я взял PostgreSQL и старый добрый pgbench. Выбор на СУБД пал потому что было интересно протестировать и сравнить производительность не только виртуальных машин, то и managed database сервисов.

Disclaimer: автор не является ни профессиональным админом, ни DBA, ни специалистом по настройке облачных решений. Тестирование проводилось сугубо в личных целях и на объективность не претендует, поэтому прошу воспринимать статью «as is». Внутри не будет какого-то глубокого разбора, но будет экспресс-сравнение с Selectel VPC (на разных дисках) и различными конфигурациями AWS EC2/RDS в части производительности и стоимости решений. Возможно, это сэкономит кому-то немного времени.

Подробности Yandex.Cloud vs Selectel VPC vs AWS под катом.

Часть I. R извлекает и рисует

Конечно, PostgreSQL с самого начала создавалась как универсальная СУБД, а не как специализированная OLAP-система. Но один из больших плюсов Постгреса — в поддержке языков программирования, с помощью которых из него можно сделать что угодно. По изобилию встроенных процедурных языков ему просто нет равных. PL/R — серверная реализация R — любимого языка аналитиков — один из них. Но об этом позже.

R – удивительный язык со своеобразными типами данных — list, например, может включать в себя не только данные разных типов, но и функции (вообще, язык эклектичный, и говорить о принадлежности его к определенному семейству не будем, чтобы не порождать отвлекающие дискуссии). В нем есть симпатичный тип данных data.frame, который подражает таблице РСУБД — это матрица, у которой столбцы содержат разные типы данных, общие на уровне столбца. Поэтому (и по другим причинам) работать в R с базами данных довольно удобно.

Мы будем работать в командной строке в среде RStudio и соединяться с PostgreSQL через драйвер ODBC RpostgreSQL. Их несложно установить.

Поскольку R создавался как этакий вариант языка S для тех, кто занимается статистикой, то и мы приведем примеры из простенькой статистики с простенькой графикой. У нас нет цели знакомить с языком, но есть цель показать взаимодействие R и PostgreSQL.

Обрабатывать данные, хранящиеся в PostgreSQL, можно тремя путями.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Architecture of a high performance GraphQL to SQL engine».

Это перевод статьи про то, как устроен изнутри и какие оптимизации и архитектурные решения несет в себе Hasura — высокопроизводительный легковесный GraphQL сервер, выступающий прослойкой между вашим веб-приложением и базой данных PostgreSQL.

Он позволяет генерировать GraphQL схему на основе существующей базы данных или создать новую. Поддерживает GraphQL Subscriptions из коробки на основе Postgres-триггеров, динамический контроль прав доступа, автоматическую генерацию join’ов, решает проблему N+1 запросов (batching) и многое другое.

Специальный выпуск POSTGRESSO, посвященный выходу официального релиза версии 11.

---

На улице PostgreSQL праздник. После четырех beta вышла PostgreSQL 11 General Availability, то есть официальная версия. В анонсе есть даже приветственное слово Брюса Момджана: «готовя этот релиз, сообщество особенно заботилось о добавлении функциональности, необходимой для работы с очень большими базами данных. Доказано, что PostgreSQL хорошо работает с транзакционными нагрузками, а теперь новая версия — PostgreSQL 11 — облегчит разработчикам еще и создание приложений для Big Data».

В release notes выделяют

• секционирование:
  • добавлено секционирование по хешу;
  • PRIMARY KEY, FOREIGN KEY, индексы (см. ниже на эту тему) и триггеры;
  • секция по умолчанию для записей, вышедших за границы созданных секций;
  • UPDATE по ключу секционирования теперь может автоматически перемещать запись в соответствующую секцию;
  • PostgreSQL научился исключать ненужные секции (partition pruning) во время исполнения запросов SELECT;
• распараллеливание:
  • теперь можно параллельно создавать индекс в случае B-tree;
  • при CREATE TABLE… AS, CREATE MATERIALIZED VIEW и в некоторых случаях запросов с UNION;
  • улучшена производительность в параллельных HASH JOIN и SEQUENTIAL SCAN;
• появились хранимые процедуры, и в них возможно управление транзакциями;
• JIT-компиляция фрагментов запросов, выигрыш на вычислении выражений;
• оконные функции теперь поддерживают все фреймовые опции SQL:2011 стандарта, в том числе расстояния по RANGE у PRECEDING/FOLLOWING, режим GROUPS, возможность исключения строк из фрейма;
• появились покрывающие индексы [не покрывающие, а инклюзивные, строго говоря — прим. POSTGRESSO], использующие выражение INCLUDE при CREATE INDEX;
• из раздела «разное»: ALTER TABLE… ADD COLUMN c значениями NOT NULL по умолчанию: этот вариант команды теперь не перезаписывает все строки таблицы и, следовательно, работает быстро.

Введение

Привет, Хабр!

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

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

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

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

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

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

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

Предыдущая статья с описанием адресов ФИАС и функций для работы с ними в среде PostgreSQL вызвала интерес у небольшой части читателей.

Поэтому имеет смысл описать аналогичные функции на языке PL/pgSQL для работы со списком домов ФИАС, загруженным в базу данных под управлением PostgreSQL.


В первой половине статьи изложены комментарии к реализации функций. Во второй- исходные тексты функций, а также скрипты для создания таблицы с записями домов ФИАС, а также загрузки данных в эту таблицу из файла в формате CSV. Тем из читателей, кого интересуют только исходные тексты, предлагаем сразу перейти к Приложению.

Мы продолжаем знакомить вас с самыми интересными новостями по 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.. Там есть существенные изменения, о них можно прочитать здесь.