Hello,
Something that might help you reduce the size of your index : Unless you
really need to be able to get the original vectors values from your Solr
results, you can make your vector fields "non stored". Like so :
<field name="img_emb"
type="knn_vector_2048"
indexed="true"
stored="*false*"/>
This changes nothing in the vector search itself. You just won't be able to
retrieve the original vectors from Solr (which is usually not needed).
In your case, this would free up to 49Go (3 vectors per document * 2M
documents * 2048 dimensions per vector * 4 bytes per dimension (size of
float32)).
This specific optimization is explained in this very informative Youtube
video : https://youtu.be/cDiCX3mVAlQ?si=T5jQV0e47L4yU0VW&t=947
Guillaume
Le mar. 1 sept. 2026 à 16:19, Sunny Kumar Singh <[email protected]>
a écrit :
> 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
>
