不仅仅是LLM，向量检索与OLAP引擎也早有渊源。作为一种用于数据分析的软件，OLAP能够快速、高效处理大量数据，并提供多维度的分析功能，而向量检索则能帮助OLAP引擎进一步提升对非结构化数据的分析和检索能力。

近期，火山引擎云原生数据仓库ByteHouse推出高性能向量检索功能，通过支持多种向量检索算法以及高效的执行链路，可以支撑极大规模向量检索场景，并达到毫秒级的查询延迟。

ByteHouse团队早已关注并研究向量检索技术。据ByteHouse技术专家介绍，“当前向量数据库的发展主要是两种思路，一种是建设一个专用的向量数据库，基于Vector-centric 的思路来设计向量数据及索引的存储与资源管理策略，查询定式简单，支持数据类型有限；另一种是基于现有数据库扩展向量检索能力，在已有数据管理机制以及查询执行链路中去添加向量索引维护与查询执行逻辑。目前，两种思路互相借鉴，向完备数据库功能支持+高性能向量检索的方式发展。”

ByteHouse来源于ClickHouse，但ClickHouse存在向量索引重复读取，相似度计算冗余等问题，对于延迟要求低、并发需求高的向量检索场景可用性较弱。

基于以上的分析，ByteHouse 在向量检索能力上进行全面创新。 首先，基于 vector-centric 的思路，ByteHouse 重新构建了高效的向量检索执行链路，结合索引缓存、存储层过滤等机制，使得性能实现进一步突破。另外，为了应对不同使用场景，ByteHouse 支持了 HNSW、Flat、IVFFlat、IVFPQ 等多种常见向量索引算法。此外，新引入的向量索引支持当前的二级索引相关语义，新的执行链路也对现有距离函数进行了适配，以降低用户使用门槛和学习成本，用户可以直接用 ClickHouse 的现有语义来使用高性能的向量检索功能。

 

ByteHouse向量检索相关组件

在建设高性能向量检索能力过程中，ByteHouse主要克服以下三大难点：

首先，列存结构读放大问题。为了减少不必要的数据读取操作，ByteHouse在 query 执行及数据读取层都进行了相应优化，并由 HaMergeTree 以及 HaUniqueMergeTree 两种引擎的可靠方案为向量检索提供稳定性保障。其次，新写入数据以及服务重启会存在冷读的问题，导致性能波动。为此，ByteHouse 引入 preload 机制，索引构建后自动载入缓存，同时支持对过期索引自动淘汰，避免多余的资源占用。最后，由于索引构建会消耗较多的资源，为了降低构建操作对正常查询的性能影响，ByteHouse引入资源控制策略，允许用户基于使用场景动态控制索引构建使用的资源，极大减少了原有链路的开销。

 

基于开源软件VectorDBBench ，与 milvus 2.3.0 进行测评

（测试环境：1 node, 80 cores, 376 GB Memory）

在最终性能效果上，ByteHouse团队基于业界最新的 VectorDBBench 测试工具进行测试，在 cohere 1M 标准测试数据集上，recall 98 的情况下，可以达到与专用向量数据库相近的性能。在 recall 95 以上的情况下，QPS 可以达到 2600 以上，p99 时延在 15ms 左右，具备业界领先优势。

性能优化一直是ByteHouse核心探索方向之一，以满足不断增长的数据处理和分析需求。不仅仅是向量检索技术，通过持续的研发和创新，ByteHouse还在查询分析、数据导入等多个方面极致优化，取得了显著的性能提升，在降本增效基础上，持续帮助企业更好地在数据驱动下实现加速决策效率。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。