Мини-гайд: Как ускорить SELECT’ы в PostgreSQL с помощью покрытия индекса (covering index)

Иногда индекс есть, а запрос всё равно тормозит. Почему?

👉 Потому что обычный индекс помогает найти строку, но потом БД всё равно лезет в таблицу, чтобы достать нужные поля. Это называется heap access — и это дорого.

📌 Решение — покрывающий индекс. Это индекс, который содержит все нужные поля прямо в себе. PostgreSQL с версии 11 умеет делать это через INCLUDE.

🔧 Пример:

-- Запрос
SELECT name, email FROM users WHERE status = 'active';

-- Обычный индекс
CREATE INDEX idx_users_status ON users(status);

-- Покрывающий индекс
CREATE INDEX idx_users_status_cover ON users(status) INCLUDE (name, email);

✅ Теперь PostgreSQL может ответить на запрос только по индексу, не трогая таблицу → быстрее.

📈 Особенно заметный профит:
– На больших таблицах
– В OLTP-нагрузках (много коротких запросов)
– Когда важна задержка ответа (например, API)

⚠️ Но не стоит включать весь ряд в индекс — это увеличит размер и замедлит обновления.

Вывод:
Покрывающие индексы — мощный способ ускорить SELECT без изменения запроса. Используй их там, где читаешь часто, а пишешь редко.

Сохрани, пригодится при оптимизации ⚙️

#db

👉 @database_info

💣 NULL — тихий саботаж в твоей БД

На первый взгляд, NULL — просто отсутствие значения. Но на практике это частый источник багов, неверных аналитик и проблем в бизнес-логике.

📉 Антипаттерн: беспечное обращение с NULL

Примеры:

SELECT * FROM users WHERE age > 18;  -- Пользователи с age = NULL не попадут

Ты думаешь, что отбираешь всех взрослых, но age = NULL тут "выпадает", ведь NULL > 18 → UNKNOWN.

WHERE col1 = col2  -- Не сработает, если хотя бы одно значение NULL

🙈 Проблема: NULL не равно даже самому себе (NULL != NULL).
📉 Итоги: ошибки в JOIN'ах, WHERE-фильтрах, расчетах.



🛡 Как защититься:

✅ Явно учитывай NULL:

WHERE age > 18 OR age IS NULL  -- если хочешь включить "неизвестный возраст"

✅ Используй COALESCE:

SELECT COALESCE(discount, 0) FROM orders  -- подставим 0, если скидка не указана

✅ Проверяй NULL через IS NULL / IS NOT NULL

✅ Для агрегаций учитывай поведение NULL:

AVG(column)  -- пропустит NULL'ы, но COUNT(column) тоже не посчитает их!

Вывод:
NULL — не "ничего", а "неизвестно".
Пиши запросы так, как будто NULL всегда где-то прячется — и он не на твоей стороне.

Сохрани, чтобы не ловить грабли 💥

#db

👉 @database_info

Как упростить хранение логов и работу с данными?

В помощь отделу ИБ, DevOps- и SRE-инженерам, дата-аналитикам и разработчикам Selectel предлагает облако для OpenSearch.

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

Кроме производительного железа, бесперебойной работы и быстрого масштабирования в облаке Selectel для OpenSearch вы получите:

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

Создайте кластер в OpenSearch за несколько кликов в Selectel по ссылке: https://slc.tl/yc44k

Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzquyU6q2

Разбор кейса. Компания переехала с MongoDB на PostgreSQL - зачем и что пошло не так.

Стартап хранил всё в MongoDB — быстро, удобно, JSON-документы летят.
Но через год — бизнес растёт, появляются проблемы:


🔸 Запросы тормозят.
Mongo не любит сложные агрегаты с джойнами по коллекциям.
А бизнесу уже нужно:
– аналитика по заказам
– ретеншн-отчёты
– CRM-связи между сущностями

🔸 Дублирование данных.
Документы растут, становятся вложенными, обновлять — боль.
Классическая проблема: “Обновили e-mail юзера — забыли в двух местах”.

🔸 Сложность поддержки.
Без схемы трудно отследить, что где лежит. Новым разработчикам — боль.


🔁 Решение: PostgreSQL

