Записки программиста

TimescaleDB — это расширение PostgreSQL для работы с временными рядами (time series). Временные ряды можно хранить в PostgreSQL и просто так, но TimescaleDB обеспечивает большую производительность на том же железе. Также расширение предлагает ряд удобных фичей, специфичных для тайм-серий.

Вот еще одна задача с PostgreSQL, возникшая по работе. Есть таблица с некими событиями. У событий есть уникальный id. В силу специфики приложения id событий не обязательно идут по порядку. Однако в каждом событии есть id следующего и предыдущего события. Требуется написать функции forward(id, steps) и backward(id, steps), возвращающие id события, произошедшего steps событий вперед или назад относительно заданного. Если такого события нет, требуется вернуть пустой результат.

В рамках поста Работа с PostgreSQL в языке Go при помощи pgx был написан микросервис, использующий SQL-запросы в виде обыкновенных строк. Безусловно, это единственный правильный способ работать с РСУБД, однако в некоторых задачах он может быть не очень удобен. Например, если вам нужно генерировать запросы со сложными WHERE-условиями в зависимости от пользовательского ввода. Одно из возможных решений заключается в использовании библиотеки squirrel.

CockroachDB — это распределенная РСУБД, написанная на Go. Является представителем так называемых NewSQL баз данных, которые пытаются совместить в себе горизонтальную масштабируемость и высокую доступность NoSQL решений с интерфейсом (SQL) и строгостью (ACID) традиционных РСУБД. Помимо прочего, CockroachDB интересен тем, что реализует протокол PostgreSQL, что упрощает портирование на него существующих приложений. Давайте же попробуем поднять свой кластер CockroachDB и поработать с ним.

Тут по работе возникла небольшая задачка с PostgreSQL. Интересна задача тем, что в ней достаточно оправдано использование триггеров. Как показывает опыт, не каждый разработчик знаком со «столь продвинутыми» возможностями постгреса. Поэтому мне показалось, что будет неплохой идеей написать про задачу и ее решение.

Многие реальные приложения, написанные на Go, используют ту или иную РСУБД. Притом, последней нередко является PostgreSQL. Для работы с постгресом в мире Go существует больше одной библиотеки, в связи с чем возникает закономерный вопрос — а какую выбрать? Неплохим и достаточно популярным вариантом является jackc/pgx, с которым мы и познакомимся.

Недавно мне понадобилось сходить в PostgreSQL из скрипта на Python. Была предпринята попытка воспользоваться для этого библиотекой py-postgresql, поскольку я успешно использовал ее в прошлом. Но оказалось, что py-postgresql не работает с последними версиями постгреса. В моем случае использовался PostgreSQL 11. Ну что же, тогда не будем выпендриваться, и возьмем используемый всеми psycopg2. Поскольку интерфейс psycopg2 заметно отличается от интерфейса py-postgresql, было решено написать небольшую памятку по использованию данной библиотеки.

Если вы давно читаете этот блог, то можете помнить некоторые старые посты, посвященные мониторингу. В частности, была рассмотрена связка из Graphite, StatsD и CollectD, а также, несколько поверхностно, сервис Datadog. Однако мир не стоит на месте. Приходят новые технологии, некоторые из которых даже оказываются лучше своих предшественников. В качестве таких новых технологий можно привести в пример связку из Prometheus и Grafana.

Типичные веб-проекты, разрабатываемые на чем-то вроде Python или PHP, характерны тем, что создают большое количество соединений к СУБД — по одному, а иногда и по несколько, на каждый HTTP-запрос. Имея классическую архитектуру «один процесс на соединение», PostgreSQL не очень хорошо справляется с большим (условно, больше 100) количеством соединений. Решить проблему позволяет пулер соединений под названием PgBouncer. Благодаря использованию библиотеки libevent, PgBouncer может поддерживать большое количество (тысячи) соединений, которые проксируются на несколько (пара десятков) соединений непосредственно к PostgreSQL.

Сегодня я хотел бы вкратце рассказать о возможности PostgreSQL под названием logical decoding. Данный механизм позволяет подписаться на изменения, происходящие в базе данных, и получать эти изменения в удобном для вас формате, например, в JSON. Logical decoding ни в коем случае нельзя путать с логической репликацией. Logical decoding появился в PostgreSQL намного раньше, в версии 9.4, и является механизмом, на основе которого работает логическая репликация, появившаяся в версии 10.