Home
Blog
Представляем AISAQ в Milvus: векторный поиск миллиардного масштаба стал на 3,200× дешевле по памяти

Представляем AISAQ в Milvus: векторный поиск миллиардного масштаба стал на 3,200× дешевле по памяти

Engineering

December 10, 2025

Martin Li

Векторные базы данных стали основной инфраструктурой для критически важных систем искусственного интеллекта, и объемы данных в них растут по экспоненте, часто достигая миллиардов векторов. При таких масштабах все становится сложнее: поддерживать низкую задержку, сохранять точность, обеспечивать надежность, работать с репликами и регионами. Но одна проблема, как правило, всплывает на поверхность раньше и определяет архитектурные решения - стоимость.

Чтобы обеспечить быстрый поиск, большинство векторных баз данных хранят ключевые структуры индексирования в DRAM (Dynamic Random Access Memory), самом быстром и самом дорогом ярусе памяти. Такая конструкция эффективна с точки зрения производительности, но плохо масштабируется. Использование DRAM зависит от объема данных, а не от трафика запросов, и даже при сжатии или частичной разгрузке SSD большая часть индекса должна оставаться в памяти. По мере роста массивов данных затраты на память быстро становятся ограничивающим фактором.

Milvus уже поддерживает DISKANN, дисковый ANN-подход, который снижает нагрузку на память за счет переноса большей части индекса на SSD. Однако DISKANN все еще полагается на DRAM для сжатых представлений, используемых во время поиска. В Milvus 2.6 эта идея получила дальнейшее развитие благодаря AISAQ, векторному индексу на основе диска, вдохновленному DISKANN. Архитектура AiSAQ, разработанная компанией KIOXIA, построена по принципу "Zero-DRAM-Footprint Architecture", которая хранит все важные для поиска данные на диске и оптимизирует размещение данных для минимизации операций ввода-вывода. При нагрузке в миллиард векторов это позволяет сократить использование памяти с 32 ГБ до 10 МБ - уменьшение на 3 200 раз присохранении практической производительности.

В следующих разделах мы объясним, как работает векторный поиск на основе графов, откуда берутся затраты на память и как AISAQ меняет кривую затрат при векторном поиске в миллиардных масштабах.

Принцип работы обычного векторного поиска на основе графов

Векторный поиск - это процесс нахождения точек данных, числовые представления которых наиболее близки к запросу в высокоразмерном пространстве. "Ближайшие" означает наименьшее расстояние в соответствии с функцией расстояния, такой как косинусоидальное расстояние или расстояние L2. На малых масштабах это просто: вычислите расстояние между запросом и каждым вектором, а затем верните ближайшие. Однако при больших масштабах, скажем, миллиардных, такой подход быстро становится слишком медленным, чтобы быть практичным.

Чтобы избежать исчерпывающих сравнений, современные системы приближенного поиска ближайших соседей (ANNS) опираются на индексы на основе графов. Вместо того чтобы сравнивать запрос с каждым вектором, индекс организует векторы в граф. Каждый узел представляет собой вектор, а ребра соединяют векторы, которые численно близки. Такая структура позволяет значительно сузить пространство поиска.

Граф строится заранее, основываясь исключительно на связях между векторами. Он не зависит от запросов. Когда поступает запрос, задача системы - эффективно перемещаться по графу и определять векторы с наименьшим расстоянием до запроса, не сканируя весь набор данных.

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

И два наиболее важных шага в этом процессе - расширение списка кандидатов и обновление списка результатов.

Расширение списка кандидатов

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

На каждой итерации алгоритм:

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

Многократно расширяя список кандидатов, поиск исследует все более релевантные области графа. Это позволяет алгоритму неуклонно двигаться к лучшим ответам, исследуя лишь небольшую часть всех векторов.

Обновление списка результатов

В то же время алгоритм ведет список результатов, в который записываются лучшие кандидаты, найденные на данный момент для окончательного вывода. По мере выполнения поиска он:

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

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

Проще говоря, список кандидатов управляет поиском, а список результатов фиксирует лучшие ответы, найденные на данный момент.

Компромисс в векторном поиске на основе графов

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

Однако эта эффективность не достается даром. Поиск на основе графов выявляет фундаментальный компромисс между точностью и стоимостью.

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

Баланс между этими противоположными силами - высокой отзывчивостью и эффективным использованием ресурсов - является центральным моментом при разработке поиска на основе графов.

И DISKANN, и AISAQ построены с учетом этих противоречий, но они делают разные архитектурные решения о том, как и где оплачиваются эти расходы.

