В чем разница между in-memory БД и традиционной?

Разница между in-memory БД и традиционной

Это фундаментальное различие в архитектуре баз данных. За 10+ лет работы я использовал обе: Redis, Memcached (in-memory) и PostgreSQL, MySQL (традиционные), и каждая имеет свои применения.

Основные различия

1. Место хранения данных

Традиционная БД (disk-based):

• Данные хранятся на диске (SSD, HDD)
• Индексы и кэш в оперативной памяти
• При запросе: БД ищет данные на диске, кэширует в RAM
• При перезагрузке сервера данные сохраняются

In-memory БД:

• Все данные хранятся в оперативной памяти (RAM)
• Диск используется только для durability (Log, Snapshot)
• При перезагрузке сервера данные теряются (если нет персистентности)

# Традиционная БД — запрос с диска
SELECT * FROM users WHERE id = 1;
# 1. БД ищет в индексе на диске → ~10-100 мс
# 2. Кэширует результат в RAM
# 3. Возвращает клиенту

# In-memory БД — запрос из RAM
redis.get("user:1")
# 1. Берёт значение из RAM → ~0.1-1 мс
# 2. Возвращает клиенту

2. Скорость доступа

import time
import redis
import psycopg2

# In-memory (Redis)
redis_client = redis.Redis(host='localhost', port=6379)
start = time.time()
for i in range(10000):
    redis_client.get(f"key:{i}")
print(f"Redis: {time.time() - start:.3f}s")  # ~0.05s (0.005ms per request)

# Традиционная БД (PostgreSQL)
conn = psycopg2.connect("dbname=testdb")
cur = conn.cursor()
start = time.time()
for i in range(10000):
    cur.execute("SELECT * FROM data WHERE id = %s", (i,))
cur.fetchall()
print(f"PostgreSQL: {time.time() - start:.3f}s")  # ~1-5s (0.1-0.5ms per request)

3. Объём данных

Традиционная БД:

• Может хранить петабайты данных
• Ограничена объёмом диска
• Масштабируется горизонтально (sharding)

In-memory БД:

• Ограничена объёмом RAM на сервере
• Обычно до 256 ГБ на одном сервере
• При больших данных — дорого и неэффективно

Когда использовать in-memory БД?

1. Кэширование часто запрашиваемых данных

from functools import lru_cache
import redis

class UserCache:
    def __init__(self):
        self.redis = redis.Redis()
    
    def get_user(self, user_id):
        # Проверяем кэш
        cached = self.redis.get(f"user:{user_id}")
        if cached:
            return json.loads(cached)
        
        # Не найдено — берём из БД
        user = db.query(User).filter(User.id == user_id).first()
        
        # Кэшируем с TTL 1 час
        self.redis.setex(
            f"user:{user_id}",
            3600,
            json.dumps(user.dict())
        )
        return user

2. Сессии пользователей

# В Django/Flask сессии хранят в Redis
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
    }
}

# Почему? Сессии часто читают/пишут, нужна скорость

3. Real-time analytics / counters

# Счётчики просмотров
redis.incr(f"views:video:{video_id}")  # Очень быстро

# Leaderboards
redis.zadd(
    "leaderboard",
    {user_id: score}
)
redis.zrevrange("leaderboard", 0, 10)  # Top 10 игроков

4. Pub/Sub (очереди сообщений)

# Redis как простой message broker
redis.publish("notifications", json.dumps({
    "user_id": 123,
    "message": "You got a like"
}))

# Consumer подписывается
pubsub = redis.pubsub()
pubsub.subscribe("notifications")
for message in pubsub.listen():
    handle_notification(message)

5. Distributed locks

import redis
from redis.lock import Lock

redis_client = redis.Redis()
lock = Lock(redis_client, "resource:123", timeout=30)

with lock:
    # Критическая секция — гарантирована только для одного потока
    process_exclusive_resource()

Когда использовать традиционную БД?

1. Больше данных, чем влезает в RAM

# В PostgreSQL могу хранить миллиарды записей
# В Redis — только то, что влезает в память

2. Транзакции и ACID гарантии

# PostgreSQL: гарантирует ACID
BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  # Либо обе операции прошли, либо ни одна

# Redis: нет полноценных транзакций (только WATCH/MULTI)

3. Сложные запросы с JOINами

-- PostgreSQL легко это делает
SELECT 
    o.id, 
    o.total,
    c.name,
    COUNT(oi.id) as items_count
FROM orders o
JOIN customers c ON o.customer_id = c.id
LEFT JOIN order_items oi ON o.id = oi.order_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
GROUP BY o.id, c.name
HAVING COUNT(oi.id) > 5;

-- Redis: невозможно, нужно вручную программировать

4. Постоянное хранилище

# PostgreSQL: persisted on disk
# После перезагрузки сервера — данные есть

# Redis: потеря данных при перезагрузке (без RDB/AOF)
# Нужна явная конфигурация для durability
appendonly yes
# Или периодические snapshots
SAVE 900 1  # Save if 1 change in 900s
SAVE 300 10
SAVE 60 10000

Гибридный подход (Cache-Aside Pattern)

class Repository:
    def __init__(self, db, cache):
        self.db = db
        self.cache = cache
    
    def get_user(self, user_id):
        cache_key = f"user:{user_id}"
        
        # 1. Пробуем кэш (быстро)
        user = self.cache.get(cache_key)
        if user:
            return User(**user)
        
        # 2. БД (медленно)
        user = self.db.query(User).get(user_id)
        if not user:
            raise NotFound()
        
        # 3. Кэшируем
        self.cache.setex(
            cache_key,
            3600,  # 1 hour TTL
            user.dict()
        )
        return user
    
    def update_user(self, user_id, data):
        # Обновляем БД
        user = self.db.query(User).get(user_id)
        user.update(data)
        self.db.commit()
        
        # Инвалидируем кэш
        self.cache.delete(f"user:{user_id}")
        
        return user

Сравнение в таблице

Оптимальная архитектура: PostgreSQL как основное хранилище + Redis как кэш и очередь задач. Это обеспечивает надёжность и производительность.