Тип 2: Хранилища типа "ключ-значение" (Key-Value Stores)

Модель данных: Простейшая модель — ассоциативный массив (словарь, хеш-таблица). По ключу можно получить значение. Значение — это просто набор байт, структура которого базе данных неизвестна.

Структура:

Особенности:

• Максимально простая модель.

• Чтение и запись по ключу выполняются за O(1) или близко к этому.

• Нет возможности поиска по значению (только по ключу).

• Часто хранят данные в оперативной памяти для скорости.

Популярные представители:

• Redis — хранит данные в RAM, поддерживает сложные структуры (списки, множества, хеши), может сохранять на диск. Используется для кэширования, сессий, очередей, счётчиков.

• Memcached — только кэш, только в памяти, очень быстрый, простой.

• Amazon DynamoDB — управляемая NoSQL от Amazon, ключ-значение и документная.

• Riak — распределённое хранилище с упором на доступность.

• Etcd, Zookeeper — используются для хранения конфигурации и координации в распределённых системах.

Когда использовать:

• Кэширование данных (чтобы не ходить в основную БД).

• Хранение пользовательских сессий.

• Счётчики (просмотры, лайки).

• Очереди задач.

• Хранение конфигурации.

• Любые сценарии, где нужен очень быстрый доступ по ключу.

Когда НЕ использовать:

• Когда нужен поиск по содержимому (не по ключу).

• Когда данные имеют сложную структуру и требуют запросов по разным полям.

• Когда нужны связи между разными сущностями (придётся моделировать на стороне приложения).

Тип 3: Колоночные базы данных (Column-Family Stores / Wide-Column Stores)

Модель данных: Данные хранятся по колонкам, а не по строкам. Это не то же самое, что колоночное хранение в аналитических СУБД (хотя идея похожа).

Структура (на примере Cassandra):

• Keyspace — аналог базы данных.

• Column Family — аналог таблицы.

• Row — идентифицируется ключом.

• Column — состоит из имени, значения и временной метки.

• Важно: разные строки могут иметь разный набор колонок.

Представление:

Строки хранятся так:

Ключ строки → {колонка1: значение1, колонка2: значение2, ...}

Но физически данные группируются по колонкам, что даёт преимущества при аналитических запросах.

Как это выглядит логически:

Row Key	Колонка: имя	Колонка: возраст	Колонка: город
user1	Иван	30	Москва
user2	Мария	25
user3	Петр		СПб

Физически же все значения колонки "имя" хранятся рядом, что позволяет быстро агрегировать.

Популярные представители:

• Apache Cassandra — распределённая, высокая доступность, нет единой точки отказа, отличная запись.

• HBase — поверх Hadoop/HDFS, для очень больших данных.

• Google Bigtable — оригинальная колоночная БД от Google.

• ScyllaDB — совместима с Cassandra, но написана на C++ для большей производительности.

Когда использовать:

• Запись огромных объёмов данных (логи, события, метрики).

• Временные ряды (данные от датчиков, мониторинг).

• Системы рекомендаций.

• Хранение данных с большим количеством атрибутов, но где каждый объект имеет свой набор.

• Аналитика в реальном времени.

Когда НЕ использовать:

• Когда нужны сложные JOIN'ы или транзакции (Cassandra их не поддерживает).

• Когда данные нужно часто обновлять (в Cassandra обновления — это фактически новые записи).