Как DISKANN оптимизирует векторный поиск на основе дисков

DISKANN - самое влиятельное на сегодняшний день решение на основе дисковых ИНС, которое служит официальным базовым уровнем для конкурса NeurIPS Big ANN, глобального эталона векторного поиска миллиардного масштаба. Его значимость заключается не только в производительности, но и в том, что он доказал: для быстрого поиска ANN на основе графов не обязательно полностью жить в памяти.

Сочетая SSD-накопители с тщательно подобранными структурами в памяти, DISKANN продемонстрировала, что крупномасштабный векторный поиск может достигать высокой точности и низкой задержки на аппаратном обеспечении, не требуя огромных площадей DRAM. Это достигается за счет переосмысления того, какие части поиска должны быть быстрыми, а какие могут допускать более медленный доступ.

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

1. Использование расстояния PQ для расширения списка кандидатов

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

DISKANN избегает этих затрат, сжимая векторы в коды Product Quantization (PQ) и сохраняя их в памяти. PQ-коды намного меньше полных векторов, но все же сохраняют достаточно информации для приблизительной оценки расстояния.

Во время расширения кандидатов DISKANN вычисляет расстояния, используя эти PQ-коды в памяти, вместо того чтобы считывать полные векторы с SSD. Это значительно сокращает дисковые операции ввода-вывода во время обхода графа, позволяя быстро и эффективно расширять кандидатов, при этом большая часть трафика SSD не попадает на критический путь.

2. Совместное размещение полных векторов и списков соседей на диске

Не все данные можно сжать или получить к ним приблизительный доступ. После того как перспективные кандидаты определены, для получения точных результатов поиск по-прежнему нуждается в доступе к двум типам данных:

Списки соседей, чтобы продолжить обход графа
полные (несжатые) векторы для окончательного ранжирования.

К этим структурам обращаются реже, чем к PQ-кодам, поэтому DISKANN хранит их на твердотельном накопителе. Чтобы минимизировать дисковые накладные расходы, DISKANN помещает список соседей каждого узла и его полный вектор в одну и ту же физическую область на диске. Это гарантирует, что при одном чтении с SSD можно получить и то, и другое.

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

3. Параллельное расширение узлов для лучшего использования твердотельных накопителей

Поиск ANN на основе графов - это итерационный процесс. Если в каждой итерации расширяется только один узел-кандидат, система выдает только одно чтение с диска за раз, оставляя большую часть параллельной пропускной способности SSD неиспользованной. Чтобы избежать этой неэффективности, DISKANN расширяет несколько кандидатов в каждой итерации и отправляет параллельные запросы на чтение на твердотельный накопитель. Такой подход позволяет гораздо лучше использовать доступную полосу пропускания и сократить общее количество необходимых итераций.

Параметр beam_width_ratio управляет тем, сколько кандидатов расширяется параллельно: Ширина луча = количество ядер процессора × соотношение ширины луча. Более высокое соотношение расширяет поиск, потенциально повышая точность, но также увеличивает объем вычислений и дисковых операций ввода-вывода.

Чтобы компенсировать это, DISKANN использует search_cache_budget_gb_ratio, который резервирует память для кэширования часто используемых данных, сокращая повторные чтения с SSD. Вместе эти механизмы помогают DISKANN сбалансировать точность, задержку и эффективность ввода-вывода.

Почему это важно - и где появляются пределы

Конструкция DISKANN - это большой шаг вперед для векторного поиска на дисках. Благодаря тому, что PQ-коды хранятся в памяти, а более крупные структуры переносятся на SSD, она значительно сокращает занимаемую память по сравнению с индексами графов, полностью хранящимися в памяти.

В то же время эта архитектура по-прежнему зависит от постоянно включенной DRAM для критически важных для поиска данных. Коды PQ, кэши и управляющие структуры должны оставаться в памяти, чтобы обеспечить эффективность обхода. По мере роста массивов данных до миллиардов векторов и добавления реплик или регионов, потребность в памяти может стать ограничивающим фактором.

Именно этот недостаток и призван устранить AISAQ.

Как работает AISAQ и почему это важно

AISAQ опирается непосредственно на основные идеи DISKANN, но вносит критический сдвиг: он устраняет необходимость хранить данные PQ в DRAM. Вместо того чтобы рассматривать сжатые векторы как критически важные для поиска структуры, всегда находящиеся в памяти, AISAQ переносит их на твердотельный накопитель и пересматривает способ размещения данных графа на диске, чтобы сохранить эффективность обхода.

