Hi All,
We have a multi-field dense-vector (HNSW) search running on SolrCloud and
would like to understand the recommended configuration and expected
performance for our scale.
Environment
-
Solr: 9.6.1
-
Lucene: 9.10.0
-
Java: 17.0.11
-
GC: G1GC
-
Collection: vector-search
-
Documents: ~2 million
-
Current shard: 1
-
Index size: ~131 GB
Vector Field Definitions
We have 3 DenseVectorField fields per document, each with 2048 dimensions:
<fieldType name="knn_vector_2048"
class="solr.DenseVectorField"
vectorDimension="2048"
similarityFunction="cosine"
hnswMaxConnections="16"
hnswBeamWidth="200"/>
<field name="img_emb"
type="knn_vector_2048"
indexed="true"
stored="true"/>
<field name="text_emb"
type="knn_vector_2048"
indexed="true"
stored="true"/>
<field name="multimodal_emb"
type="knn_vector_2048"
indexed="true"
stored="true"/>
Actual Query Pattern
For every search query, we perform 3 independent KNN searches, one for each
vector field, with topK=100.
The results are then combined using Boolean should clauses with different
weights:
q={!bool should=$imgb should=$textb should=$multib}
imgq={!knn f=img_emb topK=100}<image_vector>
imgb={!boost b=0.2 v=$imgq}
textq={!knn f=text_emb topK=100}<text_vector>
textb={!boost b=0.4 v=$textq}
multiq={!knn f=multimodal_emb topK=100}<multimodal_vector>
multib={!boost b=0.4 v=$multiq}
Solr Configuration
Current relevant settings:
-
ramBufferSizeMB=200
-
TieredMergePolicy
-
maxMergeAtOnce=5
-
segmentsPerTier=5
-
Default ConcurrentMergeScheduler
-
filterCache: LRUCache, size 512
-
queryResultCache: LRUCache, size 512
-
documentCache: LRUCache, size 512
-
useColdSearcher=true
-
maxWarmingSearchers=2
Questions1. HNSW Configuration
For a dataset of approximately 2M documents × 2048 dimensions × 3 vector
fields, are the following HNSW parameters reasonable?
- hnswMaxConnections = 16
- hnswBeamWidth = 200
What values would you recommend for M (hnswMaxConnections) and construction
beam width (hnswBeamWidth) at this scale?
2. Query-Time Configuration
We currently use topK = 100 for each vector search.
- Is topK = 100 appropriate for a dataset of this size?
- What topK range would you recommend for achieving a good balance
between recall and query latency?
- Does Solr 9.6.1 provide an efSearch-equivalent query-time parameter
for controlling the HNSW search breadth?
- If not, what is the recommended way to tune query-time recall versus
latency in Solr?
3. Multi-Field Vector Search
We currently perform 3 independent KNN searches, one for each vector field,
and combine the results using a Boolean should query with weighted boosting.
Is this a recommended approach for multi-vector-field search?
Alternatively, would you recommend:
- Candidate retrieval from each vector field followed by second-stage
reranking
- Score fusion across the three KNN results
- Using a single fused/combined embedding
- Another approach that is better suited for Solr 9.6.1
We would also like to understand the impact of these approaches on recall,
ranking quality, and latency.
4. Shard Size
We currently have approximately 2M documents and a 131 GB index in a single
shard.
Is this shard size reasonable for HNSW-based vector search?
Would you recommend splitting the data across multiple shards?
If so, is there any practical rule of thumb for the number of vectors or
total index size per shard for HNSW workloads?
We would also like to understand how shard count affects:
- Query latency
- Memory requirements
- HNSW search performance
- Indexing/merge performance
5. RAM Requirements
For approximately 2M documents × 2048 dimensions × 3 vector fields, what
would be a reasonable RAM configuration?
We would like to understand the expected memory requirements for:
- Raw vector data
- HNSW graph
- Other Lucene index structures
- JVM heap
- OS/page cache
- Additional Solr/Lucene overhead
What amount of total RAM would you recommend for a production setup, and
how much headroom should be kept beyond the estimated working set?
6. Solr Caches
Our current Solr cache configuration is:
- filterCache = 512
- queryResultCache = 512
- documentCache = 512
For a KNN-heavy workload, are these cache sizes useful?
Do KNN/vector searches benefit significantly from these Solr caches, or
does vector search primarily rely on Lucene's underlying data structures
and the OS page cache?
Would you recommend any changes to these cache configurations for a
vector-search-heavy workload?
7. Expected Latency
For the following setup:
- ~2M documents
- 2048-dimensional vectors
- 3 vector fields
- 3 KNN searches per query
- topK = 100
- HNSW-based vector search
- Properly provisioned server with sufficient RAM
What would be a reasonable expected latency ?
It would also be helpful to understand which factors are likely to have the
greatest impact on latency, such as HNSW parameters, topK, number of vector
searches, shard count, RAM/page cache, and CPU.
Any real-world benchmarks or recommendations around hardware, RAM, CPU,
shard count, and QPS would also be very helpful.
Happy to share the complete schema, solrconfig, cluster topology, if
required.
Thanks,
Sunny Kumar Singh