– Явная схема → валидируем данные сразу
– Поддержка JSONB → можно переехать частями
– Сильный SQL → отчёты, джойны, агрегации — на ура
– Надёжность и mature-инструменты для миграций, бэкапов, мониторинга


⚠️ Подводные камни:
– Миграция данных: пришлось писать парсеры и валидаторы
– Пришлось переосмыслить структуру: из “гибкого” хаоса в нормализованную модель
– Команда училась писать SQL и настраивать индексы


✅ Зато теперь:
– Запросы летят
– Данные валидны
– Аналитика возможна
– Рост — без боли


Переход с NoSQL на SQL — это не “откат назад”, это осознанный апгрейд, когда бизнесу нужен контроль, скорость и предсказуемость.

#db

👉 @database_info

PostgreSQL или MySQL?

Один из самых частых вопросов от разработчиков и DevOps — “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇

🔷 PostgreSQL:

* Поддержка JSONB с индексами — почти как NoSQL внутри SQL
* CTE, оконные функции, полнотекстовый поиск — топ для аналитики
* Расширяемость: можно писать свои типы, функции, операторы
* Хорош для сложных запросов, аналитики, геоданных (PostGIS)

🔻 Минусы:
– Сложнее в настройке и оптимизации
– Меньше хостингов out-of-the-box (но всё быстро меняется)



🔶 MySQL (особенно InnoDB / MariaDB):

* Быстрее на простых SELECT/INSERT, если запросы примитивные
* Больше ready-to-go хостингов и тулов для web
* Низкий порог входа — быстрее поднимается новичками

🔻 Минусы:
– Слабее в сложных SQL-конструкциях
– Нет нормальной поддержки CTE до недавнего времени
– JSON без индексации (в MySQL < 8.0)



Вывод:
🧠 Если делаешь CRM, веб-продукт или MVP с простыми запросами — MySQL зайдёт.
📊 Если строишь data-heavy приложения, BI, ETL или гео-системы — PostgreSQL без шансов.

Какой используешь ты и почему? 👇

#db

👉 @database_info

Антипаттерн: SELECT * — удобно, но опасно

Использовать SELECT * — значит звать всех на вечеринку, даже если звал только двоих.

Почему это плохо:
🔹 Излишняя нагрузка на сеть и СУБД — выбираются все столбцы, включая ненужные.
🔹 Проблемы с индексами — СУБД может не использовать покрывающий индекс.
🔹 Ломается при изменении схемы — добавил столбец → внезапно изменилось поведение приложения.
🔹 Сложнее читать и поддерживать — особенно в JOIN’ах.

✅ Как правильно:
Запрашивай только нужные поля:

SELECT id, name, created_at FROM users;

📌 И даже в админках/аналитике лучше явно указывать поля — это дисциплинирует.

Хочешь писать код, который легко масштабировать и отлаживать — забудь про SELECT *.

Сохрани, чтобы не забыть 💾
Поделись с коллегами, которые всё ещё "звёздят" в SQL ✨

#db

👉 @database_info

📕 Борьба с блокировками в PostgreSQL и MS SQL Server для администраторов баз данных, Data engineers, Backend и FullStack-разработчиков.

Как вести работу c PostgreSQL и MS SQL Server без конфликтов и дедлоков.

📗 На вебинаре 20 мая в 20:00 мск разберём:
1. Всё о различных типах блокировок и их механизмах, сходвстах и различиях;
2. Методы предотвращения и разрешения дедлоков;

📘 В результате на практике освоите написание SQL-кода, минимизирующего риски блокировок и дедлоков.

👉 Регистрация и подробности о курсе Базы данных: https://vk.cc/cM56It

Все участники открытого урока получат скидку на курс "Базы данных"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔧 Mini-гайд: ускоряем JOIN-ы в больших таблицах

JOIN-ы — мощный инструмент SQL, но на больших объёмах данных могут стать узким горлышком. Вот 5 проверенных способов ускорить их:


1. Индексы по ключам соединения
Без индекса — каждый JOIN превращается в полный перебор.
➤ Пример:

   CREATE INDEX idx_user_id ON orders(user_id);
   

2. Ограничь объём данных до JOIN-а
Фильтруй и агрегируй данные до объединения.
➤ Вместо:

   SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.country = 'DE';
   