Чтобы это работало, AISAQ реорганизует хранилище узлов таким образом, чтобы данные, необходимые для поиска графа - полные векторы, списки соседей и информация PQ - располагались на диске в шаблонах, оптимизированных для локальности доступа. Цель состоит не только в том, чтобы переместить больше данных на более экономичный диск, но и в том, чтобы сделать это без нарушения процесса поиска, описанного ранее.

Для удовлетворения различных требований приложений в AISAQ предусмотрено два режима хранения данных на дисках: Производительность и Масштаб. С технической точки зрения эти режимы различаются главным образом тем, как хранятся сжатые PQ-данные и как к ним осуществляется доступ во время поиска. С точки зрения приложений эти режимы отвечают двум разным требованиям: требованиям низкой задержки, характерным для онлайновых систем семантического поиска и рекомендаций, и требованиям сверхвысокого масштаба, характерным для RAG.

Производительность AISAQ: Оптимизировано для скорости

В режиме AISAQ-performance все данные хранятся на диске, а накладные расходы на ввод-вывод снижаются за счет размещения данных.

В этом режиме:

Полный вектор каждого узла, список ребер и PQ-коды его соседей хранятся вместе на диске.
Посещение узла по-прежнему требует только одного чтения с SSD, поскольку все данные, необходимые для расширения и оценки кандидатов, размещены на диске.

С точки зрения алгоритма поиска, это в точности повторяет схему доступа DISKANN. Расширение кандидатов остается эффективным, а производительность во время выполнения сопоставима, даже несмотря на то, что все критически важные для поиска данные теперь хранятся на диске.

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

Поэтому в режиме AISAQ-Performance приоритетом является низкая задержка ввода-вывода, а не эффективность работы с диском. С точки зрения приложений, режим AiSAQ-Performance может обеспечить задержку в диапазоне 10 мс, что необходимо для онлайнового семантического поиска.

Масштаб AISAQ: Оптимизация для повышения эффективности хранения данных

Режим AISAQ-Scale использует противоположный подход. Он разработан для минимизации использования диска, при этом все данные хранятся на SSD.

В этом режиме:

PQ-данные хранятся на диске отдельно, без избыточности.
Это устраняет избыточность и значительно уменьшает размер индекса.

Компромисс заключается в том, что для доступа к PQ-кодам узла и его соседей может потребоваться несколько считываний с SSD, что увеличивает количество операций ввода-вывода при расширении кандидатов. При отсутствии оптимизации это может значительно замедлить поиск.

Для борьбы с этими накладными расходами в режиме AISAQ-Scale вводятся две дополнительные оптимизации:

Перегруппировка данных PQ, которая упорядочивает векторы PQ по приоритету доступа для улучшения локальности и уменьшения случайных чтений.
Кэш PQ в DRAM (pq_read_page_cache_size), который хранит часто используемые данные PQ и позволяет избежать повторных чтений с диска для "горячих" записей.

Благодаря этим оптимизациям режим AISAQ-Scale достигает гораздо большей эффективности хранения, чем AISAQ-Performance, сохраняя при этом практическую производительность поиска. Эта производительность остается ниже, чем у DISKANN, но при этом отсутствуют накладные расходы на хранение (размер индекса аналогичен DISKANN), а объем памяти значительно меньше. С точки зрения приложений, AiSAQ предоставляет средства для удовлетворения требований RAG в сверхвысоких масштабах.

Ключевые преимущества AISAQ

Перенося все критически важные для поиска данные на диск и изменяя способ доступа к ним, AISAQ кардинально меняет стоимость и масштабируемость векторного поиска на основе графов. Его конструкция обеспечивает три существенных преимущества.

1. До 3 200× меньшее использование DRAM

Квантование продукта значительно уменьшает размер высокоразмерных векторов, но при миллиардных масштабах объем памяти все равно остается значительным. Даже после сжатия PQ-коды должны храниться в памяти во время поиска в обычных системах.

Например, для SIFT1B, эталона с миллиардом 128-мерных векторов, одни только PQ-коды требуют примерно 30-120 ГБ DRAM, в зависимости от конфигурации. Для хранения полных векторов без сжатия потребуется еще ~480 ГБ. Хотя PQ сокращает использование памяти на 4-16×, оставшийся след все еще достаточно велик, чтобы доминировать над стоимостью инфраструктуры.

