Создание агентно-ориентированного хранилища данных на базе DuckDB — Ашиш Багри, GlassFlow

Первоначальная разработка GlassFlow для мониторинга агентов состояла из двенадцати компонентов: брокеров, внешней базы данных и всего остального. Они отказались от неё и перестроили систему на основе одного файла DuckDB для каждого проекта: одна таблица, девять столбцов, без индексов и один запрос на чтение. Ашиш Багри рассказывает о том, чего это им стоило и что принесло. В этом видео Ашиш Багри, соучредитель и технический директор GlassFlow, объясняет, почему продукт, созданный для потоковых рабочих нагрузок без агентов, был неправильной отправной точкой, как Tares хранит события каждого коннектора в одной таблице JSON-полезной нагрузки, почему триггер на самом деле является просто GROUP BY, и где DuckDB дал сбой — переполнение памяти при миллионе событий на небольшой виртуальной машине, давление на диск и проблемы с хранением данных. Запись сделана на встрече Agents in Prod в Амстердаме, организованной MotherDuck. 📓 Ресурсы GlassFlow: https://glassflow.dev MotherDuck: https://motherduck.com DuckDB: https://duckdb.org ➡️ Подписывайтесь на нас LinkedIn:   / motherduck   X: https://x.com/motherduck Разделы 0:00 Вступление 1:51 Что случилось с checkout-service? 3:36 Потребитель изменился 5:49 Что мы планировали построить 7:24 Конец мая: двенадцать компонентов и кто будет их запускать 8:57 Одна таблица, девять столбцов, каждый источник 10:19 Нет индексов в таблице событий 11:30 Один запрос на чтение 12:09 Триггер — это GROUP BY 13:03 Модель данных агента — это каталог 13:38 Стоимость: память, диск, хранение 15:33 Демонстрация: AI SRE с Tares 16:33 Что можно построить с Tares 17:26 Заключение 17:51 Полная демонстрация Tares #DuckDB #MotherDuck #AIAgents #DataEngineering #Observability