Вопреки расхожему мнению, ответ на главный вопрос жизни, вселенной и всего такого — не 42, а PostgreSQL. (Ну, или всё-таки Postgres).

Введение

Знакомство с PostgreSQL началось примерно в 2003 году в рамках исследовательского проекта ColumbaDB. Самого проекта Columba больше не существует, а PostgreSQL жив и здоров как никогда.

В 2003 году MySQL был куда популярнее PostgreSQL. К тому же MySQL потенциально работал быстрее — просто потому, что не реализовывал все возможности стандарта SQL. Но при этом MySQL не хватало множества нужных функций: полнотекстового поиска, мощных индексов, полноценного соответствия SQL-стандарту. PostgreSQL же ощущался как «настоящая» база данных — этакая уменьшенная версия Oracle, только в одежде open source.

В ходе того исследовательского проекта пришло глубокое понимание баз данных, индексов и возможностей PostgreSQL. Один из важных сценариев — полнотекстовый поиск. Можно было использовать MySQL вместе с отдельной системой вроде Lucene/Solr, чтобы сделать базу данных доступной для поиска. Но это означало бы запуск и поддержку двух систем одновременно. Сложно.

PostgreSQL позволил решить всё в рамках одной системы с помощью плагина полнотекстового поиска. Не нужно синхронизировать данные. Не нужно поддерживать и запускать две системы. Всё просто работало и вызывало улыбку (разумеется, после нескольких настроек). Простота.

С тех пор PostgreSQL применялся во множестве проектов на протяжении карьеры в качестве CTO / временного руководителя. Совсем недавно PostgreSQL использовался для хранения веб-аналитики с очень высоким объёмом данных временных рядов через плагин TimescaleDB. Пример в деле можно увидеть в Privatracker — сервисе веб-аналитики, уважающем приватность посетителей.

Тему с разных сторон обсуждали и другие авторы, и каждый из этих текстов действительно стоит прочтения (SQL is Agile, Stephan Schmidt о применении SQL для всего). Также есть пост в LinkedIn на эту тему.

Тем, кто уже использует PostgreSQL, стоит прочитать хороший материал Hazel Bachrach «What I Wish Someone Told Me About Postgres».

Сила PostgreSQL, по мнению автора, проистекает из трёх источников:

  1. Он надёжен и стабилен.
  2. Его легко запускать, устанавливать и масштабировать.
  3. Он значительно упрощает IT-инфраструктуру, будучи не только реляционной СУБД, но и движком полнотекстового поиска, хранилищем документов и многим другим…

Разберём эти пункты подробнее.

Надёжность и стабильность

PostgreSQL — скучная, проверенная временем технология. Первый релиз PostgreSQL датируется 1996 годом. Система также очень широко используется — и уже очень долго. Устранение багов, особенно в СУБД, требует времени. У PostgreSQL это время было.

У проекта также очень активное сообщество, которое методично добавляет всё новые функции, не ломая старые. За последние годы PostgreSQL получил впечатляющие возможности: хранение JSON-документов, поддержку партиционирования, common table expressions и многое другое. Каждый новый релиз PostgreSQL — событие, приносящее приятные новшества.

Да, PostgreSQL стар — но возможности у него самые современные, и с каждым релизом он становится только лучше.

Простота запуска, установки и масштабирования

PostgreSQL очень легко установить локально. Он входит во все основные дистрибутивы Linux, доступен через Mac brew, а также может быть установлен через приложения вроде PostgresApp.

При запуске тестов удобно использовать Testcontainers с PostgreSQL. Ещё никогда не было так просто гонять тесты против настоящей базы PostgreSQL, на 100% идентичной продакшену.

Если нужно поднять PostgreSQL на сервере, достаточно простого apt-get install. Или запустить его в docker-контейнере.

Все облачные провайдеры позволяют запускать (и масштабировать!) PostgreSQL одним кликом. Выбор огромен:

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

Упрощение IT-инфраструктуры

Запуск PostgreSQL в облаке — уже дело одного клика. Но есть кое-что ещё лучше. PostgreSQL способен заменить множество систем, которые иначе пришлось бы поддерживать отдельно.

PostgreSQL заменяет Solr и Elastic: полнотекстовый поиск

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

Самая впечатляющая статья на эту тему — о том, как Contentful использовал PostgreSQL для полнотекстового поиска пользователей. Это история о простоте, которая обеспечивает рост.

Instacart сделал нечто очень похожее: компания построила современную поисковую инфраструктуру на Postgres вместо запуска отдельного поискового кластера. Та же история, другая компания.