AISAQ полностью устраняет это требование. Благодаря хранению кодов PQ на SSD вместо DRAM память больше не расходуется на постоянные индексные данные. DRAM используется только для легких, переходных структур, таких как списки кандидатов и метаданные управления. На практике это позволяет сократить использование памяти с десятков гигабайт до примерно 10 МБ. В репрезентативной конфигурации миллиардного масштаба объем DRAM снижается с 32 ГБ до 10 МБ, то есть на 3 200 раз.

Учитывая, что SSD-накопители стоят примерно 1/30 цены за единицу емкости по сравнению с DRAM, этот сдвиг оказывает прямое и значительное влияние на общую стоимость системы.

2. Отсутствие дополнительных накладных расходов на ввод-вывод

Перемещение PQ-кодов из памяти на диск обычно увеличивает количество операций ввода-вывода во время поиска. AISAQ избегает этого, тщательно контролируя расположение данных и шаблоны доступа. Вместо того чтобы разбрасывать связанные данные по диску, AISAQ размещает PQ-коды, полные векторы и списки соседей так, чтобы их можно было извлекать вместе. Это гарантирует, что расширение кандидатов не приведет к дополнительным случайным чтениям.

Чтобы предоставить пользователям контроль над компромиссом между размером индекса и эффективностью ввода-вывода, AISAQ вводит параметр inline_pq, который определяет, сколько данных PQ хранится в строке на каждом узле:

Меньше inline_pq: меньший размер индекса, но может потребоваться дополнительный ввод-вывод.
Большее значение inline_pq: больший размер индекса, но сохраняется однократный доступ.

При конфигурации с inline_pq = max_degree AISAQ считывает полный вектор узла, список соседей и все PQ-коды за одну дисковую операцию, что соответствует шаблону ввода-вывода DISKANN, сохраняя все данные на SSD.

3. Последовательный доступ к PQ повышает эффективность вычислений

В DISKANN расширение узла-кандидата требует R случайных обращений к памяти для получения PQ-кодов его R соседей. AISAQ устраняет эту случайность, получая все PQ-коды за один ввод-вывод и последовательно сохраняя их на диске.

Последовательное расположение обеспечивает два важных преимущества:

Последовательное чтение с твердотельного накопителя происходит гораздо быстрее, чем случайное чтение.
Непрерывные данные более удобны для кэширования, что позволяет процессорам эффективнее вычислять расстояния PQ.

Это повышает скорость и предсказуемость вычислений расстояний PQ и помогает компенсировать затраты на производительность при хранении кодов PQ на SSD, а не в DRAM.

AISAQ против DISKANN: оценка производительности

После понимания того, чем AISAQ архитектурно отличается от DISKANN, следующий вопрос прост: как эти конструктивные решения влияют на производительность и использование ресурсов на практике? В данной статье мы сравниваем AISAQ и DISKANN по трем параметрам, которые наиболее важны в миллиардных масштабах: производительность поиска, потребление памяти и использование диска.

В частности, мы изучаем, как ведет себя AISAQ при изменении объема встроенных данных PQ (INLINE_PQ). Этот параметр напрямую контролирует компромисс между размером индекса, дисковым вводом-выводом и эффективностью во время выполнения. Мы также оцениваем оба подхода на векторных рабочих нагрузках с низкой и высокой размерностью, поскольку размерность сильно влияет на стоимость вычисления расстояний и требования к хранению.

Установка

Все эксперименты проводились на одноузловой системе, чтобы изолировать поведение индекса и избежать влияния сетевых или распределенных системных эффектов.

Аппаратная конфигурация:

ПРОЦЕССОР: Процессор Intel® Xeon® Platinum 8375C @ 2,90 ГГц.
Память: Скорость: 3200 MT/s, Тип: DDR4, объем: 32 ГБ
Диск: 500 ГБ NVMe SSD

Параметры построения индекса

{
  "max_degree": 48,
  "search_list_size": 100,
  "inline_pq": 0/12/24/48,  // AiSAQ only
  "pq_code_budget_gb_ratio": 0.125,
  "search_cache_budget_gb_ratio": 0.0,
  "build_dram_budget_gb": 32.0
}

Параметры запроса

{
  "k": 100,
  "search_list_size": 100,
  "beamwidth": 8
}

Метод бенчмарка

DISKANN и AISAQ были протестированы с помощью Knowhere, векторного поискового движка с открытым исходным кодом, используемого в Milvus. В этой оценке использовались два набора данных:

