Написать свою in-memory базу данных — это своеобразный способ изучить Go под капотом и сделать значимый пет-проект. Создавать обычную обертку над map скучно. Поэтому я задался вопросом: а что если написать по настоящему быстрый движок с бинарным хранением, а сверху прикрутить интерактивного ИИ-ассистента, с которым можно общаться на естественном языке, заставляя его самостоятельно выполнять цепочки запросов?

Так на свет появился qrrot — in-memory хранилище на Go с TCP-интерфейсом, бинарными снапшотами и встроенным агентом на базе Gemini.

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

1. Под капотом: Типы данных и движок

В ядре qrrot лежит потокобезопасная структура Store, защищенная sync.RWMutex:

type Store struct {
	mu   sync.RWMutex
	data map[string]value.Value
}

В отличие от примитивных хранилищ типа string-string, движок строго типизирован и поддерживает три классических типа данных:

string — классические строки;
int — 64-битные целые числа;
json — JSON-объекты.

Все значения хранятся в памяти в структуре Value, которая содержит байтовый слайс и тег типа:

type Type uint8

const (
	TypeEmpty Type = iota
	TypeString
	TypeInt
	TypeJson
)

type Value struct {
	valueType Type
	data      []byte
}

Это позволяет легко сериализовать данные и избегать расходов на рефлексию при отдаче клиенту. Команды максимально привычные: put, get, del, exists, incr, decr, all.

2. Борьба за наносекунды: Парсер и сетевой слой

Когда вы пишете базу данных, самое «горячее» место — это разбор входящих команд. Обычный strings.Split здесь не подойдет: он аллоцирует память на каждый токен, что убьет производительность сборщика мусора при десятках тысяч запросов в секунду.

Zero-alloc (почти) парсер

Я написал парсер, который бежит по массиву байт, игнорируя лишние пробелы и табуляции. Особая магия начинается при обработке строк с пробелами (например, JSON-объектов). Парсер умеет понимать двойные кавычки " и экранированные символы \", аккуратно собирая токены в предвыделенный буфер [8][]byte.

Результаты бенчмарков (Apple M4, Darwin ARM64) говорят сами за себя:

Сырые операции в памяти:
- BenchmarkStore_Get - 6.29 ns/op, 0 B/op, 0 allocs/op
- BenchmarkStore_Put -13.30 ns/op, 0 B/op, 0 allocs/op
Парсинг команд:
- BenchmarkParser_ParseGet - 25.70 ns/op, 32 B/op, 1 allocs/op
- BenchmarkParser_ParsePut -51.19 ns/op, 32 B/op, 2 allocs/op

Аллокации в парсере сведены к минимуму (1-2 на команду) — они уходят лишь на приведение байтов к string при создании объекта команды.

TCP-сервер

Сетевое взаимодействие построено на базе стандартного пакета net. Каждое соединение обслуживается в своей горутине. Полный цикл (получение пакета -> парсинг -> блокировка мьютекса -> чтение/запись -> ответ клиенту) работает крайне быстро:

BenchmarkTCPServer_Get - 11 970 ns/op (~83 000 RPS)
BenchmarkTCPServer_Put - 12 157 ns/op (~82 000 RPS)

3. Киллер-фича: Интерактивный ИИ-ассистент

Для активации достаточно запустить базу с флагом -ai и передать API_KEY. В REPL становится доступна команда ai.

Поддерживается выполнение нескольких шагов

Простая генерация одной команды не работает для сложных задач. Например, по запросу “если юзер ivan существует, инкрементируй его возраст” ИИ не может сразу выдать команду записи, так как не знает состояние базы.

Для этого под капотом реализован цикл (до 5 итераций), где ИИ общается с движком БД специальными тегами:

QUERY READ: <command> — ИИ просит базу выполнить чтение (например, get ivan).
QUERY WRITE: <command> — промежуточная запись данных.
RESULT READ: / RESULT WRITE: — финальный результат.

Как это выглядит на практике:

Вы пишете: ai удали профиль ivan, если у него возраст меньше 30
LLM отвечает движку: QUERY READ: all
Движок прозрачно для вас выполняет all, ищет среди данных Ивана, видит у него возраст {"age": 25} [json] и отправляет обратно LLM.
LLM понимает, что юзер найден по ключу (допустим, ivan), и выдает финальное действие: RESULT WRITE: del ivan.

Human-in-the-loop (Защита от восстания машин)

База данных никогда не выполняет деструктивные команды ИИ вслепую. Если LLM генерирует write-команды (put, del, incr, decr), qrrot останавливает выполнение, рисует красивую ASCII-рамку с планом выполнения и ждет подтверждения:

