Key-value (Ключ-значение)

Введение: Самый простой и самый быстрый

Представьте себе шкаф с множеством ячеек. На каждой ячейке написан номер. Вы берете предмет, кладете в ячейку и запоминаете номер. Когда вам нужно найти предмет, вы идете прямо к этой ячейке. Не нужно перебирать все ячейки, не нужно искать по содержимому — вы знаете номер, и предмет находится мгновенно.

Это и есть модель “ключ-значение”. Самая простая и самая древняя структура данных в информатике. Словарь (dictionary), ассоциативный массив (associative array), хеш-таблица (hash table), карта (map) — все это разные названия одной и той же идеи.

Key-value база данных (хранилище “ключ-значение”) — это база данных, которая хранит данные как коллекцию пар “ключ-значение”. Ключ уникален и используется для доступа к значению. Значение — это произвольные данные (строка, число, JSON, бинарный объект), которые база данных не интерпретирует.

Это не просто “еще один тип NoSQL”. Это фундаментальная абстракция, на которой построены многие другие системы. Документо-ориентированные базы? Документ — это значение, а _id — это ключ. Колоночные базы? Первичный ключ — это ключ, а остальные колонки — значения. Кеширующие системы? Идеальный пример key-value.

Key-value хранилища — это максимальная простота и максимальная скорость. Никаких JOIN, никаких сложных запросов, никаких схем. Просто положить и получить.

Основные принципы

Ключ (Key)

Ключ — это уникальный идентификатор, по которому вы получаете доступ к данным. Ключ может быть:

Важные свойства ключей:

• Уникальность: два значения не могут иметь одинаковый ключ
• Простота сравнения: ключи должны быстро сравниваться
• Равномерное распределение: для шардирования

Значение (Value)

Значение — это любые данные, которые вы хотите сохранить. Key-value база данных не интерпретирует содержимое значения. Для нее это просто последовательность байтов.

Операции

Key-value хранилища поддерживают минимальный, но очень быстрый набор операций.

Примеры (Redis):

# Простейшие операции
SET user:123 "{\"name\":\"Иван\"}"
GET user:123
DEL user:123

# Работа со сроками жизни
SET session:abc123 "user_id=123" EX 3600   # Живет 1 час
EXPIRE temp:data 60                        # Умрет через 60 секунд
TTL session:abc123                         # Сколько осталось

# Атомарные операции со счетчиками
INCR page:home:views                       # Увеличить на 1
INCRBY page:home:views 100                 # Увеличить на 100
DECR inventory:123                         # Уменьшить на 1

Как это работает под капотом

Хеш-таблица (In-Memory)

Для in-memory key-value хранилищ (Redis, Memcached) используется хеш-таблица.

Хеш-таблица:

[0] → "user:123" → указатель на значение
[1] → NULL
[2] → "session:abc" → указатель на значение
[3] → "user:456" → указатель на значение
...

• Время доступа: O(1) в среднем
• Память: Данные хранятся в RAM
• Долговечность: Требуется персистентность (снапшоты, AOF)

LSM-Tree (On-Disk)

Для дисковых key-value хранилищ (RocksDB, LevelDB, Badger) используется LSM-Tree (Log-Structured Merge-Tree).

Запись → MemTable (в памяти) → SSTable на диске → Компакция

• Время доступа: O(log N) с амортизацией
• Память: Основные данные на диске, кеш в памяти
• Долговечность: Встроенная (WAL)

Распределенная хеш-таблица (DHT)

Для распределенных key-value хранилищ (DynamoDB, Cassandra в режиме KV, Riak) используется DHT.

    graph TD
    A[Ключ user:123] --> B[Хеш-функция]
    B --> C[Узел 1]
    B --> D[Узел 2]
    B --> E[Узел 3]
  

• Масштабирование: Горизонтальное
• Согласованность: Настраиваемая (eventual/strong)
• Доступность: Высокая (репликация)

Популярные key-value базы данных

Redis (Remote Dictionary Server)

Самая популярная key-value БД. Работает в памяти, но может сохранять данные на диск.

# Redis — не только строки, но и структуры данных
SET user:123 "Иван"
HSET user:456 name "Петр" age 25           # Хеш
LPUSH queue:jobs "task1" "task2"           # Список
SADD tags:news "sport" "politics"          # Множество
ZADD leaderboard 100 "Иван" 200 "Петр"     # Сортированное множество

# Публикация/подписка
PUBLISH channel:news "Breaking news"
SUBSCRIBE channel:news

Характеристики:

• In-memory (оперативная память)
• Поддерживает сложные структуры данных (хеши, списки, множества, битовые карты)
• Репликация, персистентность (RDB, AOF)
• Lua-скриптинг
• Pub/Sub, Streams

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

