Как zero-copy снапшоты экономят миллионы

Проблема: цена хранения состояния

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

• PostgreSQL — каждая строка ~100 байт, индексы × 2, WAL × 3, репликация × 2
• Redis — каждый объект ~50 байт оверхеда, копия на диск (RDB/AOF)
• Блокчейн — каждая транзакция копируется на все ноды (×1000)

Давайте посчитаем, сколько стоит хранить состояние 1 миллиона пользователей в классической архитектуре:

Стоимость сервера с 32 GB RAM + 100 GB SSD: ~$300-500/мес. А если пользователей 15 миллионов? Уже нужен кластер из 15 серверов — $5 000-7 000/мес.

Что такое zero-copy снапшот

Zero-copy снапшот — это снимок состояния пользователя, который не копирует данные. Вместо этого он:

1. Создаёт криптографический указатель на текущее состояние
2. Подписывает его BLAKE3-хэшем (32 байта)
3. Сохраняет только заголовок 128 байт + список изменений

Ключевая идея: если состояние не изменилось — снапшот не пересоздаётся. Он кэшируется и переиспользуется.

Анатомия снапшота в MEMORIA

Вот как выглядит реальный снапшот из кода MEMORIA:

type UserArena struct {
    // ...
    
    // Кэш последнего снапшота
    snapshotCache     [128]byte   // Сам снапшот
    snapshotCached    uint8       // Флаг: 1 = есть кэш
    snapshotBalance   int64       // Кэшированный баланс
    snapshotTxCount   uint32      // Кэшированное число tx
    
    // ...
}Go

Структура снапшота (128 байт):

Функция построения снапшота с кэшированием:

func (w *Worker) buildArenaSnapshot(arena *UserArena, balance int64) []byte {
    activeSlot := arena.getActiveSlotPtr()
    txOffset := activeSlot.TxOffset
    currentTxCount := atomic.LoadUint32(&arena.txCount)
    
    // 🔥 КЛЮЧЕВАЯ ОПТИМИЗАЦИЯ: если состояние не изменилось —
    // возвращаем кэшированный снапшот без пересчёта
    if arena.snapshotCached == 1 && 
       arena.snapshotBalance == balance &&
       arena.snapshotTxCount == currentTxCount {
        return arena.snapshotCache[:]  // ← 0 ns, 0 аллокаций
    }
    
    // Создаём новый снапшот (только если состояние изменилось)
    var snap [128]byte
    copy(snap[0:4], []byte("SNAP"))
    copy(snap[4:24], arena.peerID[:])
    binary.LittleEndian.PutUint64(snap[24:32], uint64(balance))
    copy(snap[32:64], arena.userKey[:])
    
    // Подпись BLAKE3
    h := blake3.New(32, snapshotKey[:])
    h.Write(msg)
    copy(snap[96:128], h.Sum(nil))
    
    // 🔥 Сохраняем в кэш для переиспользования
    copy(arena.snapshotCache[:], snap[:])
    arena.snapshotCached = 1
    arena.snapshotBalance = balance
    arena.snapshotTxCount = currentTxCount
    
    return arena.snapshotCache[:]
}Go

Обратите внимание на ключевую оптимизацию: если баланс и количество транзакций не изменились — снапшот не пересоздаётся. Мы просто возвращаем кэшированную версию. Это и есть zero-copy.

Экономия RAM: в 10 раз меньше

Сравним, сколько RAM нужно для хранения состояния 1 миллиона пользователей:

Экономия CPU: в 100 раз меньше

Самая большая экономия — на CPU. Вот что происходит при каждом обращении к снапшоту:

Разница: в 34 000 раз быстрее PostgreSQL и в 2400 раз быстрее Redis.

Почему такая огромная разница?

1. Нет MVCC-копирования — данные не копируются при каждом чтении
2. Нет сериализации — читаем сырые байты через unsafe.Pointer
3. Нет WAL — не пишем в лог перед изменением
4. Кэширование снапшотов — 90% запросов возвращают кэш за 0 ns
5. BLAKE3 вместо SHA-256 — в 6-8 раз быстрее

Экономия сети: в 1000 раз меньше

Когда клиент подключается к серверу, он получает свой снапшот. Сравним размер передаваемых данных:

Стоимость трафика в облаке (AWS, GCP): ~$0.09/GB.

На первый взгляд цифры маленькие. Но для 15 миллионов пользователей и реальных нагрузок (не 1 запрос/день, а 1000 запросов/день) разница становится существенной:

Экономия дисков: в 100 раз меньше

Дисковое хранение — ещё одна статья расходов. Сравним для 1 миллиона пользователей:

Стоимость SSD в облаке: ~$0.10/GB/мес.

Полный расчёт TCO

Давайте посчитаем полную стоимость владения (TCO) для трёх масштабов:

Сценарий 1: 1 миллион пользователей

Сценарий 2: 10 миллионов пользователей

Сценарий 3: 15 миллионов пользователей

Три реальных кейса

Кейс 1: Мобильная игра с 5M игроков

Сценарий: MMORPG с инвентарём, валютой, достижениями. Каждый игрок делает ~100 операций в день (подбор предметов, бои, торговля).

Экономия: $9 700/мес = $116 400/год

Бонус: задержка уменьшилась в 100 000 раз — игроки больше не видят лагов.

Кейс 2: Платёжная система с 10M пользователей

Сценарий: P2P-переводы, микроплатежи. Каждый пользователь делает ~20 транзакций в день.

Экономия: $99 500/мес = $1 194 000/год

Бонус: задержка уменьшилась в 12 000 000 раз — транзакции стали мгновенными.

Кейс 3: Социальная сеть с 15M пользователей

Сценарий: Лайки, подписки, репутация. Каждый пользователь делает ~500 операций в день.

Экономия: $23 800/мес = $285 600/год

Бонус: задержка уменьшилась в 100 000 раз — лента обновляется мгновенно.

Выводы

Zero-copy снапшоты — это не просто техническая оптимизация. Это архитектурный принцип, который меняет экономику высоконагруженных систем:

В следующей статье мы разберём юридический аспект: как архитектура MEMORIA с хранением снапшотов на стороне клиентов позволяет обходить законы о защите персональных данных (GDPR, CCPA) в большинстве стран.