Хотелось пополнить резюме, а написала LSM-движок с MVCC, снапшотами и Value Log на чистом Go

• Вступление: хотела пополнить резюме, а написала базу данных
  
• Архитектура ScoriaDB: как я собирала конструктор
  
• Что пошло не так: реальные проблемы и их решения
  
• Что уже работает, а что ещё нет
  
• Что я вынесла из этого проекта
  
• Попробовать у себя
  
• Демонстрация CLI
  
• Документация
  
• Заключение

• Хеш‑таблица? нет, она не сохраняет порядок ключей, скан невозможен.
  
• sync.Map? Тоже нет, не упорядочена, под write‑heavy нагрузкой медленная.
  
• Skip list — Хм, это золотой стандарт LSM (LevelDB, RocksDB, BadgerDB), lock‑free или хотя бы с минимальными блокировками. Но корректная реализация конкурентного skiplist в Go — задача, которая может затянуться и отвлечь от реализации mvp.
  
• B‑tree — взяла github.com/google/btree. Стабильный, есть copy‑on‑write, быстро и просто использовать.

┌─────────────┐
│   Header    │  ← magic, версия, контрольная сумма заголовка
├─────────────┤
│ Block index │  ← массив «последний ключ блока → смещение»
├─────────────┤
│Bloom filter │
├─────────────┤
│  Block 1    │  ← данные + CRC32 блока
│  Block 2    │
│  ...        │
└─────────────┘

• Блочный индекс — массив, который для каждого блока SSTable хранит его последний ключ и смещение в файле. Позволяет быстро найти нужный блок бинарным поиском, не читая весь файл.
  
• Префиксное сжатие — способ экономить место в SSTable: если ключи имеют общий префикс (например, user:100, user:101), то общая часть хранится один раз, а различающиеся суффиксы — отдельно.
  
• Bloom‑фильтр — вероятностная структура, которая быстро говорит «ключа точно нет», отсекая лишние чтения с диска. Ложноположительные срабатывания возможны, но они лишь приводят к холостому поиску в блоке, не нарушая корректности.
  
• Контрольные суммы — каждый блок снабжён CRC32. При чтении блока я проверяю сумму, чтобы обнаружить битые данные на диске. Без этого можно было бы молча получить мусор, если файл повреждён.

• После syscall.Munmap (например, при закрытии БД) слайсы, которые ссылаются на этот регион, становятся висячими указателями, то есть любое обращение к ним вызывает SIGSEGV.
  
• Без контроля времени жизни таких слайсов легко получить аварию: горутина читает по старому слайсу, пока основной поток закрыл файл и сделал Munmap.

{
  "level": 1,
  "add": ["sstable_000123.sst"],
  "delete": ["sstable_000045.sst"]
}

type VFS interface {
    Open(name string) (File, error)
    Create(name string) (File, error)
    Rename(old, new string) error
    Remove(name string) error
}

// Было
func (g *TimestampGenerator) Next() uint64 {
    g.lastTS++
    return g.lastTS
}
// Стало
func (g *TimestampGenerator) Next() uint64 {
    return atomic.AddUint64(&g.lastTS, 1)
}

• При открытии проверяю магическое число. Если не совпадает — переименовываю файл в .corrupt, создаю новый, восстанавливаю данные из WAL.
  
• В методе Get перед возвратом значения сверяю CRC32 блока с записанным.

• MemTable: B‑tree с глобальным мьютексом → замена на lock‑free skip list (v0.3.0).
  
• WAL: Group Commit (v0.2.0).
  
• Manifest: бинарный формат (v0.2.0).
  
• Value Log GC: ручной режим есть (scoria gc), автоматический (битовая карта, инкрементальный) → v0.3.0.
  
• Ограничение размеров уровней в компакшене → v0.3.0.
  
• TTL для записей → v0.2.0.
  
• Raft, шардирование, распределённые транзакции, Sorted Sets, JSON‑документы → после v1.0 (без точных дат).

• Не нужно боятся переписывать. Три переписывания компакшена, два — WAL, один серьёзный рефакторинг MVCC. Мне становилось страшно, что останется какая‑то глубокая ошибка после этих изменений, ведь до этого я максимально старалась избежать того чтобы пришлось прям кардинально что‑то менять.
  
• Тесты с-race — с первого дня. Гонку в генераторе меток я нашла бы за день, а не за неделю, если бы включила -race раньше. В моём CI это стало обязательно, до недавних пор я об этом не думала.
  
• fsync — правда полезная штука. Запись замедлилась в 5 раз (всего лишь), но теперь после kill -9 данные сохраняются. Позже Group Commit амортизирует все затраты, сохраняя надежность.
  
• LSM — это намного сложнее, чем просто скинуть на диск. Bloom‑фильтр отсекает лишние чтения. Блочный индекс и CRC блоков — ещё пара мелочей, но без них данные либо теряются, либо ищутся вечность. Префиксное сжатие экономит память. Value log в помощь LSM. В сумме эти мелочи и делают базу данных быстрой и надёжной.
  
• Самое сложное — заставить всё работать вместе. MemTable работает, SSTable работает, WAL работает. Каждый по отдельности — отлично. Но когда они начинают взаимодействовать при компакшне и восстановлении, вылезают такие грабли, о которых ты и не догадывалась. Интеграционные и стресс‑тесты — вот где настоящая боль и настоящие открытия.

# Клонировать
git clone https://github.com/f4ga/ScoriaDB.git
cd ScoriaDB
# Быстрый старт через Docker
docker compose -f deployments/docker-compose.yml up --build
# Сервер на :50051 (gRPC) и :8080 (HTTP)
# Логин/пароль при первом запуске: admin/admin
# Или собрать вручную
go build -o scoria-server ./cmd/server
go build -o scoria-cli ./cmd/cli
./scoria-server &
TOKEN=$(./scoria-cli admin auth admin admin)
./scoria-cli --token "$TOKEN" set hello world
./scoria-cli --token "$TOKEN" get hello
# Запустить все тесты (обязательно с -race!)
go test -race ./...