Rule of thumb: if one shard is working and no large sudden increase in size of corpus expected then one shard is better for many reasons.
On Tue, Sep 1, 2026, 7:20 AM Sunny Kumar Singh <[email protected]> wrote: > 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 >