➤ Лучше:

   WITH german_users AS (
     SELECT id FROM users WHERE country = 'DE'
   )
   SELECT * FROM orders o JOIN german_users g ON o.user_id = g.id;
   

3. Учитывай тип JOIN-а
INNER JOIN обычно быстрее OUTER JOIN, особенно при наличии NOT NULL. Иногда EXISTS работает быстрее, чем LEFT JOIN.

4. Следи за типами данных
JOIN по полям с разными типами (например, int и varchar) = неэффективный cast + тормоза.

5. Проверь планы выполнения (EXPLAIN)
Не гадай, а смотри, что реально происходит. EXPLAIN ANALYZE — твой друг.


📌 Даже один лишний JOIN может уронить производительность. Внимательность + EXPLAIN = уверенность.

Поделись с коллегами — спасёшь чей-то прод.

#db

👉 @database_info

❌ Антипаттерн: булевы значения как строки

В таблице users встречал такое:

is_active VARCHAR(5) -- значения 'true' или 'false'

На первый взгляд — ерунда. На практике:
– нет валидации: можно вставить 'tru', 'yes', '0',
– медленнее сравнение, чем у BOOLEAN,
– больше места в хранилище,
– сложно агрегировать и строить аналитику.

🔧 Как надо:

is_active BOOLEAN DEFAULT true

– Экономия места (1 байт против 5 и больше)
– Проверка через WHERE is_active
– Простой COUNT(*) FILTER (WHERE is_active) для отчётов
– Автоматическая поддержка в ORM и UI-форматах

📌 Даже если тебе нужно больше состояний — используй ENUM, а не строку.

💡 Чем проще тип — тем меньше шансов на баг.
Сохрани, если в коде встречал такое — и переделай с чистой совестью.

#db

👉 @database_info

Индексы в PostgreSQL: когда и как ставить, чтобы ускорить запросы

🔍 Что такое индекс?
Индекс в PostgreSQL — это структура данных (обычно B-tree), позволяющая быстро находить строки по значению столбца, не сканируя всю таблицу.


⚙️ Пример создания простого B-tree-индекса

-- Ускоряем поиск по полю email
CREATE INDEX idx_users_email
  ON users (email);

✅ Best Practices

1. Выбирай правильный тип

* BTREE — по умолчанию, для большинства операций сравнения (=, <, >, BETWEEN).
* GIN/GiST — для полнотекстового поиска (tsvector), работы с массивами и геоданных.
* HASH — для строго равенств (=), но редко нужен.

2. Индексируй часто фильтруемые и сортируемые поля

* WHERE, JOIN, ORDER BY.
* Например, для запросов типа

     SELECT * FROM orders
     WHERE user_id = 42
     ORDER BY created_at DESC;
     

создаём составной индекс:

     CREATE INDEX idx_orders_user_created
       ON orders (user_id, created_at DESC);
     

3. Не злоупотребляй

* Каждый индекс занимает место и замедляет INSERT/UPDATE/DELETE.
* Проанализируй pg_stat_user_indexes и pg_stat_user_tables через pg_stat_statements перед добавлением.

4. Используй частичные индексы
Если условие фильтрации редко меняется, можно сузить индекс:

   CREATE INDEX idx_active_users_email
     ON users (email)
     WHERE active = true;
   

5. Поддерживай актуальность
Периодически делай REINDEX или VACUUM ANALYZE для больших таблиц, чтобы индекс не фрагментировался.


❌ Антипаттерн: “Индекс на всё”
Создание индекса на каждый столбец:

-- Плохо: много маленьких индексов, мало пользы, много затрат
CREATE INDEX idx1 ON table(a);
CREATE INDEX idx2 ON table(b);
CREATE INDEX idx3 ON table(c);
... 

Проблемы:

* Большой объём хранилища.
* Замедление DML-операций.
* Планы запросов могут пропускать некоторые индексы.


💡 Вывод
Правильно подобранные и настроенные индексы — ключ к быстрой работе базы. Сосредоточься на реально востребованных столбцах, комбинируй, не забывай про обслуживание.

Сохрани этот мини-гайд, чтобы не забыть, и поделись с коллегами: какие индексы стали для тебя открытием?

#db

👉 @database_info

🔗 Сравнение: Типы JOIN в SQL и когда их применять

