Убьют ли Amazon S3 Vectors векторные базы данных — или спасут их?
Не так давно AWS представила кое-что новое: S3 Vectors. Это их первая попытка создать решение для векторного хранения, позволяющее хранить и запрашивать векторные эмбеддинги для семантического поиска прямо внутри Amazon S3.
На первый взгляд это выглядит как легковесная векторная база данных, работающая поверх недорогого объектного хранилища, — по цене, которая явно привлекательна по сравнению со многими специализированными решениями для векторных баз данных.
amazon s3 vectors.png
Естественно, это вызвало множество горячих мнений. Я видел, как люди в социальных сетях и инженерных кругах говорили, что это может стать концом специализированных векторных баз данных — включая Milvus, Pinecone, Qdrant и другие. Смелое заявление, правда?
Как инженерный архитектор Milvus и человек, который провел слишком много поздних ночей, размышляя о векторном поиске, я должен признать: S3 Vectors действительно привносит кое-что интересное, особенно в плане стоимости и интеграции внутри экосистемы AWS. Но вместо того чтобы “убить” векторные базы данных, я вижу, как она встраивается в экосистему в качестве дополняющего элемента. Более того, ее реальное будущее, вероятно, заключается в работе с профессиональными векторными базами данных, а не в их замене.
В этом посте я объясню, почему я так думаю, рассмотрев это с трех точек зрения: сама технология, что она может и чего не может, и что это значит для рынка.
Удивительный факт: векторное хранение может стоить дороже, чем вызовы LLM
Векторный поиск мощный, но у него есть серьезный подвох: он дорогой. Вычислительные требования часто на один-два порядка выше, чем в типичной базе данных NoSQL. Этот разрыв не просто теоретический — он проявляется в реальных счетах.
Недавно я общался с CTO популярного AI-приложения для заметок, который рассказал мне кое-что удивительное: они тратят на векторный поиск вдвое больше, чем на вызовы OpenAI API. Подумайте об этом секунду. Запуск слоя извлечения обходится им дороже, чем оплата самой LLM. Это переворачивает привычное предположение с ног на голову.
Бум ChatGPT в 2022 году только сделал это еще более очевидным. Внезапно эмбеддинги были повсюду, а векторные данные стали самым быстрорастущим типом данных в публичном облаке. Retrieval-Augmented Generation (RAG) стала движущей силой — и вместе с ней появились три вызова, которые изменили то, что должна была делать такая векторная база данных, как Milvus:
Массивный взрыв данных: Нагрузки почти за одну ночь выросли с десятков миллионов до десятков миллиардов векторов. Это не линейный рост — это квантовый скачок, и он сломал старые способы работы с данными.
Смещение терпимости к задержкам: Поскольку LLM в любом случае требуется время для генерации ответов, пользователи стали более терпимо относиться к немного более медленному извлечению. Мышление “sub-10ms recall at all costs” внезапно стало менее важным.
Чувствительность к стоимости резко выросла: Удвоение или утроение объема данных было не просто проблемой хранения; это превращалось в финансовый кризис, если пытаться масштабироваться с использованием традиционных вычислительно-тяжелых архитектур.
Короче говоря: векторные базы данных должны были быстро эволюционировать не потому, что технология не работала, а потому что экономика извлечения внезапно оказалась в центре внимания.
Эволюция векторного хранения: от памяти к диску, а теперь к объектному хранилищу
Давление, связанное со стоимостью и масштабом, привело к одному выводу: векторные базы данных не могли вечно оставаться только в памяти. Им пришлось эволюционировать — сначала к диску, а теперь к объектному хранилищу вроде S3. Это был не выбор; это была неизбежность для индустрии. И если вы следили за этой областью, вы, вероятно, заметили ту же тенденцию, что и я, за последние несколько лет.
Я видел, как векторные базы данных прошли через три distinct stages:
Фаза I (2018–2022): Эра чистой памяти: В ранние дни Milvus мы полагались на индексы в памяти, такие как HNSW и IVF. Производительность и полнота были фантастическими, но затраты — жестокими. Память не масштабируется дешево, и все, кто оплачивал эти облачные счета, это знали.
Фаза II (2022–2024): Революция дисковых индексов: Чтобы преодолеть ограничение памяти, мы первыми внедрили дисковый подход с использованием DiskANN вместе с нашим проприетарным индексом Cardinal (эксклюзивно для Zilliz Cloud, управляемого Milvus). Благодаря приемам вроде асинхронного ввода-вывода (AIO) и io_uring нам удалось выжать из дисков реальную производительность. Результат? Снижение затрат в 3–5 раз. Наши вычислительные единицы (CU), оптимизированные по емкости, быстро стали бестселлерами в Zilliz Cloud.
Фаза III (2024– ): Эра многоуровневого хранения: Следующий шаг был очевиден: перенести векторные индексы в дешевое объектное хранилище. Новые игроки, такие как TurboPuffer, полностью сделали ставку на S3, снизив стоимость хранения до ~$0.33/GB/month — сокращение в 10 раз. Но компромисс был столь же очевиден: задержка холодных запросов в диапазоне 500 мс–1 с и более слабая точность полноты.
В Zilliz мы уже некоторое время работаем над многоуровневым хранением, но откладывали выпуск, пока не смогли укротить производительность холодных запросов. В следующем месяце мы запустим наши обновленные CU расширенной емкости с настоящим разделением горячего и холодного в Zilliz Cloud. Это означает стабильную задержку холодных запросов менее 500 мс в сочетании со сверхвысоким QPS для горячих запросов. Иными словами, лучшее из обоих миров.
Amazon S3 Vectors появляется как раз вовремя
Поскольку многоуровневое хранение уже доказало свою эффективность, неудивительно, что AWS вышла на рынок с S3 Vectors. На самом деле этот релиз выглядит как естественное продолжение того, что уже происходило в отрасли. Amazon расширяла роль S3 с помощью таких функций, как S3 Tables, превращая его из «просто объектного хранилища» в мультимодальную основу холодного хранения. Векторы — это просто следующая модальность в этой эволюции, и, вероятно, на этом дело не остановится. Графы, данные ключ-значение и временные ряды могут пойти тем же путем.
И Amazon приносит на стол три неоспоримых преимущества:
Более низкая стоимость: одни из самых низких цен на хранение в отрасли.
Огромный масштаб: пулы машин AWS способны поглотить почти любую нагрузку запросов.
Микросервисно-нативная архитектура: идеально соответствует рабочему процессу векторного индексирования write–build–query.
В совокупности это дает S3 Vectors все предпосылки стать сверхдешевым, высокомасштабируемым решением холодного хранения для векторов.
S3 Vectors — настоящий убийца цен, но с четкими ограничениями
Как только был анонсирован S3 Vectors, наша команда подвергла его всесторонним тестам. Результаты оказались впечатляющими — не только с точки зрения того, насколько он дешев, но и в том, где начинают проявляться трещины.
S3 Vectors — настоящий убийца цен
Нельзя отрицать: S3 Vectors невероятно экономичен.
Хранение обходится всего в $0.06/GB, что примерно в 5 раз дешевле большинства serverless-векторных решений. Для типичной рабочей нагрузки — скажем, 400 миллионов векторов плюс 10 миллионов запросов в месяц — счет составляет около $1,217/месяц. Это более чем 10-кратное снижение по сравнению с традиционными векторными базами данных. Для нагрузок с низким QPS, допускающих задержки, это почти непревзойденно.
Но у производительности есть реальные ограничения
Ограничения размера коллекций: Каждая таблица S3 ограничена максимум 50 млн векторов, и вы можете создать только до 10 000 таблиц.
Холодные запросы: Задержка составляет ~500 мс для 1 млн векторов и ~700 мс для 10 млн векторов.
Горячие запросы: Задержка остается ниже 200 мс при 200 QPS, но выйти за этот потолок в 200 QPS сложно.
Производительность записи: Ограничена уровнем ниже 2 МБ/с. Это на порядки меньше, чем у Milvus (который обрабатывает ГБ/с), хотя, к чести S3, записи не ухудшают производительность запросов. Иными словами: он не предназначен для сценариев с большими, часто изменяющимися наборами данных.
Компромиссы в точности и функциональности
С точностью всё становится сложнее. Recall держится на уровне 85–90%, и у вас нет настроек, чтобы поднять его выше. Добавьте фильтры, и recall может упасть ниже 50%. В одном тесте, где мы удалили 50% данных, TopK-запросы запрашивали 20 результатов, но смогли вернуть только 15.
Функциональность также урезана. TopK-запросы ограничены максимум 30. Метаданные на запись имеют строгие ограничения по размеру. И вы не найдете таких функций, как гибридный поиск, мультитенантность или расширенная фильтрация — всё это является обязательным для многих production-приложений.
Разбор S3 Vectors: вероятная архитектура
После проведения тестов и сопоставления их со знакомыми шаблонами проектирования AWS мы сформировали довольно хорошую гипотезу о том, как S3 Vectors работает под капотом. Хотя Amazon не опубликовала полных деталей, характеристики производительности указывают на пять ключевых технологий:
Динамическое индексирование SPFresh: Вместо перестроения целых индексов после каждой записи S3 Vectors, похоже, обновляет только затронутые части. Такой дизайн сохраняет низкие затраты на запись и высокую доступность, но у него есть цена: после обновлений показатели recall снижаются на несколько процентных пунктов.
Глубокое квантование (4-bit PQ): Чтобы снизить накладные расходы ввода-вывода S3, embeddings, вероятно, сжимаются с помощью 4-битного product quantization.
Плюс: хранение обходится дешево, а запросы остаются быстрыми.
Минус: recall выходит на плато около ~85%, и у разработчиков нет настроек, чтобы поднять его выше.
Механизм пост-фильтрации: Судя по всему, фильтрация применяется после грубого поиска. Это сохраняет индекс единым и простым, но плохо справляется со сложными условиями. В наших тестах, когда мы удалили 50% данных, TopK-запросы, запрашивавшие 20 результатов, вернули только 15 — классический признак конвейера с пост-фильтрацией. Это также suggests, что Amazon сильно опиралась на существующие open-source дизайны индексов, а не строила кастомный с нуля.
Многоуровневое кэширование: Горячие запросы выполняются гораздо быстрее, вероятно, благодаря SSD/NVMe-кэшу перед S3. Но когда запрос не попадает в кэш, задержка значительно возрастает. Такой паттерн соответствует многоуровневой иерархии кэша, созданной для маскировки присущей объектному хранилищу медлительности.
Крупномасштабное распределенное планирование: У AWS нет недостатка в пулах машин. S3 Vectors, похоже, распределяет нагрузку между микросервисами, выстраивая конвейер потока read → decompress → search. Результат — то, что мы наблюдали в тестах: удивительно стабильное распределение задержки даже под высокой нагрузкой.
Где подходит S3 Vectors: правильный инструмент для конкретных задач
После всестороннего тестирования S3 Vectors стало ясно, что в некоторых сценариях он проявляет себя отлично, а в других не дотягивает. Как и большинство инфраструктурных инструментов, это не универсальное решение — это правильный инструмент для правильной задачи.
Где он хорошо работает
Архивирование холодных данных: Идеально подходит для хранения исторических наборов данных, к которым редко обращаются. Если вы можете мириться со временем запросов 500 мс+, экономия затрат непревзойденна.
RAG-запросы с низким QPS: Представьте небольшие внутренние инструменты или чатботы, которые выполняют всего десятки запросов в день, оставаясь ниже 100 QPS. Для таких случаев задержка не критична.
Недорогое прототипирование: Отлично подходит для proof-of-concept-проектов, где цель — проверить идею без больших затрат на инфраструктуру.
Где он испытывает трудности
Высокопроизводительный поиск и рекомендации: Если вашему приложению нужна задержка менее 50 мс, S3 Vectors просто не создан для этого.
Записи большого объема или частые обновления: Производительность быстро снижается, а точность recall заметно падает при интенсивных изменениях.
Сложные нагрузки запросов: Нет поддержки гибридного поиска, агрегаций или других расширенных функций запросов.
Мультитенантные production-приложения: При жестком ограничении в 10 000 buckets он не предназначен для крупномасштабных мультитенантных развертываний.
Другими словами, S3 Vectors отлично подходит для холодных, дешевых сценариев с низким QPS, но это не тот движок, который стоит использовать для системы рекомендаций, приложения поиска в реальном времени или любой высокомасштабной production-системы.
Будущее — за многоуровневым хранением векторов
S3 Vectors не означает конец векторных баз данных — он подтверждает то, что многие из нас наблюдают уже некоторое время: будущее — за многоуровневым хранением. Вместо того чтобы держать каждый вектор в дорогой памяти или на быстром диске, нагрузки будут естественным образом распределяться между горячими, теплыми и холодными уровнями в зависимости от того, как часто к ним обращаются и какую задержку может терпеть приложение.
Вот как это выглядит на практике:
Уровень горячих данных (<50 мс) – Здесь находятся поиск в реальном времени, рекомендации и таргетированная реклама. Задержка должна быть менее 50 мс, а значит, специализированные векторные базы данных по-прежнему являются лучшим вариантом. Они оптимизированы как для молниеносной скорости, так и для высокой пропускной способности запросов.
Уровень теплых данных (50–500 мс) – Сюда попадают многие приложения на основе RAG и мультитенантные общие сервисы. Этим нагрузкам не нужна сверхнизкая задержка, но им нужна предсказуемая производительность при более низкой стоимости. S3 Vectors и инстансы многоуровневого хранения Milvus занимают эту среднюю позицию.
Уровень холодных данных (>500 мс) – Исторические архивы и офлайн-анализ не требуют ответов в реальном времени, поэтому задержка в сотни миллисекунд приемлема. Здесь важна экономическая эффективность в огромном масштабе. Именно здесь хорошо проявляют себя решения вроде S3 + Spark/Daft или векторного озера данных Milvus.
Разделение на горячий–теплый–холодный уровни балансирует задержку, стоимость и масштаб так, как не может покрыть ни один отдельный уровень хранения сам по себе. Это паттерн, который мы уже видели в реляционных базах данных, хранилищах данных и даже CDN — и теперь векторное хранение идет по той же траектории. Эта трехуровневая архитектура также тесно соответствует дорожной карте, которую мы разрабатывали для Milvus и Zilliz Cloud.
1. Единая архитектура онлайн- и офлайн-обработки
AI-приложения не существуют аккуратно разделенными на отдельные «онлайн» и «офлайн» миры. На практике данные постоянно перемещаются между ними. Именно поэтому в будущей версии Milvus 3.0, мы представим векторное озеро данных, предназначенное для поддержки как извлечения в реальном времени, так и офлайн-обработки на одном и том же наборе данных.
На практике это означает, что один набор данных может обслуживать ваши live RAG и поисковые запросы, одновременно передаваясь в офлайн-анализ на базе Spark — например, для подготовки обучающих данных для LLMs. Без дублирования, без жонглирования двумя разными pipelines.
Мы также выпустим формат StorageV2 для векторного озера данных, который выводит экономику на новый уровень:
До 100 раз дешевле для хранения холодных данных.
До 100 раз быстрее, чем brute-force-запросы Spark по горячим данным.
В результате получается единая система, которая минимизирует избыточность, держит затраты под контролем и делает работу с векторными данными намного менее болезненной.
2. Создание функций, которые действительно нужны AI-разработчикам
За последние два года AI-приложения развивались очень быстро — и вместе с ними менялись требования к инфраструктуре, которая их поддерживает. В Zilliz мы развивали Milvus в соответствии с этими потребностями, выпуская такие возможности, как BM25 + гибридный векторный поиск, мультитенантная изоляция, многоуровневое хранилище hot–cold и дедупликация MinHash, а также длинный список улучшений, ориентированных на разработчиков.
Наша философия проста: когда вы сочетаете глубокое понимание бизнес-сценариев с новейшими технологиями, вы открываете совершенно новые возможности для инфраструктуры. Именно этот подход формирует Milvus 3.0, который принесет новую волну AI-native функций, разработанных непосредственно для реальных приложений. Среди них:
Взвешивание ключевых слов в поиске – Чтобы запрос вроде «красный телефон» мог правильно отдавать приоритет слову красный.
Поддержка геолокации – Храните и запрашивайте векторы с учетом местоположения для обработки промптов вроде «найти ближайшие кофейни».
Поддержка нескольких векторов для RAG – Прикрепляйте несколько эмбеддингов к каждому тексту, улучшая полноту и точность в сложных задачах поиска.
Гибкая обработка UDF – Пользовательские функции для более богатой, настраиваемой обработки данных.
Инструменты визуальной аналитики – Более глубокий офлайн-майнинг и исследование данных в масштабе.
И это только начало. Главное в том, что Milvus эволюционирует в систему, которая не только эффективна и масштабируема, но и AI-native в своей основе — специально создана для того, как на самом деле работают современные приложения.
3. Инженерия масштабирования без высокой цены
В Zilliz мы верим, что: 10-кратное снижение затрат открывает дверь к 100-кратно большему числу сценариев использования приложений. Этот принцип направлял каждый крупный этап развития Milvus. С 2022 года мы внедрили дисковые индексы, GPU-ускорение и квантизацию RabitQ — все это повысило производительность запросов на порядки, одновременно снижая затраты.
Заглядывая вперед, мы сосредоточены на том, чтобы извлечь из стека еще больше эффективности:
Более глубокая оптимизация аппаратного обеспечения – Настройка под чистую вычислительную мощность и производительность IOPS.
Более интеллектуальное сжатие и квантизация – Сделать векторы легче без потери точности.
Раннее завершение индексных запросов – Отсечение лишних вычислений, как только мы получаем результаты, в которых уверены.
Усовершенствованное многоуровневое индексирование – Лучшее использование кэша для более быстрого доступа к холодным данным.
Конечная цель не изменилась: создать инфраструктуру, которая просто работает из коробки, масштабируется по требованию и остается одновременно быстрой и доступной.
Почему появление S3 Vectors — хорошая новость для всех
Многие беспокоятся, что S3 Vectors сделает традиционные векторные базы данных устаревшими. Я считаю наоборот: его выпуск — хорошая новость для всей отрасли. На самом деле я вижу три больших преимущества.
Это подтверждает спрос. Никто больше не может утверждать, что векторы — это просто мимолётный тренд. Если AWS строит вокруг этого продукт, это однозначное доказательство того, что векторное хранилище — реальная необходимость, а не просто «индексы, завёрнутые в базу данных».
Это обучает рынок. Благодаря охвату AWS больше предприятий теперь знают о векторных базах данных, что расширяет границы того, какие приложения можно создавать.
Это стимулирует инновации. Конкуренция подталкивает всех нас — включая Milvus — сильнее оптимизировать, ещё больше снижать затраты и находить дифференцированные сильные стороны.
С точки зрения позиционирования S3 Vectors выглядит не столько как полноценная векторная база данных, сколько как холодный уровень векторного хранилища. Его низкая стоимость делает его особенно привлекательным для сценариев, которые раньше были экономически недоступны: небольшие команды, создающие RAG-приложения, индивидуальные разработчики, экспериментирующие с технологиями, или организации, индексирующие огромные наборы данных с потребностями лишь в базовом поиске. Это настоящий прорыв для экосистемы.
Лично я также хочу отметить инженерную команду AWS. Они последовательно улучшают свою платформу — от отладки Lambda до производительности холодного старта, — и S3 Vectors является ещё одним примером продуманной продуктовой инновации. Мне действительно интересно увидеть, что разработчики будут создавать теперь, когда экономика стала настолько благоприятной.
Так что нет, рынок векторных баз данных не подвергается разрушительному изменению — он созревает в многоуровневую экосистему, где разные решения обслуживают разные потребности в производительности и стоимости. Это хорошо для предприятий, хорошо для разработчиков и хорошо для всего стека AI-инфраструктуры.
Золотой век векторных баз данных не закончился — он только начинается.
Читать далее
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.
DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding
Explore DeepSeek-VL2, the open-source MoE vision-language model. Discover its architecture, efficient training pipeline, and top-tier performance.