TL;DR
Five fresh items since your July 29 drop: (1) Tencent’s TEngineDB‑V proposes an OLAP‑native vector search path for large‑k analytics and a new DPPQ quantizer, reporting up to 145× speedups; (2) RaG‑Tree unifies R‑trees with partition‑aware HNSW for multi‑attribute range–filtered ANN; (3) a “join index” for Lucene/Solr cuts cross‑collection join latency 5–8× by turning joins into a prunable semijoin over segments; (4) Milvus 3.0 adds server‑side Aggregation and ORDER BY (plus “Search Aggregation”) so you can shape structured results without post‑processing; (5) a lakehouse paper shows filtered ANN by composing Iceberg/Parquet file pruning with per‑file IVF, yielding up to ~32–94× gains when layout has file‑level locality.
TEngineDB‑V: OLAP‑native vector search for large‑k analytics (Tencent)
- Key facts and current state of the topic
- Many systems cap k or bolt vector search onto OLAP, paying scatter‑gather and post‑processing costs for analytics (e.g., k in the 10^3–10^5 range). (arxiv.org)
- Important context and background information
- TEngineDB‑V decomposes IVFPQ search into relational operators and materializes a global, segment‑decoupled index as OLAP tables; it also introduces DPPQ (direction‑aware PQ + hierarchical residual refinement). (arxiv.org)
- Recent developments or changes
- Authors report up to 145× speedup vs. competitive OLAP baselines (e.g., StarRocks) and up to 52× in 10‑billion–scale production deployments—worth watching if you run analytical retrieval over large result sets. (arxiv.org)
RaG‑Tree: R‑tree + partition‑aware HNSW for multi‑attribute range filters
- Key facts and current state of the topic
- Multi‑attribute range‑filtered ANN (e.g., “kNN where price∈[a,b] AND ts∈[t1,t2]…”) remains hard; most indexes optimize one attribute or recurse per‑attribute. (arxiv.org)
- Important context and background information
- RaG‑Tree couples hierarchical R‑tree partitions (effective range pruning) with locally tuned HNSW graphs per partition to reflect local vector distributions. (arxiv.org)
- Recent developments or changes
- The preprint (Aug 2) reports superior query performance with lightweight indexing and fast incremental updates across three real datasets—relevant for high‑selectivity, attribute‑rich search. (arxiv.org)
Join indices for Lucene/Solr: prunable semijoin across segments
- Key facts and current state of the topic
- Query‑time joins across collections (e.g., products↔SKUs) are common in e‑commerce/search but can be expensive at scale. (arxiv.org)
- Important context and background information
- This work builds a “join index” that turns joins into a parallel, prunable semijoin over Lucene segments, aligning with Lucene’s approximation/confirmation execution model. (arxiv.org)
- Recent developments or changes
- Prototype results (Aug 2) show average query latency 5.4× lower at concurrency 1 (359.8 ms vs. 1934.6 ms) and up to 8.3× at concurrency 8, with a small (~30 MB) auxiliary index and a <10‑query break‑even. Consider for hybrid stacks that join metadata to vector‑retrieved candidates. (arxiv.org)
Milvus 3.0: server‑side Aggregation and ORDER BY (plus Search Aggregation)
- Key facts and current state of the topic
- Post‑retrieval shaping (facets, grouped metrics, sorting) often forces app‑side processing or a second analytics engine. (milvus.io)
- Important context and background information
- An Aug 7 engineering post details new Milvus 3.0 primitives: exact “Query aggregation” (count/sum/avg/min/max with GROUP BY), “Search Aggregation” (bucketed views over ANN candidates with per‑bucket metrics/top hits), and server‑side ORDER BY for both query and search paths. (milvus.io)
- Recent developments or changes
- These move group‑by/sort into the retrieval engine, reduce data movement, respect MVCC visibility, and provide explicit semantics for approximate, candidate‑bounded views—useful before heavier re‑ranking. (milvus.io)
Lakehouse filtered‑ANN: compose Iceberg/Parquet pruning with per‑file IVF
- Key facts and current state of the topic
- In lake‑native stacks, vectors and filter columns live together; engines already own strong file‑pruning (partitions, zone‑maps, bitmap indexes). (arxiv.org)
- Important context and background information
- A new paper (Aug 5) embeds an IVF index per Parquet file and rewrites planning to prune files first, then run per‑file ANN, assembling a global top‑k—avoiding new filtered‑ANN algorithms when file‑level locality exists. (arxiv.org)
- Recent developments or changes
- Reported gains: ~32× speedup at Recall@10 ≥ 0.90 on an 11.5M×768 table (355/444 files pruned) and ~94× (14.7 s→157 ms) on 5M real embeddings when a join‑borne predicate aligns with partitions—clear guidance for layout and caching in lake‑native retrieval. (arxiv.org)
If you want A/B plans, I can sketch: (a) large‑k evaluation of TEngineDB‑V ideas vs. your current OLAP+vector path; (b) RaG‑Tree‑style partitioning for your heaviest multi‑range predicates; (c) a Milvus 3.0 “Search Aggregation” pilot to replace app‑side facets; (d) lakehouse per‑file IVF where you already have Iceberg/Parquet with strong locality.