Зачем понимать JOIN’ы?
Правильный выбор типа соединения таблиц позволяет получать необходимые данные эффективно и избегать неожиданных «пустых» или дублирующихся строк.


1. Основные типы JOIN и их поведение

INNER JOIN Возвращает только строки, у которых есть совпадения в обеих таблицах. Когда нужно только пересечение данных.

LEFT JOIN Берёт все строки из левой таблицы и совпадающие из правой (NULL, если нет). Когда важно сохранить все данные «слева» даже без пары.

RIGHT JOIN Аналог LEFT, но берёт все из правой таблицы. Редко используется, чаще удобнее поменять местами таблицы.

FULL JOIN Объединяет LEFT и RIGHT: все строки из обеих таблиц, NULL там, где нет пары. Когда нужны все данные из обеих, и нет явного «лево/право».

CROSS JOIN Декартово произведение: каждая строка левой с каждой строкой правой. При генерации матриц или тестовых наборов.


2. Примеры синтаксиса

-- INNER: только общие заказы и клиенты
SELECT o.id, c.name
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id;

-- LEFT: все заказы, даже если клиента нет (NULL)
SELECT o.id, c.name
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id;

-- FULL: все заказы и все клиенты
SELECT o.id AS order_id, c.id AS customer_id
FROM orders o
FULL JOIN customers c ON o.customer_id = c.id;

3. Лучшие практики и советы

1. Всегда уточняйте направление соединения
Понимайте, какая таблица «левее»: от этого зависит полнота результатов.
2. Используйте явный JOIN вместо «старого» синтаксиса через WHERE
Повышает читабельность и уменьшает риск ошибок.
3. Ограничивайте выборку
Добавляйте фильтры (WHERE, ON) до JOIN, чтобы не нагружать соединение лишними данными.
4. Проверяйте результаты на NULL
При LEFT/FULL JOIN обрабатывайте NULL через COALESCE или дополнительные условия.


4. Подводные камни

* Нежелательный CROSS JOIN
Пропущенный условный оператор соединения приведёт к взрывному росту строк.
* Производительность
JOIN’ы на больших таблицах без индексов по ключам могут быть медленными.
* Дублирование
Многократное соединение одной таблицы без корректных условий — источник «дублей».


Вывод: понимание семантики JOIN’ов — ключ к точной и быстрой выборке данных.
Сохрани себе, поделись с коллегами и напиши в комментариях: с каким типом JOIN у тебя чаще всего возникают вопросы?

#db

👉 @database_info

Кейс: Тонкости работы с транзакциями в распределённых БД

Многие знают, что ACID — основа транзакций в классических СУБД. Но как только переходишь к распределённым решениям (например, CockroachDB, Yugabyte, Spanner), возникают интересные нюансы.

Проблема:
В распределённой БД транзакции могут “подвисать” из-за сетевых задержек, split-brain, clock skew и частых реконнектов между узлами. Строгая согласованность (strong consistency) может негативно влиять на производительность и отклик.

Типичные сложности:
– Distributed deadlocks (где одна часть транзакции ждёт другую через сеть)
– Аномалии времени (например, при использовании синхронизации через NTP)
– Цена глобального commit (двухфазный коммит медленный, а трифазный сложный)

Best practices:
– Минимизируй объём данных внутри одной транзакции
– Используй idempotent-операции, чтобы безопасно повторять неудачные транзакции
– Если возможно, проектируй систему под eventual consistency и асинхронные паттерны (saga, outbox)
– Следи за timeouts и обрабатывай partial failures (например, через retry с exponential backoff)

Кодовый пример (Saga-паттерн для микросервисов):

# Пример на псевдокоде
try:
    step1()
    step2()
    step3()
except Exception:
    compensating_action()

Saga разбивает большой бизнес-процесс на независимые шаги с откатом (compensating actions).

Вывод:
В распределённых БД транзакции требуют пересмотра архитектуры. Не полагайся только на “магический” commit — строй систему с учётом ошибок и задержек.

А с какими граблями в распределённых транзакциях сталкивался ты?

#db

👉 @database_info

Мини-гайд: Как не превратить индексы в PostgreSQL в ловушку для производительности

Добавил пару-тройку индексов — стало быстрее? Отлично! Но помни: индексы — это не бесплатная магия. Вот что важно учитывать:

