IngoDB - адаптивная AI-native база данных

Анонс IngoDB от Хенрика Инго (Henrik Ingo) - самотрансформирующегося движка хранения документов на Rust, построенного на архитектуре lsm-tree. Основная идея: база данных отслеживает паттерны запросов и автоматически создаёт индексы, избавляя от необходимости вручную проектировать схему или настраивать СУБД с DBA. Проект позиционируется как "AI-native" - он и рассчитан на запросы от AI-агентов, и частично написан одним из них.

Архитектура

В основе IngoDB лежит движок LSM-tree. Записи идут стандартным путём: MemTable в памяти, сброс в неизменяемые SSTable на диске, фоновая компактизация для слияния и очистки. В качестве стратегии компактизации используется Cassandra Unified Compaction Strategy (UCS), управляемая единственным параметром W, который задаёт баланс между read amplification и write amplification. IngoDB адаптивно подстраивает W под текущую нагрузку.

Поверх фундамента LSM движок выделяют три вещи:

Запросы через Liquid AST. Никакого SQL. Запросы представляют собой структуры данных Rust - enum'ы и struct'ы, описывающие фильтры, проекции и обходы графа. Это сделано для того, чтобы AI-агенты и код приложений могли формировать запросы программно, избегая неоднозначностей парсинга SQL. Это интересная ставка: SQL появился потому, что людям нужен читаемый язык, но если основной автор запросов - LLM или агент, типизированный AST может оказаться более удобным интерфейсом.

Реактивное индексирование. Каждый запрос собирает статистику: по каким полям шла фильтрация, сколько документов было просканировано относительно возвращённого объёма, какова была задержка. Когда движок замечает повторяющийся паттерн с низкой селективностью (сканируется много документов, а возвращается мало), он создаёт вторичный SSTable, отсортированный по полю фильтра. Следующий запрос по тому же паттерну попадает в бинарный поиск вместо полного сканирования. Накладные расходы практически нулевые: данные всё равно сортировались бы во время компактизации, поэтому движок просто сортирует их по другому ключу. Дальнейшая компактизация поддерживает эти вторичные индексы в актуальном состоянии.

Ad-hoc обход графов. Любое поле во время выполнения запроса может стать ребром графа. Конструкция Traverse { from_field: "user_id", to_field: "_id", depth: 2 } обходит связи без предварительного объявления внешних ключей или специальных типов указателей. Это позволяет работать с документоориентированным хранилищем как с неявным графом.

Конкурентность

Изоляция снимков (snapshot isolation) через MVCC с использованием UUIDv7 в качестве идентификаторов версий. Читатели видят согласованное состояние на определённый момент времени, пока писатели продолжают работу параллельно. Упорядоченность UUIDv7 по времени означает, что версии сортируются хронологически без дополнительных метаданных.

Snapshot isolation - это конкретная точка в пространстве решений, где также находятся двухфазная блокировка, оптимистичное управление и варианты serializable snapshot; статья Грэфе (Graefe) on-transactional-concurrency-control объединяет их все в рамках одной модели и служит компактным ориентиром для понимания того, от чего отказывается движок хранения, выбирая тот или иной вариант.

Бенчмарки

На 1 миллионе документов с товарами:

Операция	Пропускная способность
Ingest (batch=1000)	210 - 235K docs/sec
Точечные выборки	56K ops/sec, p50=14µs
Первое сканирование (без индекса)	3.9s на 100K результатов
Второе сканирование (с реактивным индексом)	1.8s (в 2.2 раза быстрее)
Конкурентный доступ в 8 потоков	413K ops/sec
Смешанное чтение/запись	72K ops/sec

Write amplification измерен на уровне 0.72x благодаря адаптивной настройке W: движок записал на диск меньше сырого объёма данных за счёт эффективного дельта-сжатия и компактизации.

Написано за неделю

Вся кодовая база (~10K строк, 7 Rust-crate'ов, 170 тестов) была создана в формате парного программирования между Инго и Claude примерно за неделю. Инго принимал архитектурные решения и отлавливал огрехи проектирования; Claude генерировал рабочую реализацию. Это ещё один аргумент в дискуссии о "разработке с помощью ИИ" - полноценный движок хранения, а не игрушечный проект, созданный в ходе дисциплинированного сотрудничества человека и ИИ.

Планы развития

Принятие решений о создании/удалении индексов и настройке компактизации на базе нейросетей
Семантический shredding: извлечение часто запрашиваемых полей в колоночный формат во время компактизации
Co-location: совместное размещение связанных документов на основе наблюдаемых паттернов обхода
Пользовательские компараторы на WASM и сетевой доступ через gRPC

См. также

lsm-tree - базовая архитектура хранения
lsm-trees-nosql - вводное объяснение LSM-деревьев
building-syntaqlite-ai - ещё один проект базы данных, созданный с помощью ИИ, с другими выводами о процессе

https://github.com/nyrkio/ingodb