История баз данных, согласно Databricks, представляет собой долгий безлунный интервал.
Где-то в 1980-х годах операционные и аналитические данные были разделены безжалостной физикой хранения. Rowstore пошел в одну сторону. Columnstore — в другую. На протяжении сорока лет цивилизация перевозила данные между ними в небольших караванах ETL, теряя актуальность, деньги и время от времени волю к жизни. Затем появились ИИ-агенты, разрушили старый порядок и заставили Databricks изобрести LTAP.
Это волнующий рассказ. С ним есть только одна небольшая проблема.
SingleStore существует.
Компания уже много лет выполняет транзакционные и аналитические нагрузки вместе, в промышленной эксплуатации, на одном распределенном движке SQL. В 2019 году мы публично описали нашу запатентованную архитектуру Universal Storage и уже ведущуюся работу по стиранию практических различий между rowstore и columnstore — не путем размещения двух специализированных движков поверх общего озера данных, а путем создания таблицы, способной справляться с обоими видами нагрузок.
Во-первых, о «физике»
Databricks начинает с обоснованного инженерного компромисса и где-то между предпосылкой и выводом возводит его в ранг судьбы. Строковое хранение (row-oriented) благоприятствует селективным транзакциям, в то время как колоночное (columnar) — широкому сканированию и агрегации. Эти шаблоны доступа требуют различных оптимизаций, но они не требуют раздельных систем.
Разработка Universal Storage в SingleStore была направлена непосредственно на преодоление этих компромиссов. Таблицы columnstore стали поддерживать поиск и высокую конкурентность благодаря хэш-индексам, доступу на уровне субсегментов и блокировкам на уровне строк. Вместо сканирования сегмента в миллион строк для извлечения одной записи SingleStore может определить положение строки и прочитать только необходимую часть. Вместо блокировки всего сегмента при обновлении система может блокировать данные на уровне строк. В бенчмарке, опубликованном вместе с оригинальным постом о Universal Storage, время поиска по несортированному столбцу в таблице, содержащей более миллиарда строк, сократилось с 271 миллисекунды до 2,54 миллисекунды.
Это было в 2019 году. С тех пор в Universal Storage добавились селективные соединения (joins) и операции upsert для таблиц columnstore, так что одна и та же таблица, которая обрабатывает крупные аналитические сканирования, также выполняет селективное чтение и мелкогранулярные обновления, традиционно закрепленные за rowstore.
Затем появились агенты
Databricks утверждает, что агенты окончательно разрушили старый порядок, поскольку им одновременно требуются живые операционные данные и исторический контекст. Например, агент по борьбе с мошенничеством не может принять полезное решение на основе копии транзакционных данных, которая отстает от реальности на минуты или часы. Ему нужна транзакция, происходящая прямо сейчас, и паттерны, скрытые в многолетней истории.
В этом вопросе мы согласны настолько полностью, что SingleStore изначально создавался вокруг этой идеи.
Агенты сделали эту потребность более очевидной, а объем запросов — более агрессивным, но они не изобрели требование анализировать текущие данные. Обнаружение мошенничества, трейдинг, логистика и клиентские приложения всегда зависели от актуальных данных. Любое приложение, которое должно было реагировать на изменения в мире до того, как мир снова изменится, нуждалось в этом.
Почти любая система может в конечном итоге проанализировать операционные данные после того, как они пройдут через достаточное количество конвейеров, реплик и преобразований форматов. Агенты же работают в интервале до того, как наступит это «в конечном итоге», когда последняя зафиксированная запись уже должна быть доступна для операционных запросов, аналитических запросов, векторного поиска и приложения, действующего на основе результата.
В SingleStore это именно так.
Агент может изучить только что поступившую транзакцию, сравнить ее с историческим поведением, выполнить поиск по связанным векторам, объединить структурированные и полуструктурированные данные и записать следующее действие обратно — и все это через один движок. Нет никакого интервала, в течение которого система должна ждать, пока настоящее превратится в историю, прежде чем она сможет его осмыслить.
Агенты не нарушили 40-летнее правило. Они сделали расплату за его соблюдение невозможной для игнорирования.
Хорошие гипотезы. А вот реальные цифры из эксплуатации.
Клиенты покупают интервал времени между событием и возможностью отреагировать на него, а затем тратят годы на устранение всего, что увеличивает этот интервал.
Databricks предлагает нам представить агентов, сопоставляющих текущие события с многолетней историей без перегрузки систем, обрабатывающих транзакции. Эти требования также описывают внедрения SingleStore, где гипотезы уже обрели целевые показатели задержки, требования к аудиту и семизначные счета за инфраструктуру.
Пример с мошенничеством имеет близкого родственника в реальной эксплуатации в ServiceNow (Armis), где объектом наблюдения является каждое устройство, перемещающееся по корпоративной сети. Ее платформа поглощает 100 миллиардов событий и 1,2 миллиарда сессий каждый день, загружая примерно один миллион сложных строк в секунду в клиентские среды объемом до 30 терабайт. SingleStore обеспечивает работу прогнозирования угроз на базе ИИ, обнаружения аномалий в реальном времени и поиска. Команда особо отметила наличие rowstore и columnstore в одной базе данных как причину своего выбора.
До SingleStore ее крупнейшая нагрузка была распределена по более чем 400 базам данных PostgreSQL и кластеру Elasticsearch из 160 узлов, за которыми следовали буферы Kafka, ресурсы EKS и процесс EMR, который периодически извлекал обновленные записи обратно из озера данных для переиндексации. Перенос крупнейшего набора данных в SingleStore сократил расходы на конвейер данных на 70%, позволив пользователям выполнять поиск, агрегировать и детализировать потоковые данные по мере их поступления.
Финансовая версия той же истории уже работает в одном из крупнейших банков мира. Его платформа управления частным капиталом рассчитывает доходность портфелей на основе данных за более чем 20 лет, выдавая результаты запросов за 10–20 миллисекунд более чем 40 000 одновременно работающих пользователей без конфликтов блокировок. Его платформа торговли акциями управляет еще 600 терабайтами данных в SingleStore, обрабатывает миллиарды рыночных событий каждый торговый день и поддерживает транзакции, аналитику и векторный поиск наряду с Kafka и HDFS. Клиенты могут проверять текущие позиции, анализировать историю портфеля за десятилетия и действовать, пока рынок все еще находится в движении.
Агенты увеличат трафик и сократят допустимую задержку, но они не вызвали из небытия принципиально новый класс нагрузок.
Но как быть с целым стадом агентов?
Databricks также права в том, что стадо агентов может парализовать операционную систему. Один послушный агент — это нагрузка; сотни — это стихийное бедствие.
Они прибывают лавинообразно, распределяются по инструментам, отправляют запросы, которые не мог предвидеть ни один планировщик мощностей, и потребляют ресурсы со спокойной уверенностью программного обеспечения, которое никогда лично не получало счетов за облачные услуги. Позвольте им всем столкнуться с рабочей нагрузкой в продакшене, и в конце концов кто-нибудь заново изобретет автоматический выключатель (circuit breaker).
Именно поэтому SingleStore разделяет хранение и вычисления, не разделяя транзакции и аналитику по разным движкам баз данных.
Благодаря технологии Zero-Copy data fabric и функции Smart Attach в SingleStore, база данных может иметь одно подключение для чтения-записи и множество подключений только для чтения в изолированных вычислительных кластерах. Каждый кластер обладает собственными вычислительными ресурсами, настройками, кэшем и конечной точкой. Аналитические приложения, рабочие нагрузки для вывода (inference) и группы агентов могут масштабироваться независимо, не создавая полную копию базовой базы данных.
Основной кластер может продолжать выполнять операции приема данных и транзакции. Выделенные кластеры могут брать на себя запросы агентов и аналитические рабочие нагрузки. Новые записи передаются в эти подключения «только для чтения» практически в режиме реального времени, в то время как общее объектное хранилище остается для них надежным источником данных. Если появится еще сотня агентов со сложными планами и отсутствием чувства меры, для новой рабочей нагрузки не потребуется создавать еще одну полную копию базы данных.
Управление данными имеет решающее значение. Это не машина времени.
Databricks также утверждает, что LTAP объединяет операционные и аналитические данные под общим каталогом и границей управления. Это хорошо. Корпоративные данные не должны терять свои политики и историю происхождения каждый раз, когда они проходят через конвейер.
Каталог может подсказать, где находятся данные, кто имеет право их видеть и как они туда попали. Однако каталог не может сделать транзакцию мгновенно доступной для любого типа запросов, превратить два движка выполнения в один или устранить задержку, скрытую внутри преобразования форматов, просто поместив всё под одну административную крышу.
SingleStore также признает, что не все корпоративные данные будут изначально находиться внутри одной базы данных. Архитектура кластеров третьего поколения и технология Zero-Copy data fabric поддерживают прямой доступ к открытым данным Apache Iceberg, позволяя приложениям работать с управляемыми данными lakehouse без предварительного создания еще одной проприетарной копии. Тот же движок HTAP может объединять эти открытые исторические данные с текущими операционными данными, векторным поиском, полнотекстовым поиском и состоянием приложения.
Открытое хранилище и унифицированное управление важны, но агентам нужно нечто большее, чем просто разрешение на просмотр данных. Им нужен движок, способный действовать на основе этих данных, пока они остаются актуальными.
Недостающая запись в хронологии
В 2019 году SingleStore представила Universal Storage как постоянное усилие по стиранию видимой разницы между строковыми и столбцовыми таблицами. Указанная цель была столь же ясна: один тип таблицы для транзакций и аналитики на наборах данных, значительно превышающих объем оперативной памяти.
Теперь агенты делают эту архитектуру еще более значимой. Умножая запросы и комбинируя шаблоны доступа, агенты превращают каждый стык в стеке данных — и каждый момент устаревшего контекста — в дополнительные задержки, сложность инфраструктуры и затраты токенов.
Добро пожаловать. Мы здесь уже некоторое время.
