OpenSearch Vector Search Edition is a large-scale distributed search engine built by Alibaba Group, offering high availability, real-time data freshness, and cost-effective vector search for demanding production workloads.
Overview
OpenSearch Vector Search Edition is a large-scale distributed search engine built by Alibaba Group. It serves as the search backbone for the entire Alibaba Group—including Taobao, Tmall, Cainiao, Youku, and e-commerce platforms outside the Chinese mainland—and is the base engine of Alibaba Cloud OpenSearch. After more than ten years in production, it meets demanding requirements for high availability, real-time data freshness, and cost-effectiveness, with a built-in operations and maintenance (O&M) system for custom search deployments.
Architecture
OpenSearch Vector Search Edition has three main components: a management system, an online search system, and data sources. The online search system loads indexes and serves vector queries. Data sources supply both full data imports and real-time incremental updates. The management system handles automated O&M so you can create and manage clusters without manual intervention.
System architecture
Online search system
The online search system is table-scoped: each vector table is queried and managed independently. Per-table configuration covers fields, vector indexes, data sources, and real-time data concurrency. The backend uses a distributed architecture of two worker types: Query Result Searcher (QRS) workers and Searcher workers.
QRS workers receive, parse, verify, and rewrite your query requests, then fan them out to Searcher workers. After collecting and merging the results, QRS workers return the final response. QRS workers are stateless compute nodes that hold no user data, so their memory footprint is low. Memory usage rises only when queries return a large document set or generate many statistical entries. If QRS workers become a bottleneck, scale out by adding more workers or upgrading their specifications.
Searcher workers load index data, retrieve documents, and apply filtering, aggregation, and ranking. Indexes on Searcher workers can be sharded: each shard hashes fields to values in [0, 65535], and all shards together must cover the complete range. Set the number of shards when creating an index. Sharding improves single-query performance for large datasets. To increase overall queries per second (QPS)—for example, from 1,000 to 10,000—add replicas instead. When you add replicas, all data on every Searcher worker must be split into the same number of shards, and together they must cover [0, 65535].
CPU, memory, and disk resources on Searcher workers are shared across tables.
The figure above shows an example with two tables: Vector Table 1 has four shards and distributes data evenly across them based on generated indexes; Vector Table 2 has one shard and stores the full dataset on every Searcher worker as a broadcast table.
Data sources
A data source maps one-to-one to a table and drives index construction through full indexing (reindexing). After reindexing, the index data is loaded into the corresponding table in the online search system for retrieval. Supported data source types are MaxCompute, Search, Advertisement, and Recommendation Offline (SARO), and API. API data sources start empty—you push all data to the online search system by calling an API operation.
Management system
The management system is the O&M platform for OpenSearch Vector Search Edition instances. It significantly reduces operational overhead for provisioning and managing clusters.
Data synchronization process
Full indexing
OpenSearch Vector Search Edition maintains indexes across multiple versions, each built from a snapshot of the raw data. By default, API data sources start with empty raw data. Every reindexing run triggers a full indexing job. Full indexing is not a long-running process—it ends once data is processed and the index is built, at which point the new index is applied to online clusters.
Multi-version indexes protect data integrity across schema and structural changes. When the index schema or data structure changes, the new index version is isolated from earlier versions. If a data change causes an error, you can roll back to any earlier version.
Full indexing involves several stages: data processing, index building, and index merging. You can set the concurrency for each stage to speed up the overall process.
Real-time incremental indexing
After full indexing completes, each index version starts a long-running incremental indexing process. Data update nodes consume incremental data and keep the index continuously updated.
You can push incremental data from MaxCompute, Object Storage Service (OSS), and API data sources to tables via API operations. Data update nodes process the incoming data, and Searcher workers build indexes in real time for immediate retrieval.
Each full index of a table has a corresponding incremental indexing process. Adjust the number of data update nodes to match your real-time data throughput requirements.
Benefits
Built for mission-critical search
The engine is written in C++ and has powered core business systems across Alibaba Group for over ten years. It is a proven choice for search workloads that require high stability and cannot tolerate downtime.
Real-time updates at scale
As a distributed search engine, it handles large data volumes with data changes taking effect within seconds. Use it when your application requires time-sensitive search results—product inventory updates, live content feeds, or any scenario where stale results are unacceptable.
Cost-effective index management
Multiple index compression policies and multi-value index loading strategies let you meet query performance requirements at lower infrastructure cost.