• Кеширование
• Сессии пользователей
• Очереди (через списки)
• Счетчики и метрики
• Лимитирование (rate limiting)
• Лидерборды (через sorted sets)

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

• Большие объемы данных (дорого хранить в RAM)
• Сложные запросы (нет индексов по значениям)
• Долговременное хранение (есть риск потери при сбое)

Memcached

Простой in-memory кеш, без персистентности и сложных структур.

# Memcached — только строки
set user:123 0 3600 15
Иван Петрович
STORED

get user:123
VALUE user:123 0 15
Иван Петрович
END

Характеристики:

• Только key-value (нет структур данных)
• Нет персистентности (только кеш)
• Максимальная производительность (проще Redis)
• Распределенный хешинг (consistent hashing)

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

• Простой кеш без сложных потребностей
• Когда Redis избыточен

RocksDB / LevelDB

Встраиваемые key-value библиотеки на диске (LSM-Tree).

// RocksDB (C++)
rocksdb::DB* db;
rocksdb::DB::Open(options, "/path/to/db", &db);
db->Put(rocksdb::WriteOptions(), "key", "value");
db->Get(rocksdb::ReadOptions(), "key", &value);

Характеристики:

• Встраиваемая (embedded) — работает внутри приложения
• Дисковое хранилище (LSM-Tree)
• Высокая производительность записи
• Сжатие данных

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

• База внутри приложения (не сервер)
• Высокая нагрузка на запись
• Ограниченная оперативная память

Amazon DynamoDB (режим Key-Value)

Управляемая облачная key-value БД.

// AWS SDK
await dynamodb.put({
    TableName: 'Users',
    Item: { userId: '123', name: 'Иван', age: 30 }
});

const result = await dynamodb.get({
    TableName: 'Users',
    Key: { userId: '123' }
});

Характеристики:

• Полностью управляемый сервис AWS
• Автоматическое масштабирование
• Настраиваемая согласованность
• Глобальные таблицы (мульти-регион)

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

• Проекты на AWS
• Нужно автоматическое масштабирование
• Нет желания администрировать Redis

Riak / Riak KV

Распределенная AP-система (по CAP-теореме).

Характеристики:

• Высокая доступность (AP)
• Репликация, автоматическое восстановление
• Ссылочные типы данных (CRDTs)

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

• Высокая доступность важнее согласованности
• Распределенная система без единой точки отказа

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

Паттерн 1: Кеширование (Cache-Aside)

Самый распространенный паттерн. Приложение сначала проверяет кеш, при промахе — идет в основную БД.

async function getUser(userId) {
    // 1. Проверяем кеш (Redis)
    let user = await redis.get(`user:${userId}`);
    if (user) {
        return JSON.parse(user);
    }
    
    // 2. Промах кеша — идем в PostgreSQL
    user = await db.users.findOne({ id: userId });
    
    // 3. Сохраняем в кеш на 5 минут
    await redis.set(`user:${userId}`, JSON.stringify(user), 'EX', 300);
    
    return user;
}

Варианты:

• Write-through: Запись сначала в кеш, потом в БД
• Write-behind: Запись в кеш, асинхронно в БД
• Cache-aside (lazy loading): Загрузка только при обращении

Паттерн 2: Счетчики и лимитирование

Атомарные операции инкремента идеальны для счетчиков.

// Счетчик просмотров страницы
async function recordPageView(pageId) {
    await redis.incr(`page:${pageId}:views`);
}

// Rate limiting (не более 100 запросов в минуту)
async function checkRateLimit(userId) {
    const key = `rate:${userId}:${Math.floor(Date.now() / 60000)}`;
    const count = await redis.incr(key);
    if (count === 1) {
        await redis.expire(key, 60);  // Живет 1 минуту
    }
    return count <= 100;
}

Паттерн 3: Сессии пользователей

Хранение сессий — классический use case для key-value.

// Сохранение сессии при логине
await redis.setex(
    `session:${sessionId}`,
    86400,  // 24 часа
    JSON.stringify({ userId: 123, role: 'admin', ip: '1.2.3.4' })
);

// Проверка сессии при каждом запросе
const session = await redis.get(`session:${sessionId}`);
if (!session) {
    return res.status(401).json({ error: 'Unauthorized' });
}

Паттерн 4: Очереди (Redis Lists)

// Producer
await redis.lpush('queue:emails', JSON.stringify({ to: 'user@example.com', subject: 'Hello' }));

// Consumer (блокирующий)
const task = await redis.brpop('queue:emails', 5);  // Ждет до 5 секунд
if (task) {
    processEmail(JSON.parse(task[1]));
}

Паттерн 5: Лидерборды (Redis Sorted Sets)

