Specification calculator
Before purchasing a Vector Search Edition instance, use the specification calculator to get recommended query node and data node configurations. This topic also provides HNSW and IVF_SQ8 benchmark data at different data scales as a performance reference for specification selection.
Use the specification calculator
On the Vector Search Edition purchase page, click Specification Calculator.
The OpenSearch Vector Search Edition Specification Calculator dialog box appears, containing the Basic Configurations, Vector Data Configurations, and Query Configurations sections. After filling in the parameters, click Perform Operation to get the recommended specifications.
Basic configurations
Instance region: The region where the engine will be created.
Disaster recovery: Whether disaster recovery is required. Select Yes or No from the drop-down list.
Vector data configurations
Number of vector docs: The number of vector data entries to be written to the engine.
Vector dimension: The dimension of the vectors to be written to the engine.
Vector algorithm: Select a vector algorithm based on your requirements. The following three algorithms are supported:
HNSW: A graph-based vector retrieval algorithm with very high recall rate and good performance. Its memory and storage consumption is comparable to Linear. HNSW performs well on both low-dimensional and high-dimensional vector datasets, making it suitable for most vector search scenarios.
QC: A quantization and clustering-based vector retrieval algorithm with very high recall accuracy, low resource consumption, and good performance. It performs better on low-dimensional vector datasets. Its memory and storage consumption is typically about one-fourth of that required by Linear and HNSW. QC is suitable for large-scale retrieval scenarios that do not have strict requirements for recall rate.
Linear: A linear search algorithm (brute-force search) that guarantees completely accurate retrieval results but consumes significant resources and offers lower performance. It is typically used for precise searches on small datasets with up to 10,000 entries.
Query configurations
Average QPS: The expected queries per second (QPS) for the engine.
Expected average response time: The target average response time for recall results. The unit can be seconds (s) or milliseconds (ms).
After filling in the parameters, click Perform Operation.
The recommendation includes parameters such as query node specification family, number of query nodes, query node specification, data node specification family, number of data nodes, data node specification, and storage space/disk space per data node. Purchase the corresponding specifications based on the recommended results.
HNSW benchmark data
The following test data is based on public datasets, using engine version vector_service 1.5.9, with a configuration of 1 query node + 1 cloud disk data node. Index build parameters: M = 100, ef-construction = 500.
Dataset | Specification | Parameters | recall@k (serial) | P95 latency (serial) | Peak QPS (concurrent) | Peak concurrency | Query node CPU/Mem | Data node CPU/Mem | Index memory usage |
OpenAI 1536D 50K | 2C8G query node + 2C16G data node | ef=20, k=10 | 0.9793 | 20ms | 643 | 10 | 89%/12% | 61%/10% | 311MB |
ef=200, k=100 | 0.9991 | — | — | — | — | — | |||
4C16G query node + 4C32G data node | ef=20, k=10 | 0.9805 | 27ms | 1035 | 20 | 99%/7% | 38%/18% | ||
ef=200, k=100 | 0.9989 | 35ms | 744 | 20 | 88%/7% | 88%/18% | |||
Cohere 768D 1M | 4C16G query node + 4C32G data node | ef=20, k=10 | 0.9560 | 18ms | 1413 | 20 | 96%/7% | 48%/18% | 3.13GB |
ef=200, k=100 | 0.9919 | 131ms | 745 | 80 | 68%/7% | 91%/18% | |||
4C16G query node + 8C64G data node | ef=20, k=10 | 0.9598 | 26ms | 1601 | 30 | 99%/8% | 29%/8% | ||
ef=200, k=100 | 0.9921 | 25ms | 1527 | 30 | 97%/7% | 93%/8% | |||
Cohere 768D 10M | 8C32G query node + 8C64G data node | ef=20, k=10 | 0.9429 | 24ms | 1534 | 30 | 70%/3% | 95%/55% | 33GB |
ef=200, k=100 | 0.9552 | 55ms | 662 | 30 | 40%/5% | 95%/55% |
Relationship between data node memory watermark and performance
The following tests use the Cohere 768D dataset, with a configuration of 4C16G query node + 4C32G cloud disk data node, and an HNSW index (InnerProduct, ef-construction = 500, M = 100). Data is inserted incrementally (1M entries at a time) o observe the impact of data node memory usage percentage on QPS.
Data volume | Index memory usage | Process memory usage | QPS (k=10, ef=20) | QPS (k=100, ef=200) |
2M | 6.3GB | 26.6% | 1368 | 647 |
4M | 12.5GB | 47.8% | 1324 | 378 |
5M | 15.6GB | 59.2% | 1068 | 334 |
6M | 18.8GB | 69% | 1112 | 341 |
7M | 21.8GB | 80% | Nearly unusable | |
8M | — | — | — | — |
In a typical configuration, vector indexes, PK indexes, and inverted indexes are locked in physical memory using mlock for the lowest retrieval latency. Other data (attributes, summaries, etc.) is not locked with mlock and relies on OS page cache for on-demand loading. As memory usage percentage rises, page cache is compressed, and accessing attributes frequently triggers page faults, leading to increased latency:
Watermark > 70%: QPS drops sharply.
Watermark > 80%: Service becomes nearly unusable.
IVF_SQ8 benchmark data
The following tests use the Cohere 768D 10M dataset, with a configuration of 4C16G query node + 4C32G cloud disk data node.
Index build parameters:
{
"proxima.qc.builder.quantizer_class": "Int8QuantizerConverter",
"proxima.qc.builder.quantize_by_centroid": true,
"proxima.qc.builder.optimizer_class": "BruteForceBuilder",
"proxima.qc.builder.thread_count": 10,
"proxima.qc.builder.optimizer_params": {
"proxima.linear.builder.column_major_order": true
},
"proxima.qc.builder.store_original_features": false,
"proxima.qc.builder.train_sample_count": 3000000,
"proxima.qc.builder.train_sample_ratio": 0.5
}Serial test: recall rate and latency
Scan ratio | Recall rate | Latency (P99) | Latency (P95) |
0.01 | 0.9123 | 39.5ms | 35.7ms |
0.05 | 0.9454 | 84ms | 75ms |
Concurrent performance test: incremental insertion
10M entries of 768-dimensional vector data are inserted incrementally to observe the index size and query QPS changes at different data volumes.
Data volume | Index memory usage | Memory usage | QPS (scan ratio 0.01, k=100) | QPS (scan ratio 0.05, k=100) |
1M | 2.25GB | 7.4% | 1000 | 558 |
2M | 3.11GB | 10.4% | 766 | 258 |
4M | 4.95GB | 16% | 408 | 122 |
10M | 9.9GB | 32.4% | 131 | 46 |