1Z0-184-25 Question 52
Single answerYour company is building a recommendation engine using HNSW-based vector indexing on Oracle Cloud Infrastructure. The dataset is quite large, and user queries need to return results within milliseconds. Cost is also a concern, as you want to avoid overspending on compute resources. Which approach would best reduce query latency while keeping costs manageable?
- A
Deploy multiple smaller compute instances with locally attached NVMe storage, shard the HNSW index across them, and use a load balancer to distribute queries
- B
Use a single extra-large compute shape with maximum RAM to store the entire HNSW index in memory on one node
- C
Decrease the M parameter in the HNSW index to the minimum possible value to reduce the index size
- D
Lower efSearch to 1 to achieve the fastest query response times
Show answer and explanation
Correct answer: A
Explanation
HNSW (Hierarchical Navigable Small World) indexes support approximate nearest neighbor queries for vector data. For large datasets and frequently accessed queries, it is generally recommended to distribute the index across multiple compute shapes with locally attached NVMe or SSD storage. This approach reduces latency by handling queries in parallel and uses fewer large, expensive instances. Tuning HNSW parameters (M, efConstruction, efSearch) is also crucial, but extreme reductions in parameters can degrade accuracy or performance. Refer to Oracle Cloud Infrastructure documentation and best practices for vector search, which emphasize sharding and effective parameter tuning to achieve both performance and cost efficiency.
- A. Correct.
Correct. Sharding the HNSW index across smaller compute instances with locally attached NVMe storage helps distribute both the storage and compute workload, reducing latency while offering more cost control. Locally attached storage typically has lower latency compared to network block storage, and using a load balancer distributes search queries to the appropriate shard efficiently.
- B. Incorrect.
Incorrect. While storing the entire index in a single large instance might simplify architecture and reduce inter-node communication, it is less cost-effective for large datasets. Sustaining peak workloads with this setup could lead to significant expense and potential memory limits on one node.
- C. Incorrect.
Incorrect. Lowering M drastically shrinks the graph connectivity in HNSW. Although it can reduce the index size and memory usage, it typically degrades search accuracy and can impair overall performance during queries.
- D. Incorrect.
Incorrect. Setting efSearch to 1 will yield the fastest raw search times, but with extremely poor search accuracy. efSearch usually needs to be tuned to balance performance and result quality, and setting it too low often undermines the value of vector-based similarity search.