Как я писал in-memory векторный движок на Go — и в каком месте он обогнал hnswilb

Значимый прорыв формирует отрасль ИИ: dubovoinikolai 7 минут назад Как я писал in-memory векторный движок на Go — и в каком месте он обогнал hnswilb Средний 15 мин 0 Go * Алгоритмы * Open source * Базы данных * Кейс Из песочницы Привет, Хабр! Меня зовут Николай, мне 32 года. По образованию я врач, анестезиолог-реаниматолог — но последние годы развиваюсь в инженерной сфере, и, честно говоря, она затянула меня сильнее.

Больше всего — всё низкоуровневое: как устроена память, что происходит под локами, почему индекс быстрый или медленный. Реанимация научила одной вещи, которая неожиданно пригодилась в инженерии: доверять только измеренным показателям, а не ощущениям. Проект, о котором пойдёт речь, задумывался как образовательный эксперимент — хотелось своими руками пощупать, как базы данных устроены изнутри: event loop, аллокаторы, WAL, графовые индексы.

Технические детали

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

Каждое решение и каждую цифру из этой статьи я понимаю и могу защитить, но написано это было в четыре руки, и мне кажется правильным сказать об этом прямо. Полгода назад я начал писать однонодовую in-memory базу с векторным поиском на Go. Без кластеров, без Raft, без «нам нужен Kubernetes-оператор».

Один процесс, RESP-протокол (работает обычный redis-cli), HNSW-индекс внутри, WAL на диске. В этой статье — путь от первой версии, которая выдавала 18 QPS, до движка, который на многопоточном поиске обходит hnswlib на 36–38%, а на высокоразмерных векторах с квантизацией — в 2. 5 раза при вчетверо меньшей памяти.

Отраслевые последствия

Со всеми цифрами, методологическими граблями и честными границами применимости. Код открыт: Репозиторий на Гитхабе. Зачем ещё одна векторная БДКороткий ответ: мне нужен был движок под RAG/семантический поиск, который живёт в одном процессе рядом с данными, а не отдельный кластер на три ноды с координатором.

Тезис, вокруг которого построен проект: подавляющее большинство реальных задач векторного поиска — это единицы миллионов векторов. Миллион векторов по 1536 float32 — это 6 ГБ. С int8-квантизацией — 1.

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

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.