ai wants to execute the following write command(s):
┌─────────────────────────────────┐
     1. del ivan                                                                       
└─────────────────────────────────┘
execute final commands? (y/n):

Это гарантирует, что галлюцинации нейросети не уничтожат ваш прод.

4. Данные на диске: Бинарные снапшоты

In-memory — это круто, но данные нужно сохранять. Вместо использования тяжеловесных форматов (JSON/XML), qrrot сохраняет дамп в собственный бинарный формат с сигнатурой QRRT.

Структура файла максимально плотная:

4 байта сигнатура (QRRT) + 1 байт версии.
Далее подряд идут записи: [1 байт тип] [2 байта длина ключа] [ключ] [4 байта длина значения] [значение].

Атомарность сохранения: При вызове exit или перехвате системных сигналов (SIGINT/SIGTERM) срабатывает механизм Graceful Shutdown:

Дамп пишется во временный файл dump.qrr-*.tmp.
Вызывается f.Sync() для принудительного сброса буферов ОС на физический диск (защита от отключения питания).
Выполняется os.Rename(), который в POSIX-системах гарантированно атомарно подменяет старый файл новым.

Бенчмарки I/O (10 миллионов ключей с длинными значениями и JSON):

Сохранение на диск: 2.41 секунды.
Чтение, парсинг и загрузка 10М ключей в RAM: 3.14 секунды. Дополнительно реализована защита от OOM при чтении битых файлов: если в дампе указана длина значения больше 16 МБ, база откажется загружать этот ключ, предотвращая краш системы.

5. О проблемах и архитектурных недочетах

Идеального кода не существует, особенно, если проект написан за две недели одним человеком. qrrot создавался как пет-проект, и он уж точно не способен хотя бы как то конкурировать с каким нибудь Redis. В нем заложены компромиссы, которые при росте нагрузки могут выстрелить в ногу. Давайте их разберем:

1. Глобальная блокировка

Ядро базы — это Store под единым sync.RWMutex. Для 80k RPS на localhost этого хватает, но на машинах с десятками ядер потоки начнут выстраиваться в очередь. Как чинить: Переписать на шардирование. Разбить хранилище на массив из 256 сегментов (каждый со своей мапой и своим мьютексом). Сегмент выбирается по хэшу от ключа. Это радикально снизит конкуренцию блокировок.

2. OOM при снятии снапшотов

В текущей реализации метод Snapshot сначала вызывает loadDataToRam(), который делает maps.Copy(res, s.data). Это катастрофа для больших баз. Если у вас в памяти лежит 10 ГБ данных, в момент создания снапшота база выделит еще 10 ГБ оперативки просто для создания безопасной копии мапы. Как чинить: Либо блокировать мапу на время записи на диск (убьет доступность БД), либо реализовывать MVCC (Multi-Version Concurrency Control) или механизм наподобие RCU (Read-Copy-Update).

3. Отсутствие WAL (Write-Ahead Log)

Снапшоты сохраняются только при выходе. Если сервер проработает месяц, накопит данные, и процесс убьет SIGKILL (или пропадет питание) — все данные с момента старта исчезнут. Как чинить: Писать append-only лог каждой транзакции на диск в реальном времени. При старте база должна загружать последний дамп, а затем “накатывать” операции из WAL.

4. ИИ-ассистент работает только локально (в REPL)

Архитектура ИИ-агента с интерактивным запросом y/n завязана на os.Stdin и os.Stdout. Если вы запустите БД в режиме TCP-сервера и пошлете по сети команду ai, движок честно ответит: ai is only available in interactive console (i'll fix it). Для работы по сети потребуется реализовать интерактивный протокол поверх TCP.

5. Оверхед по памяти для простых чисел

Значения типа int (int64) занимают 8 байт, но qrrot упаковывает их в структуру Value с тегом типа и байтовым слайсом []byte. Это порождает лишние аллокации и оверхед в памяти. Для мелких данных это неэффективно по сравнению с interface{} или unsafe-трюками.

Итог

qrrot — это отличный полигон для экспериментов. Проект доказывает, что на чистом Go, используя лишь стандартную библиотеку (за исключением ИИ-клиента), можно за короткое время собрать производительный движок, выдерживающий огромный RPS.

Опыт с LLM в качестве самостоятельного агента мне оказался особенно интересным: модель отлично справляется с многошаговыми задачами и парсингом JSON внутри базы, выступая мостом между человеческим языком и строгой логикой БД.

Вы можете потыкать демо онлайн через TCP (увы, пока для TCP AI я не прикрутил):

nc qrrot.xyz 23

Буду рад вашей критике, архитектурным советам и пулл-реквестам: GitHub

Спасибо!

qrrot — база данных со встроенным ИИ