SIFT128D (1 млн векторов): известный 128-мерный эталон, обычно используемый для поиска дескрипторов изображений. (Размер сырого набора данных ≈ 488 МБ)
Cohere768D (1M векторов): 768-мерный набор вложений, типичный для семантического поиска на основе трансформаторов. (Размер необработанного набора данных ≈ 2930 МБ)

Эти наборы данных отражают два различных сценария реального мира: компактные зрительные характеристики и большие семантические вкрапления.

Результаты

Sift128D1M (полный вектор ~488 МБ)

Cohere768D1M (полный вектор ~2930 МБ)

Анализ

Набор данных SIFT128D

На наборе данных SIFT128D AISAQ может сравниться с производительностью DISKANN, когда все данные PQ выстраиваются в ряд, так что необходимые данные каждого узла полностью помещаются на одной странице SSD объемом 4 КБ (INLINE_PQ = 48). При такой конфигурации каждый фрагмент информации, необходимый для поиска, размещается в колоке:

Полный вектор: 512B
Список соседей: 48 × 4 + 4 = 196B
PQ-коды соседей: 48 × (512B × 0.125) ≈ 3072B
Итого: 3780B

Поскольку весь узел умещается на одной странице, на один доступ требуется только один ввод-вывод, и AISAQ избегает случайного чтения внешних PQ-данных.

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

Набор данных Cohere768D

На наборе данных Cohere768D AISAQ работает хуже, чем DISKANN. Причина в том, что 768-мерный вектор просто не помещается на одну страницу SSD объемом 4 КБ:

Полный вектор: 3072B
Список соседей: 48 × 4 + 4 = 196B
PQ-коды соседей: 48 × (3072B × 0.125) ≈ 18432B
Итого: 21 700 Б (≈ 6 страниц)

В этом случае, даже если все PQ-коды вложены, каждый узел занимает несколько страниц. Хотя количество операций ввода-вывода остается неизменным, каждый ввод-вывод должен передавать гораздо больше данных, что приводит к ускоренному расходованию пропускной способности SSD. Как только пропускная способность становится ограничивающим фактором, AISAQ не может идти в ногу с DISKANN - особенно на высокоразмерных рабочих нагрузках, где объемы данных на каждом узле быстро растут.

Примечание:

Схема хранения AISAQ обычно увеличивает размер индекса на диске на 4-6×. Это сознательный компромисс: полные векторы, списки соседей и PQ-коды размещаются на диске, чтобы обеспечить эффективный одностраничный доступ при поиске. Хотя это увеличивает использование SSD, дисковая емкость значительно дешевле DRAM и легче масштабируется при больших объемах данных.

На практике пользователи могут настраивать этот компромисс, регулируя коэффициенты сжатия INLINE_PQ и PQ. Эти параметры позволяют сбалансировать производительность поиска, занимаемую площадь на диске и общую стоимость системы в зависимости от требований рабочей нагрузки, а не ограничиваться фиксированными лимитами памяти.

Заключение

Экономика современного оборудования меняется. Цены на DRAM остаются высокими, в то время как производительность твердотельных накопителей стремительно растет - пропускная способность дисков PCIe 5.0 теперь превышает 14 ГБ/с. В результате архитектуры, в которых критически важные для поиска данные переносятся из дорогой DRAM в более доступные SSD-накопители, становятся все более привлекательными. Учитывая, что стоимость гигабайта емкости SSD в 30 раз ниже, чем DRAM, эти различия больше не являются второстепенными - они оказывают существенное влияние на дизайн системы.

AISAQ отражает этот сдвиг. Благодаря отсутствию необходимости постоянно выделять большой объем памяти он позволяет системам векторного поиска масштабироваться в зависимости от объема данных и требований рабочей нагрузки, а не от ограничений DRAM. Такой подход соответствует более широкой тенденции к архитектурам "все в хранилище", в которых быстрые SSD играют центральную роль не только в сохранении данных, но и в активных вычислениях и поиске. Предлагая два режима работы - Performance и Scale - AiSAQ удовлетворяет требованиям как семантического поиска (требующего минимальной задержки), так и RAG (требующего очень высокого масштаба, но умеренной задержки).

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

Более подробную информацию об обсуждаемых здесь конструкциях см. в документации:

У вас есть вопросы или вы хотите получить подробную информацию о любой функции последней версии Milvus? Присоединяйтесь к нашему каналу Discord или создавайте проблемы на GitHub. Вы также можете заказать 20-минутную индивидуальную сессию, чтобы получить знания, рекомендации и ответы на свои вопросы в Milvus Office Hours.