1. Индексы ускоряют SELECT, но тормозят INSERT/UPDATE/DELETE.
Каждая модификация данных требует обновления всех связанных индексов. Чем их больше — тем медленнее запись.

2. Следи за “мертвыми” индексами.
Иногда индексы создают “на всякий случай”, а потом не используют. PostgreSQL сам не удаляет неиспользуемые индексы. Проверь через

SELECT * FROM pg_stat_user_indexes WHERE idx_scan = 0;

— если idx_scan ноль, пора чистить!

3. Избегай дублирующих индексов.
Одинаковые или почти одинаковые индексы — трата ресурсов. Держи только то, что реально нужно для твоих запросов.

4. Регулярно делай REINDEX и VACUUM.
Индексы могут фрагментироваться и “раздуваться” из-за удалённых данных. Периодическая чистка — залог стабильной производительности.

Вывод:
Индексы — мощный инструмент, но требующий внимания. Не ленись мониторить их эффективность, иначе можно только навредить.

Сохрани, чтобы не попасть в индекс-ловушку!

#db

👉 @database_info

📕 Сравнение индексации в PostgreSQL и ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данных

На открытом уроке 3 июня в 20:00 мск мы обсудим различия в механизмах индексации между PostgreSQL и ClickHouse:

📗 На вебинаре разберём:
1. Основы и сравнение производительности разных подходов к индексации;
2. Для каких сценариев распространено использование этих подходов;

📘 В результате на практике разреберете и сравните подходы, производительность и архитектуру индексации PostgreSQL и ClickHouse.

👉 Регистрация и подробности о курсе ClickHouse для инженеров и архитекторов БД: https://vk.cc/cMuQbb

Все участники открытого урока получат скидку на курс "ClickHouse для инженеров и архитекторов БД"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Антипаттерн: N+1 запросов и как его избежать

Что такое N+1?
При выборке связанных данных ORM (или вручную) сначала делается 1 запрос за основными записями, а потом N дополнительных — по одной для каждой записи, чтобы получить связанные объекты. Например, получить 10 пользователей и для каждого — список их заказов ⇒ 1 запрос к users + 10 запросов к orders. 🚩

# SQLAlchemy-пример “N+1”:
users = session.query(User).all()              # 1 запрос
for u in users:
    print(u.orders)                            # для каждого пользователя — отдельный запрос

Почему плохо?

🔹 Высокая нагрузка на базу: запросы “в тоненькую” вместо одного “тяжелого”.
🔹 Задержки сети: множество раунд-трипов увеличивает время ответа.
🔹 Масштабируемость страдает: при росте N время растёт линейно.

Как победить N+1

1. Eager loading (предварительная загрузка)
Загрузка связей сразу вместе с основными объектами.

   # SQLAlchemy, joinedload — делает JOIN и подтягивает данные сразу
   from sqlalchemy.orm import joinedload

   users = session.query(User).options(joinedload(User.orders)).all()
   for u in users:
       print(u.orders)  # не генерирует дополнительных запросов
   

✅ Сокращает число запросов до 1.

2. Batch loading (групповые запросы)
Если JOIN приводит к дублированию полей, можно сделать два запроса:

   -- 1: получить user_id
   SELECT id FROM users WHERE active = true;
   -- 2: получить все заказы для этих пользователей
   SELECT * FROM orders WHERE user_id IN (...список id...);
   

✅ Баланс между сложностью и производительностью.

3. DataLoader / кеширование
В GraphQL и приложениях на Node.js часто используют DataLoader:

🔹 Собирает все ключи за тиковый цикл
🔹 Делает один общий запрос
🔹 Раздаёт результаты обратно

4. Правильное проектирование API
— Предусматривайте, какие связи нужны на фронтенде, и загружайте их сразу.
— Разделяйте endpoints: если нужны только пользователи без заказов — делайте лёгкий запрос.

Best practices & подводные камни

🔹 EXPLAIN ANALYZE для проверки плана: убедитесь, что JOIN-ы и IN (…) не приводят к полному сканированию таблиц.
🔹 Пагинация: всегда ограничивайте выборку через LIMIT/OFFSET или курсоры.
🔹 Будьте осторожны с joinedload на “много ко многим” — может раздувать размер результата.

