PostgreSQL наносит ответный удар)
Я думаю все слышали про NoSQL, предлагающие альтернативные реляционной структуре способы хранения данных.
И отъедающие долю рынка у реляционных СУБД.
Но есть и обратный процесс.
Уже писал про расширения для PostgreSQL, как правило NoSQL данные добавляются именно с их помощью.
Что у нас есть на данный момент?
Рассмотрим работу с разными типами данных:
1) time series - TimescaleDB. time series = временная метка и значение какого-то показателя. Самый яркий пример - метрика. Особенности при работе с такими данными: объем данных - т.е. автоматический retention и сжатие, быстрая работа с длинными рядами - простое разбиение на партиции\чанки, агрегация данных из коробки.
2) embeddings - pgvector. Хранение embedding в базе и конечно же векторный поиск по ним
3) полнотекстовый и нечеткий поиск по тексту - встроенные типы данных tsvector и методы из pg_trgm - получаем упрощенный аналог ElasticSearch (OpenSearch). На объемах уровня логов скорее всего упадет, но на меньших...
4) графы - в 19-й версии появилась поддержка SQL/PGQ. Т.е. по сути простой графовый VIEW. Данные хранятся по классике в таблицах, но есть удобный синтаксис для запросов по графу. https://www.postgresql.org/docs/19/sql-create-property-graph.html
5) пространственные данные (spatial) - PostGIS
6) document oriented DB - jsonb конечно не полноценный аналог, но запросы по вложенному JSON писать можно. А если еще добавить сюда Citus - то и шардирование получим, что для таких данных видится частым требованием из-за объема.
К чему это я? Не к тому, что все базы данных убьет PostgreSQL. Вряд ли.
А к тому, что если техстек ограничен и там есть PostgreSQL (а он там есть) - до какого-то масштаба можно обойтись одной базой данных.
И здесь появляется жирный плюс. Рядом - в той же или даже соседней схеме - можно положить реляционные данные и менять все вместе в одной транзакции.
Никаких оркестраторов и хореографии, докатов, никакого двухфазного коммита.
P.S. Кроме того, из PostgreSQL можно сделать key-value storage (но не нужно, кэш и БД вместе все равно держать нет смысла). И объекто-ориентированную БД (но зачем, даже не слышал про использование объектных БД, хотя они есть).
Если смотреть на основные типа БД https://db-engines.com/en/ranking - разве что Wide column не покрыты. Но там не просто произвольный набор столбцов у каждой записи, там еще и append only запись как в Kafka для собственно скорости записи.
#postgresql #data #rdbms #nosql
Я думаю все слышали про NoSQL, предлагающие альтернативные реляционной структуре способы хранения данных.
И отъедающие долю рынка у реляционных СУБД.
Но есть и обратный процесс.
Уже писал про расширения для PostgreSQL, как правило NoSQL данные добавляются именно с их помощью.
Что у нас есть на данный момент?
Рассмотрим работу с разными типами данных:
1) time series - TimescaleDB. time series = временная метка и значение какого-то показателя. Самый яркий пример - метрика. Особенности при работе с такими данными: объем данных - т.е. автоматический retention и сжатие, быстрая работа с длинными рядами - простое разбиение на партиции\чанки, агрегация данных из коробки.
2) embeddings - pgvector. Хранение embedding в базе и конечно же векторный поиск по ним
3) полнотекстовый и нечеткий поиск по тексту - встроенные типы данных tsvector и методы из pg_trgm - получаем упрощенный аналог ElasticSearch (OpenSearch). На объемах уровня логов скорее всего упадет, но на меньших...
4) графы - в 19-й версии появилась поддержка SQL/PGQ. Т.е. по сути простой графовый VIEW. Данные хранятся по классике в таблицах, но есть удобный синтаксис для запросов по графу. https://www.postgresql.org/docs/19/sql-create-property-graph.html
5) пространственные данные (spatial) - PostGIS
6) document oriented DB - jsonb конечно не полноценный аналог, но запросы по вложенному JSON писать можно. А если еще добавить сюда Citus - то и шардирование получим, что для таких данных видится частым требованием из-за объема.
К чему это я? Не к тому, что все базы данных убьет PostgreSQL. Вряд ли.
А к тому, что если техстек ограничен и там есть PostgreSQL (а он там есть) - до какого-то масштаба можно обойтись одной базой данных.
И здесь появляется жирный плюс. Рядом - в той же или даже соседней схеме - можно положить реляционные данные и менять все вместе в одной транзакции.
Никаких оркестраторов и хореографии, докатов, никакого двухфазного коммита.
P.S. Кроме того, из PostgreSQL можно сделать key-value storage (но не нужно, кэш и БД вместе все равно держать нет смысла). И объекто-ориентированную БД (но зачем, даже не слышал про использование объектных БД, хотя они есть).
Если смотреть на основные типа БД https://db-engines.com/en/ranking - разве что Wide column не покрыты. Но там не просто произвольный набор столбцов у каждой записи, там еще и append only запись как в Kafka для собственно скорости записи.
#postgresql #data #rdbms #nosql