История вопроса
Переход от лексического поиска к семантическому извлечению коренным образом изменил требования к инфраструктуре данных за последнее десятилетие. Ранний информационный поиск полагался на инвертированные индексы и оценку TF-IDF, но современные мультимодальные AI системы требуют поиска вблизи в высокоразмерных векторных пространствах, которые часто превышают 1000 измерений. Этот сдвиг усилился с распространением моделей на основе трансформеров, генерирующих миллиарды плотных эмбеддингов, которые традиционные базы данных не могут эффективно просканировать методом грубой силы. Проблема изменилась от простой хранения к поддержанию графов приблизительных ближайших соседей по географически распределенным узлам, обеспечивая согласованность с транзакционными исходными системами.
Проблема
Векторные базы данных сталкиваются с уникальными ограничениями под теоремой CAP, так как точные вычисления k-ближайших соседей требуют глобального знания о датасете, что делает терпимость к разделению и низкую задержку взаимно исключительными на масштабе миллиардов векторов. Высокопроизмеренные эмбеддинги потребляют значительное количество памяти — часто 4 КБ на вектор при 1024 измерениях с использованием float32 — создавая проблемы притяжения данных, которые усложняют развертывание на краю. Кроме того, "проклятие размерности" делает неэффективными пространственные индексы на основе деревьев, что требует использования графовых алгоритмов, таких как HNSW, которые дорого обновлять постепенно. Поддержание согласованности между изменяемыми транзакционными данными в PostgreSQL и неизменяемыми векторными индексами вводит аномалии двойной записи, в то время как репликация индексов по регионам ухудшает затраты на полосу пропускания из-за размеров полезной нагрузки эмбеддингов.
Решение
Архитектура на основе ячеек, использующая иерархически навигационные маленькие миры графов с сжатием квантования продукта, позволяет выполнять запросы за меньше чем 10 мс, сокращая объем памяти на 90%. Региональные векторные ячейки поглощают эмбеддинги через потоки Apache Kafka с Debezium CDC коннекторами, обеспечивая изоляцию баз данных с истинным состоянием от накладных расходов по строительству индекса. Динамическое разбиение использует локально-чувствительное хеширование для маршрутизации запросов к определенным разделам, минимизируя пространство поиска с миллиардов до миллионов кандидатов. Модель с конечной согласованностью с версионированием векторов и "мягкими" метками удаления позволяет выполнять неблокирующие обновления индекса, в то время как консенсус Raft координирует изменения метаданных по ячейкам без централизации горячего пути запроса.
Описание проблемы
Глобальная платформа визуальной коммерции "LuxeSearch" управляет 400 миллионами SKU продуктов в категориях моды и мебели, требуя поиска визуальной схожести, где пользователи загружают фото для поиска идентичных или сопутствующих предметов. Устаревшая инфраструктура Elasticsearch не справилась с вычислительными нагрузками, связанными с расчетами косинусного сходства по 768-мерным эмбеддингам CLIP, вызывая задержки до 800 мс в пиковые часы. Более того, обновления метаданных продуктов происходят со скоростью 50 000 транзакций в секунду во время запросов, что вызывает порчу индекса, когда одновременные обновления конфликтуют с операциями поиска, в результате чего потери доходов превышали 2 миллиона долларов в час деградации.
Решение 1: Монолитный глобальный кластер
Первоначальное предложение развернуло единственный кластер Milvus в us-east-1 с глобальным кешированием на краевых ММР для наборов результатов запросов. Этот подход предложил сильные гарантии согласованности и упростил эксплуатационные накладные расходы за счет поддержания единого состояния индекса. Однако задержка между регионами для пользователей APAC превышала 180 мс, нарушая требования мобильного приложения менее 50 мс, и риск единой точки отказа стал неприемлемым в период праздничных покупок, когда затраты на простой резко возрастают.
Решение 2: Ночной пакет региональных индексов
Альтернативная архитектура предложила региональные индексы FAISS, восстанавливаемые через ночные пакетные задания из снимков S3. Это обеспечивало задержку запроса менее 5 мс благодаря локальному выводу на ЦПУ и устраняло сетевые задержки во время поиска. К сожалению, 24-часовая устарелость данных вызывала жалобы клиентов на "призрачные продукты", появляющиеся в результатах визуального поиска после распродажи товаров, а шестичасовые окна обслуживания, необходимые для восстановления индекса, нарушали SLA доступности 99,99%.
Выбранное решение
Команда реализовала автономные векторные ячейки, используя Redis с модулем RedisSearch для горячих индексов, содержащих 10% лучших продуктов по объему запросов, поддерживаемых маппированными HNSW графами, хранящимися в S3 для холодных данных. Debezium фиксирует изменения в PostgreSQL в Kafka, подавая региональным строителям индексов, которые реализуют инкрементальные обновления HNSW, используя паттерн обозначения.