Подробнее по теме: https://www.postgresql.org/docs/current/textsearch.html

PostgreSQL заменяет MongoDB: отличная поддержка JSON

PostgreSQL прекрасно умеет хранить и — что важно — запрашивать JSON. У него есть и специальный тип индекса (GIN), который делает эти операции чрезвычайно быстрыми. Так нужна ли вообще MongoDB?

The Guardian тоже написал отличную статью о том, как перешёл с Mongo на PostgreSQL. Спасибо за наводку, Jan-Otto! Hazel также написала хороший материал про jsonb и нюансы его использования.

PostgreSQL заменяет Kafka и RabbitMQ: PostgreSQL в роли очереди

События, очереди и персистентные логи играют всё большую роль в современных программных системах. Такие системы, как Kafka, RabbitMQ, SQS и другие, обеспечивают эту функциональность. Но их поддержка утомительна, специфична и требует отдельного набора навыков.

Хорошая новость: можно обойтись PostgreSQL. Магия кроется в:

  • SELECT .. FOR UPDATE
  • SELECT .. SKIP LOCKED

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

Статья на crunchydata отлично объясняет эту концепцию.

Совет: начните с PostgreSQL как системы очередей. Переходите на Kafka, RabbitMQ или SQS только тогда, когда производительности PostgreSQL перестанет хватать. Результат может удивить.

PostgreSQL заменяет ClickHouse: данные временных рядов большого объёма

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

Есть специализированные системы вроде ClickHouse (кстати, отличная штука…). Но можно использовать плагин для PostgreSQL, который позволяет делать (почти) то же самое: Timescale.

Опыт использования Timescale положительный, рекомендация подтверждается. Хорошая новость в том, что можно продолжать использовать PostgreSQL даже для больших объёмов данных — без необходимости изучать и поддерживать что-то новое.

PostgreSQL как векторная база данных для AI-workflow

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

Также Timescale недавно анонсировал pgai, который включает pgvector, а также ряд других полезных расширений, значительно упрощающих индексацию данных, вызов LLM-моделей и поиск данных по схожести.

PostgreSQL заменяет Redis: непостоянное высокопроизводительное кеширование

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

Но зачем использовать Redis, если PostgreSQL можно настроить так, чтобы он работал (в большинстве сценариев) так же быстро, как кеш Redis? Секрет — в использовании UNLOGGED-таблицы. Можно даже эмулировать автоматическое истечение срока действия данных Redis с помощью триггера. Об этом уже много написано — остаётся только порекомендовать попробовать на практике.

PostgreSQL заменяет файловую систему: для сырых данных

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

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

Для хранения данных в blob-колонке использовался Flatbuffers, десериализация происходила на клиенте. Этот подход стоит попробовать и в других проектах.

PostgreSQL вместо графовой базы данных

Иерархические данные можно обрабатывать в SQL через рекурсивные запросы. Это работает, но читать, поддерживать и отлаживать такой код крайне сложно. Про производительность и говорить нечего.

Лучший вариант — тип данных LTREE в PostgreSQL. Он не раз помогал реализовать иерархические структуры тегов. Легко читать, легко поддерживать, работает очень быстро.

PostgreSQL вместо микросервиса

Большинство современных «микросервисов» сводятся к моделям, получению данных из базы и возврату JSON клиенту.

Но вот в чём дело: PostgreSQL умеет превращать любой запрос в JSON-результат. Это фактически заменяет серверный middleware. У такого подхода есть свои плюсы и минусы, но он наглядно показывает возможности PostgreSQL. Прекрасную статью на эту тему написал Lukas Eder — она не про PostgreSQL конкретно, но всё описанное там прекрасно реализуемо и в PostgreSQL.

PostgreSQL — замена PlayStation 5

Ну а что, один энтузиаст реализовал Тетрис на common table expressions в чистом SQL. Безумие. И, пожалуй, не стоит воспринимать это слишком серьёзно.

Заключение

Приведённый список далеко не исчерпывающий. PostgreSQL — очень гибкое программное обеспечение, которое можно расширять плагинами практически бесконечно.

Для быстрого движения вперёд нужна простота. Столкнувшись с новым требованием, стоит всегда спрашивать: а не может ли PostgreSQL справиться с этим сам? И правда ли необходима новая блестящая технология X?

PostgreSQL, возможно, не ответ на всё — но он отвечает на куда больше вопросов, чем можно подумать!