В СУБД для работы с временными рядами (time series DBMS) есть такое понятие, как ASOF JOIN. Хотя PostgreSQL и не поддерживает данный синтаксис, он позволяет выполнять те же запросы при помощи LATERAL JOIN’ов. Давайте разберемся, что это за JOIN’ы такие, и какую проблему они решают.

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

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

Foreign-Data Wrappers (FDW) — это такая фича в PostgreSQL, позволяющая обращаться к внешним СУБД, а также файлам, веб-сервисам, да и вообще к чему угодно. В настоящее время существует много готовых FDW, в том числе для Oracle, MySQL, Redis, MongoDB, ClickHouse, Kafka, Cassandra и RocksDB. Если нужный FDW еще не написан, вы можете реализовать его самостоятельно. Сегодня мы рассмотрим основы использования FDW, на примере доступа к одному серверу PostgreSQL с другого.

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, с которым мы и познакомимся.