Сохрани этот пост, чтобы не забыть, и поделись с коллегами!
А у тебя были случаи, когда N+1 съедал всю производительность? Как борешься?

#db

👉 @database_info

Мини-гайд по трём ключевым сущностям PostgreSQL: соединения, буфер и WAL

1. Соединения (Connections)
PostgreSQL по умолчанию позволяет одновременно до 100 соединений (max_connections).

🔹 Проблема: слишком много прямых соединений создают нагрузку на память и CPU.
🔹 Решение: используйте пуллинг через PgBouncer или Pgpool-II.

  [databases]
  mydb = host=127.0.0.1 port=5432 dbname=mydb

  [pgbouncer]
  listen_addr = 0.0.0.0
  listen_port = 6432
  pool_mode = transaction
  max_client_conn = 500
  default_pool_size = 20
  

🔹 Совет: на проде стремитесь держать max_connections < 200 и масштабируйте через пуллер.


2. Буфер (Shared Buffers & Work Mem)
PostgreSQL активно использует память для кэширования страниц и сортировок.

🔹 shared_buffers – основной буфер кэша:

  shared_buffers = 4GB        # ≈25% от RAM на выделенном сервере
  

🔹 work_mem – память на сортировку/слияние одного потока:

  work_mem = 64MB             # для сложных запросов с сортировками и хэш-джоинами
  maintenance_work_mem = 512MB # для VACUUM/CREATE INDEX
  

🔹 Best practice:

🔹 Установите shared_buffers ≈ 25% RAM.
🔹 Настройте work_mem исходя из числа параллельных операций, не превышайте общий объём памяти.



3. WAL (Write-Ahead Log)
WAL обеспечивает надёжность и репликацию.

🔹 wal_level – детальность логирования:

  wal_level = replica       # для потоковой репликации
  

🔹 checkpoint_timeout и max_wal_size:

  checkpoint_timeout = 10min
  max_wal_size = 1GB
  

🔹 Архивация WAL для резервных копий:

  archive_mode = on
  archive_command = 'cp %p /mnt/backup/wal/%f'
  

🔹 Рекомендации:

🔹 Увеличьте max_wal_size, если у вас большие всплески нагрузки.
🔹 Настройте сжатие WAL (pg_wal) для экономии места.



💡 Сохрани, чтобы не забыть!
А как вы оптимизируете соединения, буфер и WAL в своих проектах?

#db

👉 @database_info

🎯 Типы баз данных — кратко и по делу

Выбирая базу данных для проекта, важно понимать их ключевые особенности. Ниже — наглядная классификация:

🔷 Реляционные (Relational)
Классика: таблицы со строгими схемами и связями.
📌 ACID, SQL, целостность данных
📌 Идеальны для: финансов, e-commerce, CRM, ERP, банков и инвентаризации

🔷 Документные (Document)
Гибкие NoSQL-базы на основе JSON-документов
📌 Горизонтальное масштабирование, вложенные структуры
📌 Подходят для: CMS, каталогов, мобильных и веб-приложений

🔷 In-Memory
Хранят данные в оперативной памяти — максимум скорости
📌 Используются как кэш, для сессий, real-time аналитики
📌 Примеры: Redis, Memcached

🔷 Графовые (Graph)
Работают с узлами и связями — мощные запросы по связности
📌 Идеальны для соцсетей, рекомендаций, мошеннических схем
📌 Пример: Neo4j

🔷 Временные (Time-Series)
Оптимизированы под работу с временными метками
📌 Подходят для метрик, IoT, логов, финансовых данных
📌 Примеры: InfluxDB, TimescaleDB

🔷 Пространственные (Spatial)
Работают с геоданными и координатами
📌 Используются в GIS, логистике, экологии, городском планировании

🔷 Колончатые (Columnar)
Хранят данные по колонкам — супер для аналитики
📌 Быстрые агрегации, параллельная обработка
📌 Используются в BI, отчетах, хранилищах данных
📌 Пример: ClickHouse

🔷 Ключ-Значение (Key-Value)
Простые NoSQL-базы — пара ключ-значение
📌 Идеальны для кэшей, предпочтений, сессий
📌 Примеры: Redis, DynamoDB

🔍 Правильный выбор базы — залог производительности и масштабируемости проекта.

#db

👉 @database_info