Объектное хранилище для AI-нагрузок
Объектное хранилище для AI-нагрузок
Объектное хранилище хранит данные как самодостаточные объекты, а не как файлы в папках или блоки на диске. Оно создано для неструктурированных данных: фотографий, видео, аудио, электронной почты, веб-страниц, показаний датчиков и векторных эмбеддингов, которые производят AI-приложения.
Облачное объектное хранилище распределяет эти данные по множеству машин, но позволяет обращаться ко всем ним как к единому пулу через HTTP API. Каждый объект содержит три вещи: сами данные, любые добавленные вами метаданные и уникальный ID. Вы извлекаете или анализируете любой объект по этому ID, независимо от его типа файла.
Amazon S3, первое облачное объектное хранилище, теперь содержит более 500 триллионов объектов. Оно стало стандартным слоем хранения в облаке.
Как работает объектное хранилище
Три модели хранения обрабатывают данные по-разному. Файловая система помещает данные во вложенные папки. Блочное хранилище разбивает данные на блоки фиксированного размера на диске. Объектное хранилище сохраняет каждый элемент целиком в плоском контейнере, называемом bucket, без папок.
Чтобы сохранить файл, система берет данные, добавляет любые переданные вами метаданные и присваивает ID. Затем приложения читают, записывают и удаляют объекты по этому ID через HTTP API. Здесь нет пути к файлу и точки монтирования.
PUT /my-bucket/embedding-batch-042.parquet # сохранить объект
GET /my-bucket/embedding-batch-042.parquet # получить его по ID
DELETE /my-bucket/embedding-batch-042.parquet # удалить его
Именно плоская структура позволяет объектному хранилищу масштабироваться. Вы добавляете емкость, добавляя машины в пул, а не перестраивая дерево папок, поэтому один bucket может расти почти без ограничений. Amazon S3, запущенный в 2006 году, задал API, который скопировала остальная отрасль, и Ceph, MinIO и OpenStack Swift все совместимы с S3, как и другие крупные облака.
| Сервис | Провайдер | Стандарт API |
|---|---|---|
| Amazon S3 | AWS | S3 (фактический стандарт) |
| Cloud Storage | Google Cloud | Совместимый с S3 + нативный |
| Blob Storage | Microsoft Azure | Нативный + S3-совместимые шлюзы |
| MinIO / Ceph | Self-hosted (open source) | S3-совместимый |
Ключевые возможности и ограничения
Конструкция объектного хранилища дает ему четкий набор сильных сторон и четкий набор ограничений.
Ключевые возможности
- Масштабируется почти без ограничений. Один bucket хранит столько объектов, сколько вам нужно. Вы добавляете емкость, записывая больше данных, и платите только за то, что храните, без необходимости заранее рассчитывать размер кластера.
- Долговечное и отказоустойчивое. Объектные хранилища держат копии каждого объекта на нескольких машинах, часто в разных дата-центрах или регионах. Amazon S3 рассчитан на одиннадцать девяток (99.999999999%) долговечности, причем каждый объект хранится как минимум в трех Availability Zones.
- Дешевое, с уровнями хранения. Цена за гигабайт значительно ниже, чем у блочного или файлового хранилища, а холодные данные автоматически перемещаются на более дешевые уровни.
- Хранит любые данные, с богатыми метаданными. Один bucket может хранить любой тип неструктурированных данных, и каждый объект несет метаданные, которые вы определяете. Вы можете находить и фильтровать объекты по этим метаданным, независимо от типа файла.
- Открытое и легко доступное. Объекты читаются через простой HTTP API. S3 API является фактическим стандартом, поэтому многие инструменты читают одни и те же bucket без специальных коннекторов.
Ограничения
- Медленнее блочного хранилища. Каждый запрос проходит через HTTP, поэтому объектное хранилище плохо подходит для низколатентных задач со случайным доступом или транзакционных баз данных.
- Нет редактирования на месте. Вы заменяете весь объект, а не изменяете его часть, что делает объектное хранилище плохим выбором для данных, которые часто меняются.
- Малые чтения становятся дорогими. Нагрузка, которая выполняет много крошечных чтений, может привести к большим расходам на API, даже если сами данные невелики.
- Нет встроенного поиска или вычислений. Объектное хранилище хранит и отдает байты. В нем нет индекса, поиска, аналитики. Всё, что выходит за рамки "получить этот объект по ID", требует поверх него query engine. Именно этот последний пробел объясняет, почему объектное хранилище является основой для AI-данных, но само по себе не может обслуживать AI-поиск.
Варианты использования и мост к AI
Масштабируемость, надежность и низкая стоимость объектного хранилища делают его стандартным местом для многих рабочих нагрузок:
- Озера данных (стандартная основа хранения)
- Резервное копирование и аварийное восстановление
- Долгосрочные архивы
- Хранение и доставка медиа
- Журналы и данные аналитики
- Наборы данных для обучения ML (большие наборы данных, на которых учатся модели)
AI-поиск теперь требует от объектного хранилища большего, чем просто хранить данные. Эмбеддинги — это числовые векторы, лежащие в основе семантического поиска и retrieval-augmented generation (RAG). Их огромное количество, каждый из них большой, а хранение их в специализированной базе данных становится дорогим.
Поэтому команды начали хранить эмбеддинги напрямую в объектном хранилище. Amazon S3 Vectors, общедоступный с декабря 2025 года, добавляет в S3 нативное хранение векторов и поиск по ним. AWS заявляет, что это снижает стоимость хранения и запросов к векторам до 90% по сравнению со специализированными векторными базами данных, поддерживает до двух миллиардов векторов на индекс и отвечает на частые запросы примерно за 100 миллисекунд, а на редкие — менее чем за секунду.
Подвох — в скорости. Объектное хранилище теперь может дешево хранить векторы и искать по ним, но быстро ответить на поисковый запрос, при том что данные остаются в объектном хранилище и никогда не копируются в отдельное быстрое хранилище, — это сложная часть.
Объектное хранилище в AI-инфраструктуре
У объектного хранилища есть один реальный пробел для AI: у него нет способа искать по самому себе. Эмбеддинги дешево лежат в нем, но поиск по сходству оставляет вам два плохих варианта. Скопировать данные в выделенную векторную базу данных — и тогда вы храните две копии, платите по двум счетам и должны поддерживать их синхронизацию. Искать по сырым файлам без индекса — и это слишком медленно для production.
Решение — дать объектному хранилищу то единственное, чего ему не хватает: способ искать данные там, где они находятся. Для этого нужны три компонента, ни один из которых не поставляется встроенным:
- Индексы рядом с данными. Векторные индексы живут в объектном хранилище рядом с данными, а не в отдельной системе.
- Чтения, которые извлекают только нужное. Механизм запросов подтягивает только страницы индекса и фрагменты данных, которых касается запрос, а не целые файлы.
- Кэш перед хранилищем. Память или локальный SSD располагается перед объектным хранилищем, чтобы горячие данные отдавались без обращения туда и обратно.
Вместе это позволяет искать напрямую в объектном хранилище, а не относиться к нему как к пассивному хранилищу.
Zilliz Vector Lakebase — одна из систем, построенных таким образом. Она хранит данные и индексы в объектном хранилище, отдельно от вычислительных ресурсов, которые выполняют запросы к ним. Несколько вычислительных кластеров могут одновременно читать одну и ту же копию данных — для обслуживания, discovery или аналитики — без ее дублирования. Ее функция External Collections указывает на lake-таблицы, которые у вас уже есть, будь то в Lance, Iceberg, Parquet или ее собственном формате Vortex, и выполняет векторный поиск по ним на месте.
В бенчмарке Zilliz на Iceberg-таблице с одним миллиардом векторов скорость зависит от того, как кэшируются данные:
- Без индекса (brute-force сканирование Spark): часы
- Cold (индекс только что построен, примерно за 20 минут): ~30 секунд
- Warm (из кэша на локальном SSD): десятки миллисекунд
- Hot (из памяти): единицы миллисекунд
Поскольку каждый запрос загружает только нужные ему страницы, Zilliz сообщает, что снижает read amplification (избыточную передачу данных) более чем на 90%, а ее формат Vortex передает из S3 при каждом чтении в 135 раз меньше данных, чем Parquet.
Этот паттерн шире, чем какой-либо один продукт. Объектное хранилище превращается в место, где AI-данные ищутся напрямую, в дополнение к тому, что там они хранятся.
Часто задаваемые вопросы
Подходит ли объектное хранилище для AI-нагрузок?
Да, для хранения обучающих данных, эмбеддингов и артефактов моделей в масштабе, где окупаются его надежность, практически неограниченная емкость и низкая стоимость. Ограничение — скорость: чтобы быстро искать по этим данным, вам нужен индекс и вычисления поверх сырого хранилища.
В чем разница между объектным хранилищем и векторной базой данных?
Объектное хранилище — это универсальное хранилище для любых неструктурированных данных, доступных по ID. Векторная база данных создана для поиска по сходству среди эмбеддингов, с индексами, оптимизированными для быстрых запросов ближайших соседей. Эти два подхода сближаются: команды всё чаще хранят векторы в объектном хранилище и добавляют поверх них поисковый слой.
Можно ли выполнять векторный поиск непосредственно в объектном хранилище?
Всё чаще — да. AWS S3 Vectors добавляет нативный векторный поиск, а платформы, которые напрямую работают с lake tables на месте, позволяют искать данные в объектном хранилище без их копирования. Запросы выполняются медленнее, чем в индексе в памяти, но стоимость значительно ниже.
Почему data lakes используют объектное хранилище?
Data lake должен дешево и надежно хранить огромные объемы структурированных и неструктурированных данных в открытых форматах, доступных одновременно многим движкам. Плоский пул объектного хранилища с адресацией по ID подходит для этого лучше, чем файловое или блочное хранилище.
Объектное хранилище медленнее блочного хранилища?
Для одной операции — обычно да. Блочное хранилище обеспечивает очень низкую задержку для транзакционных задач и работы со случайным доступом. Объектное хранилище жертвует этим ради пропускной способности, надежности и стоимости при работе с крупными, в основном статичными объектами, читаемыми по HTTP. Разрыв сокращается при больших последовательных чтениях, но остается значительным для небольших операций, чувствительных к задержке.
Объектное хранилище для AI: следующие шаги
Объектное хранилище — это фундамент, на котором строится остальная часть стека данных для AI. Чтобы узнать, как vector-native платформа выполняет retrieval, discovery и analytics непосредственно по данным в объектном хранилище, прочитайте From Vector Database to Vector Lakebase или изучите платформу Zilliz Cloud.
- Как работает объектное хранилище
- Ключевые возможности и ограничения
- Варианты использования и мост к AI
- Объектное хранилище в AI-инфраструктуре
- Часто задаваемые вопросы
- Объектное хранилище для AI: следующие шаги
Контент
Начните бесплатно, масштабируйтесь легко
Попробуйте полностью управляемую векторную базу данных, созданную для ваших GenAI приложений.
Попробуйте Zilliz Cloud бесплатно