База данных последовательностей событий сохраняет историю агентов

Для дата-инженера, создающего конвейеры извлечения данных или аналитики для агентов, практический вопрос заключается в том, где хранится история событий. Традиционные базы данных сводят события к плоским строкам и предварительно вычисленным агрегатам, отбрасывая последовательность и контекст, которые необходимы ИИ-агенту для понимания причин произошедшего, — в результате агенту приходится восстанавливать эту историю из хранилища или поискового индекса во время выполнения запроса.

Компания Keewano создала новый тип базы данных вместо того, чтобы добавлять прикладные функции к уже существующей. Расчет делается на то, чтобы сохранять полную последовательность событий нетронутой, а не позволять ей отбрасываться в момент записи. Во вторник компания объявила о выходе KeewanoDB в общий доступ (GA), а также о привлечении 12 миллионов долларов начального финансирования в раунде под руководством Hetz Ventures. СУБД работает как полностью управляемый сервис в Google Cloud, а развертывание в других облачных средах и собственными силами запланировано на начало 2027 года. Агент подключается к KeewanoDB напрямую и считывает последовательность там, где она уже находится. Разработчики настраивают это подключение с помощью SDK и протокола контекста модели (Model Context Protocol). Поверх базы данных располагается отдельный аналитический слой для команд, которым это необходимо, включая агента запросов на естественном языке и второго агента под названием Signal, который, по заявлению компании, выполняет обнаружение аномалий и причинно-следственный анализ примерно раз в час.

«Агенты и машины становятся крупными потребителями данных, и им требуются совсем не те вещи, что раньше», — рассказал VentureBeat Марк Кардашов (Mark Kardashov), соучредитель и генеральный директор Keewano.

Совершенно иной способ хранения событий — не таблица и не временной ряд

На протяжении десятилетий базы данных хранили события самыми разными способами, включая графовые, табличные и форматы временных рядов. Однако ни один из них не подошел Павлу Бибергалу, соучредителю и техническому директору Keewano, который ранее руководил инфраструктурой данных в кроссплатформенном игровом вендоре Plarium.

По словам Кардашова, команда Бибергала начала создавать решения с использованием агентов и больших языковых моделей примерно два года назад. Даже при наличии солидного бюджета и полной команды аналитиков они не могли получать ответы на простые вопросы в реальном времени. Стандартные хранилища данных могли показать, *что* произошло. Ответить на вопрос *почему* с приемлемыми для бизнеса затратами существующая инфраструктура была не способна. Кардашов отметил, что именно этот пробел подтолкнул Бибергала уйти из компании и в одиночку создать первый прототип KeewanoDB.

Это происхождение определяет то, как Кардашов позиционирует продукт сегодня. Он выступает против того, чтобы называть KeewanoDB графовой базой данных, документоориентированной или простой системой временных рядов, хотя и признает, что она разделяет концепции со всеми тремя. Отвечая напрямую на вопрос, чем она отличается от базы данных временных рядов вроде InfluxDB, он охарактеризовал ее как базу данных последовательностей событий. 

KeewanoDB не упорядочивает строки по времени в разных таблицах. Вместо этого она рассматривает каждую сущность (пользователя, устройство, агента) в качестве первичного ключа. Каждое событие, происходящее с этой сущностью, присоединяется к ней последовательно, образуя, по выражению Кардашова, одну большую таблицу на каждую сущность вместо системы, построенной на объединениях (joins) множества таблиц.

Как это работает

Архитектура состоит из трех основных компонентов.

Формат хранения. По данным компании, события хранятся на диске в виде четырехбайтовых блоков, упорядоченных по сущностям, а не разбитых по реляционным таблицам, причем в запросах не используются операции соединения (joins).

Семантический слой. Кардашов описал уровень, создаваемый во время приема данных с помощью больших языковых моделей, который добавляет к каждому событию дополнительный контекст по мере его поступления. Этот контекст меняется по мере изменения поведения сущности, и каждое изменение попадает в поток событий, а не заменяет то, что было раньше. Если пользователь переходит из статуса активного в неактивный, а затем в категорию помеченных как мошеннические, все три метки сохраняются в последовательности — агент видит текущий статус, не теряя предыдущие.

Путь выполнения запросов. По словам Кардашова, механизм ускорения позволяет агентам запускать скрипты напрямую внутри базы данных с помощью MCP. Это исключает шаг, который до сих пор требуется в большинстве архитектур агентов: выгрузку данных во внешний процесс перед их использованием.

Место на перенасыщенном рынке баз данных

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

В марте Oracle обновила собственную базу данных, объединив вокруг единого транзакционного движка векторные, JSON-, графовые, реляционные и пространственные данные. Компания аргументировала это тем, что синхронизация контекста агента между разрозненными системами рушится при продакшн-нагрузках. Компания Couchbase выступила с аналогичным заявлением в июне, позиционируя свои корни в сфере кэширования и транзакционных баз данных как более прочную основу для персистентной памяти агентов, чем инструменты, созданные для поиска или аналитики.

По мнению Филипа Руссома (Philip Russom), ведущего аналитика по данным и аналитике в IronSpark Analysis, главным отличительным фактором является то, что машинное обучение (МО) является для Keewano нативным.

«Как видите, большинство коммерчески доступных систем управления базами данных сегодня включают ту или иную функциональность для машинного обучения», — рассказал Руссом VentureBeat. 

Он отметил, что это справедливо как для более старых и устоявшихся вендоров баз данных, таких как Oracle и Microsoft, так и для новых — Snowflake и Databricks. По его мнению, функционал машинного обучения слишком часто искусственно «прикручивается» к реляционным СУБД, из-за чего структурированные данные приходится трансформировать, чтобы сделать их пригодными для МО-операций. Кроме того, он отметил, что адаптированная обработка МО обычно запускается вне СУБД, что приводит к перемещению данных, которое отнимает время и расходует ресурсы.

«Если честно, я пока не могу четко отнести KeewanoDB к какому-то одному классу», — признался Руссом. — Пока она выглядит как гибрид графовой, нейросетевой, колоночной/временной, InMemory- и реляционной СУБД реального времени. Это точно не JARD (просто еще одна реляционная база данных) и не YAPI (еще одна итерация Postgres)».

Что это значит для бизнеса

Получение данных, которые должным образом связаны для создания контекста агентного ИИ, представляет собой реальную проблему, задокументированную собственными исследованиями Pulse Research издания VentureBeat. В ходе июльского опроса 2026 года, охватившего 101 крупное предприятие (более 100 сотрудников), 68% респондентов заявили, что за последние шесть месяцев их ИИ-агенты выдавали уверенные, но ошибочные ответы, причиной которых стали пропущенные или противоречивые бизнес-контексты, а не ошибки самих моделей. Повторяющиеся случаи (37%) перевесили единичные (32%).

Что лучше подходит под конкретную рабочую нагрузку — подход на основе последовательности событий, временные ряды или адаптированная реляционная база данных — зависит от задач. Дата-инженерам стоит проверить один ключевой момент: как ваши агенты получают историю событий сегодня? Если она собирается заново из хранилища или поискового индекса во время запроса, либо считывается из предварительно вычисленных агрегатов, где была потеряна последовательность, — именно эту проблему и стремится решить Keewano.