MEMORIA vs PostgreSQL vs Redis

Зачем это сравнение

Когда мы говорим, что MEMORIA работает за 0.35 наносекунд, первая реакция — «не может быть». Ведь PostgreSQL делает простой SELECT за 100 микросекунд, а Redis — за 5 микросекунд. Это в 300 000 и 14 000 раз медленнее соответственно.

Давайте разберёмся, почему так происходит, и в каких сценариях каждая из этих технологий действительно нужна.

PostgreSQL: золотой стандарт

PostgreSQL — самая популярная реляционная СУБД с открытым исходным кодом. Она используется в банках, телекоме, e-commerce. Вот типичный путь запроса «получить баланс пользователя»:

Каждый слой добавляет задержку:

• TCP handshake — если соединение новое, +1-3 ms
• Web-фреймворк (Express, Django, Rails) — +50-200 μs
• ORM (Prisma, SQLAlchemy, ActiveRecord) — +100-500 μs
• SQL-парсер PostgreSQL — +50-100 μs
• Планировщик запросов — +20-50 μs
• Executor — +10-50 μs
• Disk I/O (если данные не в shared_buffers) — +1-10 ms
• Сериализация результата — +10-50 μs

Итого: от 100 μs до 10 ms на одну операцию чтения. Для системы, которая обрабатывает миллионы запросов в секунду, это неприемлемо.

Почему PostgreSQL такой медленный?

PostgreSQL жертвует скоростью ради надёжности:

• ACID-транзакции — каждая операция атомарна, изолирована, согласована и долговечна
• MVCC (Multi-Version Concurrency Control) — каждая транзакция видит свой снимок данных
• WAL (Write-Ahead Log) — все изменения сначала пишутся в лог, потом в таблицу
• B-tree индексы — O(log n) доступ к данным
• Дисковое хранение — данные могут не помещаться в RAM

Это отличные свойства для банковских транзакций, но избыточные для простого чтения баланса.

Redis: когда нужна скорость

Redis — это in-memory key-value хранилище. Все данные в RAM, никаких дисковых операций. Путь запроса короче:

Задержки:

• TCP round-trip (локально) — +1-5 μs
• Redis-протокол (RESP) — парсинг текстового протокола — +1-3 μs
• Хэш-таблица — O(1) доступ — +0.1-0.5 μs
• Сериализация ответа — +1-3 μs

Итого: 5-50 μs на операцию. Это в 10-100 раз быстрее PostgreSQL, но всё ещё в 14 000 раз медленнее MEMORIA.

Почему Redis медленнее MEMORIA?

Даже Redis, будучи in-memory хранилищем, имеет накладные расходы:

1. Сетевой стек — TCP/IP, даже на localhost, добавляет 1-5 μs на round-trip
2. Сериализация — Redis использует текстовый протокол RESP, который нужно парсить
3. Объектная модель — Redis хранит объекты (строки, хэши, списки), а не сырые байты
4. Однопоточность — Redis однопоточный (основной цикл), что ограничивает пропускную способность
5. Копирование данных — каждый ответ копируется из внутреннего буфера в сетевой

# Типичный сценарий Redis
SET user:123:balance 1000
GET user:123:balance
INCRBY user:123:balance -100

# Время: ~5 μs на каждую операцию
# Итого: ~15 μs на полный циклRedis

Redis Cluster: горизонтальное масштабирование

Когда данных становится больше, чем помещается в один Redis, используют Redis Cluster — распределённую версию с шардированием на 16 384 слота.

Но кластер добавляет новые задержки:

• Поиск слота — CRC16 от ключа → номер слота → узел — +1-2 μs
• Сетевой hop — если клиент попал не на тот узел, MOVED redirect — +100-500 μs
• Репликация — асинхронная репликация на реплики — фоновая, но создаёт нагрузку
• Gossip-протокол — узлы обмениваются состоянием каждые 1 секунду

Итого: 10-100 μs на операцию, плюс сложность эксплуатации кластера из 6+ узлов.

MEMORIA: другой подход

MEMORIA вообще не использует сетевой стек для внутренних операций. Вот путь запроса «получить баланс»:

Почему так быстро:

1. Нет сетевого стека для внутренних операций — всё в одной памяти
2. Нет сериализации — читаем сырые байты через unsafe.Pointer
3. Нет парсинга — бинарный протокол, фиксированные смещения
4. Нет блокировок — lock-free шардирование на 256 частей
5. Нет копирования — zero-copy доступ к памяти
6. Нет GC — предвыделенные arena-пулы

// Реальный код из MEMORIA
func (ua *UserArena) ReadBalance() int64 {
    active := atomic.LoadUint32(&ua.active)
    var base uintptr
    if active == 0 {
        base = uintptr(unsafe.Pointer(&ua.ping[0]))
    } else {
        base = uintptr(unsafe.Pointer(&ua.pong[0]))
    }
    slot := (*ArenaHotSlot)(unsafe.Pointer(base))
    return slot.Balance
}Go

Эта функция компилируется в 6 ассемблерных инструкций и выполняется за 0.35 наносекунды. Сравните с PostgreSQL, где только парсинг SQL-запроса занимает 50 μs.

Сводная таблица

Анатомия задержки

Давайте посмотрим, из чего складывается задержка в каждой системе. Представим операцию «прочитать баланс пользователя #12345»:

Обратите внимание: в MEMORIA нет сетевого стека для внутренних операций. Когда воркер обрабатывает UDP-пакет, он уже находится в том же процессе, в той же памяти. Нет TCP handshake, нет сериализации, нет копирования.

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

PostgreSQL — когда нужна надёжность

• Финансовые транзакции с ACID-гарантиями
• Сложные SQL-запросы с JOIN'ами
• Данные, которые должны пережить перезагрузку сервера
• Когда данные не помещаются в RAM
• Когда важна совместимость с экосистемой (ORM, миграции, бэкапы)

Redis — когда нужна скорость кэша

• Кэширование результатов запросов к БД
• Сессии пользователей
• Rate limiting
• Leaderboards и счётчики
• Pub/Sub для real-time уведомлений

Redis Cluster — когда данных много

• Больше данных, чем помещается в один Redis
• Высокая доступность (automatic failover)
• Горизонтальное масштабирование записи
• Географическое распределение

MEMORIA — когда нужна максимальная скорость

• Миллионы операций чтения/записи в секунду
• Состояние пользователей в RAM (балансы, инвентарь, профили)
• Real-time приложения (игры, платежи, телеметрия)
• Когда задержка измеряется наносекундами, а не микросекундами
• Когда стоимость инфраструктуры критична

Стоимость владения

Давайте посчитаем, сколько стоит обслужить 15 миллионов активных пользователей с 10 000 операций в секунду:

Разница в стоимости — в 30-50 раз. И это без учёта стоимости команды, которая обслуживает инфраструктуру.

Выводы

Каждая технология решает свою задачу:

• PostgreSQL — для надёжности и сложных запросов
• Redis — для быстрого кэширования
• Redis Cluster — для горизонтального масштабирования
• MEMORIA — для максимальной скорости обработки состояния

MEMORIA не пытается заменить PostgreSQL для сложных аналитических запросов или Redis для pub/sub. Она решает одну задачу — обработка состояния пользователей с минимальной задержкой — и делает это в 30 000 раз быстрее классического стека.

В следующей статье мы сравним MEMORIA с блокчейнами — Bitcoin, Ethereum, Solana — и покажем, почему классические блокчейны не подходят для real-time приложений.