// Добавление очков
await redis.zincrby('leaderboard:game1', 100, 'user:123');
await redis.zincrby('leaderboard:game1', 50, 'user:456');

// Топ-10 игроков
const top10 = await redis.zrevrange('leaderboard:game1', 0, 9, 'WITHSCORES');

// Ранг игрока
const rank = await redis.zrevrank('leaderboard:game1', 'user:123');

Паттерн 6: Распределенные блокировки (Redis)

// Блокировка с таймаутом (чтобы не повисла)
const lockKey = `lock:resource:${resourceId}`;
const lockAcquired = await redis.set(lockKey, processId, 'NX', 'EX', 10);

if (lockAcquired) {
    try {
        // Критическая секция
        await doSomething();
    } finally {
        await redis.del(lockKey);
    }
} else {
    throw new Error('Resource locked');
}

Важно: Redis не гарантирует идеальные распределенные блокировки (есть проблема с часами и сетевыми задержками). Для критичных случаев используйте Redlock или ZooKeeper.

Паттерн 7: Геопространственные запросы (Redis)

# Добавление точек
GEOADD locations 37.617 55.752 "Moscow"
GEOADD locations -73.935 40.730 "New York"

# Поиск в радиусе 1000 км от Москвы
GEORADIUS locations 37.617 55.752 1000 km

# Расстояние между городами
GEODIST locations Moscow "New York" km

Плюсы и минусы key-value хранилищ

Плюсы

Минусы

Key-value в сравнении с другими типами NoSQL

Когда выбирать key-value

Идеальные сценарии

Сомнительные сценарии

Выбор key-value базы данных: Сравнение

Проектирование ключей

В key-value хранилищах проектирование ключей — это искусство. Поскольку нельзя искать по значению, всю логику запроса нужно закодировать в ключе.

Стратегии именования ключей

Использование префиксов:

user:123
user:456:profile
session:abc123
order:2024-01-01:123

Использование составных ключей (с разделителем):

"user:123:profile"
"user:123:settings"
"user:123:orders:2024-01"

Использование хешей для группировки (Redis):

HSET user:123 name "Иван" email "ivan@example.com" age 30
HGET user:123 name
HGETALL user:123

Шаблоны хороших ключей

Чего избегать в ключах

Распространенные ошибки

Ошибка 1: Использование Redis как единственной БД

Redis — это не замена PostgreSQL. Он не поддерживает сложные запросы, не гарантирует долговечность (в режиме по умолчанию), не умеет в JOIN.

Как исправить: Используйте Redis как кеш или для специфических задач, но основное хранилище — реляционная или документная БД.

Ошибка 2: Хранение больших значений в Redis

Redis загружает все данные в память. Хранение гигабайтных значений (видео, изображений) разорительно.

Как исправить: Для больших объектов используйте S3, MinIO, Blob Storage. В Redis храните только ссылки (URL, ключи).

Ошибка 3: Игнорирование TTL (времени жизни)

Данные в кеше накапливаются, память заканчивается, сервер падает.

Как исправить: Всегда устанавливайте TTL для кешируемых данных. Используйте политики вытеснения (LRU, LFU).

Ошибка 4: Использование KEYS в Redis (продакшн)

# Опасно! Блокирует сервер на время сканирования всех ключей
KEYS user:*

# Безопасно
SCAN 0 MATCH user:* COUNT 100

Ошибка 5: Наивные распределенные блокировки

// Плохо (нет таймаута)
await redis.set('lock:resource', processId);
// ... если процесс упадет, блокировка останется навсегда

Как исправить: Используйте SET NX EX или Redlock.

Резюме для системного аналитика

1. Key-value хранилища — самые простые и самые быстрые среди NoSQL. Доступ по ключу за O(1), никаких сложных запросов, никаких схем. Идеальны для кеширования, сессий, счетчиков, очередей.

2. Главное ограничение — только доступ по ключу. Нельзя искать по значению, нельзя делать JOIN, нельзя выполнять сложные агрегации. Если вам нужен поиск по полям — выбирайте документную или реляционную БД.

3. Redis — король key-value. In-memory, богатые структуры данных, Lua-скриптинг, репликация, персистентность. Memcached — проще, быстрее, но без структур данных и персистентности.

4. Встраиваемые KV (RocksDB, LevelDB) — для приложений, которым нужна локальная база. Высокая производительность записи, дисковое хранение, работает внутри вашего процесса.

5. Две основные модели персистентности: in-memory (Redis, Memcached) — максимальная скорость, но данные в RAM; on-disk (RocksDB) — больше места, но медленнее.

6. Проектирование ключей — ключевой навык. Хороший ключ должен быть коротким, информативным, равномерно распределенным. Используйте префиксы и разделители.