随着LLM（Large Language Models 大语言模型）技术应用及落地，数据库需要提高向量分析以及AI支持能力，向量数据库及向量检索等能力“异军突起”，迎来业界持续不断关注。简单来说，向量检索技术以及向量数据库能为 LLM 提供外置的记忆单元，通过提供与问题及历史答案相关联的内容，协助 LLM 返回更准确的答案。

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

ByteHouse是火山引擎推出的云原生数据仓库，同时也是一款OLAP引擎。通过在已有数据管理机制以及查询执行链路中去添加向量索引维护与查询逻辑，ByteHouse近期拓展了高性能检索能力，目前已支持多种向量检索算法以及高效的执行链路，可以支撑大规模向量检索场景，并达到毫秒级的查询延迟。

《ByteHouse高性能向量检索技术指南V1.0》将结合ByteHouse团队对向量数据库行业和技术的前沿观察，解读OLAP如何建设高性能的向量检索能力以及相关落地场景。通过开源软件VectorDBBench测试工具，在 cohere 1M 标准测试数据集上，recall 98 的情况下，ByteHouse QPS性能已可以超过专用向量数据库。

概念解析

向量数据库的核心实现原理是向量化存储和索引技术。向量化存储是将向量数据转换为二进制格式进行存储，以提高存储效率和查询速度。向量索引是将向量数据进行索引，以便快速地进行相似度匹配和聚类分析等操作。
向量数据库中的向量是由多个维度组成的，每个维度代表向量的一个特征。例如，一个文档可以简单的表示为一个词频组成的向量。向量数据库中的向量可以是稠密向量或稀疏向量，稠密向量是指向量中大部分维度都有值，稀疏向量是指向量中只有少数维度有值。

原理介绍

向量数据库能够快速检索与查询相似的对象，是因为它们已经预先计算了这些相似度。其中的基本概念称为近似最近邻（ANN）搜索，它使用不同的算法进行索引和相似度计算。
当你拥有数百万个嵌入时，使用简单的 K 近邻（kNN）算法计算查询与你拥有的每个嵌入对象之间的相似度会变得耗时。通过使用近似最近邻搜索，你可以在一定程度上牺牲一些准确性以换取速度，并检索出与查询近似最相似的对象。索引 - 为此，向量数据库对向量嵌入进行索引。这一步将向量映射到一种数据结构中，以实现更快的搜索。

数据预处理

在向量化存储之前，需要对原始数据进行预处理，包括数据清洗、特征提取和特征归一化等步骤。例如，在文本向量化中，需要对文本进行分词、去停用词和词干提取等处理，然后使用词袋模型或词向量模型将文本转换为向量。

向量编码

将向量数据编码为二进制格式，以便存储到磁盘或内存中。常用的向量编码方法有二进制编码、哈希编码和压缩编码等。哈希编码是将向量映射到一个哈希表中，以便快速地进行相似度匹配。压缩编码是将向量中的冗余信息进行压缩，以减少存储空间。

存储管理

将编码后的向量数据存储到磁盘或内存中，需要进行存储管理，包括数据分片、数据压缩和数据索引等步骤。数据分片是将向量数据分成多个块，以便分布式存储和查询。数据压缩是将向量数据进行压缩，以减少存储空间。数据索引是将向量数据进行索引，以便快速地进行相似度匹配和聚类分析等操作。

数据查询

向量化存储后，需要进行数据查询，包括相似度匹配和聚类分析等操作。相似度匹配是指在向量数据库中查找与查询向量最相似的向量，常用的相似度计算方法有余弦相似度和欧几里得距离等。聚类分析是指将向量数据分成多个簇，以便进行数据分析和挖掘。

选型分析

当前向量数据库的发展主要是两种思路，一种是建设一个专用的向量数据库，基于Vector-centric 的思路来设计向量数据及索引的存储与资源管理策略，查询定式简单，支持数据类型有限；另一种是基于现有数据库扩展向量检索能力，在已有数据管理机制以及查询执行链路中去添加向量索引维护与查询执行逻辑。

专用向量数据库

专用向量数据库（如Milvus、Pinecone等）大多数可支持的数据类型较少，并且缺乏企业级功能，如多环境部署选项（本地、混合和云）、灾难恢复、ACID、数据安全和治理。对于较小的项目和原型，这效果很好，因为它们可以非常快速地启动项目，并用于搜索PDF或其他非结构化数据文件。

数据库+向量扩展

目前行业上，越来越多数据库拓展了向量能力，如Elasticsearch、PostgreSQL、MongoDB、ByteHouse等，这类数据库具备以下优势：

• 更广泛的数据处理。提供向量处理功能以及传统数据库功能，如支持SQL和JSON数据。这使数据架构进一步复杂化，通常也意味不需要额外购买另一个数据库，以此达到节省成本的目标。
• RAG的多功能性。结构化和向量数据检索结合可以为大模型提供更丰富的上下文，产生更准确的上下文感知。

ByteHouse简介

ByteHouse是字节跳动数据平台自主研发的云原生数据仓库产品，在开源ClickHouse引擎之上做了技术架构重构，实现了云原生环境的部署和运维管理、存储计算分离、多租户管理等功能，已通过火山引擎对外提供服务。在可扩展性、稳定性、可运维性、性能以及资源利用率方面，ByteHouse都有巨大的提升。
截至2022年2月，ByteHouse在字节跳动内部部署规模超过1万8000台，单集群超过2400台。经过内部数百个应用场景和数万用户锤炼，并在多个外部企业客户中得到推广应用。

产品特性

ByteHouse以提供高性能、高资源利用率、高稳定性、低运维成本为目标，进行了优化设计和工程实现，产品特性和优势如下：

• 存储计算分离：解决了全局元数据管理，过多小文件存储性能差等等技术难题。在最小化性能损耗的情况下，实现存储层与计算层的分离，独立扩缩容。
• 新一代 MPP 架构：结合 Shared-nothing 的计算层以及 Shared-everything 的存储层，有效避免了传统 MPP 架构中的 Re-sharding 问题，同时保留了MPP并行处理能力。
• 数据一致性与事务支持。
• 计算资源隔离，读写分离：通过计算组(VW)概念，对宿主机硬件资源进行灵活切割分配，按需扩缩容。资源有效隔离，读写分开资源管理，任务之间互不影响，杜绝了大查询打满所有资源拖垮集群的现象。
• ANSI-SQL：SQL兼容性全面提升，支持ANSI-SQL 2011标准，TPC-DS测试集100%通过率。
• UDF：支持Python UDF/UDAF创建与管理，补足函数的可扩展性。(Java UDF/UDAF已在开发中)
• 自研优化器：自研Cost-Based Optimizer，优化多表JOIN等复杂查询性能，性能提升若干倍。

产品能力上，在引擎外提供更加丰富的企业级功能和可视化管理界面：

• 库表资产管理：控制台建库建表，管理元信息。
• 多租户管理：支持多租户模型，租户间互相隔离，独立计费。
• RBAC权限管理：支持库、表、列级，读、写、资源管理等权限。通过角色进行管理。
• VW自动启停，弹性扩展：计算资源按需分配，闲时关闭。降低总成本，提高资源使用率。
• 性能诊断：提供Query History和Query Profiler功能，帮助用户自助地排查慢查询的原因。

适用场景

ByteHouse定位为一款数据仓库产品，主要用于OLAP查询和计算场景。在实时数据接入、大宽表聚合查询、海量数据下复杂分析计算、多表关联查询场景下有非常好的性能。
主要的的应用场景如下：

ByteHouse向量检索介绍

ByteHouse来源于ClickHouse，但ClickHouse存在向量索引重复读取，相似度计算冗余等问题，对于延迟要求低、并发需求高的向量检索场景可用性较弱。ByteHouse 在向量检索能力上进行全面创新，具备以下特点：

• 具备较全的 SQL 语法支持， 还提供大量的函数支持用户构造复杂的结构化数据与非结构化数据的混合查询语句，提升灵活性、易用性。
• 支持OLAP 混合场景，支持结构化&非结构化数据，比目前专用向量数据库具备更广泛的应用场景。
• 减少了文本/向量/OLAP 混合场景中对组件组件依赖，降低工程复杂度。
• 存储计算分离架构更容易解决向量数据库 index 构建任务重影响正常读写问题。
• ByteHouse高性能查询引擎，能为向量搜索相关查询提供高效率执行底座，让查询性能更优。
• 支持查询优化器，混合查询下可以根据 cost 去选择最优计划，进一步提升性能。
• 支持数据实时更新和实时查询。
• 成本较低，相比ES性能提升数倍以上，相同场景机器资源节省80%。

难点与挑战

向量检索的目标是查找与给定向量最相似的 k 个结果，广泛用于以图搜图、推荐系统等场景。近两年，随着大模型的普及，而基于向量检索构建的大模型检索增强功能，能够显著改善大模型的结果准确率低的问题，得到了广泛的关注。因此，向量检索相关技术，以及基于向量检索的向量数据库的概念逐渐流行起来，成为数据库领域一个热门话题。
实际使用场景中，向量检索针对的数据集大小通常会在 million 甚至 billion 级别，而查询延迟通常会要求在数毫秒到百毫秒内返回，因此，通常不会使用 brute force 的方式进行计算，而是会使用具有特殊结构的向量检索索引的方式来计算，比较流行的向量索引算法有 HNSW、Faiss IVF 等。

这类基于向量索引的向量检索负载大概具有以下几个特点：

• 构建时间长，资源消耗大：索引的构建时间通常比较长，远大于数据插入的时间，以常用的 gist1M 数据集为例不同类型的索引构建时间大概需要几十秒甚至上百秒。此外，构建索引通常需要消耗较多的 CPU 及内存资源。因此，在实现向量检索功能时，需要考虑如何高效管理索引构建任务需要的资源，保证构建速度的同时，也不会影响其他任务的进行。
• 内存计算：HNSW、Faiss IVF 类索引都需要将索引结构全部读取到内存中，而索引结构通常会包含有所有向量数据的原始数据以及一些额外的结构相关数据，因此其大小通常会大于向量数据的总量，由于结构较大每次加载索引时间会比较长，对于查询低延迟和高 QPS 的需求场景通常需要索引常驻内存。因此，向量检索功能需要考虑如何支持内存计算，并考虑内存资源的高效管理。
• 融合查询：用户通常需要查询相近向量的很多其他属性信息，通常也需要结合一些标量过滤条件进行更符合预期的结果筛选。因此，向量检索功能需要考虑如何降低从向量检索到其他属性读取的额外开销，同时考虑如何与过滤语句结合。

当前，ByteHouse 已经有一套 skip index 实现方案。向量索引可以作为一种新型的 skip index 引入使用。
然而，原本的 skip index 体系并不能高效支持向量检索相关计算，主要为以下3点：

• ByteHouse 缺少针对 skip index 的 cache 机制，无法保证向量索引常驻内存。
• skip index 只用于查询计划执行前做 mark level 的过滤，过滤的结果需要通过额外的距离计算才能获取到 topK 的结果，而不是直接使用 skip index 计算的结果来获取，导致计算上存在冗余。
• skip index 只能按照 mark 粒度（mark * granule）来进行构建，对于数据量较大的 data part 而言，会存在多个 skip index，带来更多的 IO 与计算的开销。

考虑到以上几点，ByteHouse团队认为现有的 skip index 架构不能支持高性能的向量检索计算，因此重新针对向量检索场景设计了一套全新的架构方案。

架构设计

ByteHouse 的向量检索功能整体的架构如下图所示：

在向量索引方面，ByteHouse接入了 hnswlib、faiss 两个比较流行的检索算法库，支持 HNSW、IVF_PQ、IVF_PQ_FS 等多种常用索引。另外，考虑到向量检索需要在内存中执行，ByteHouse还加入了向量索引缓存机制，确保查询涉及的 data part 索引常驻内存，实现低延迟向量检索。
另外，ByteHouse基于现有 skip index 逻辑，添加了对应索引的构建语句支持，指定每个 data part 只构建一个索引。
为了解决构建资源消耗较高的问题，在索引构建流程上，ByteHouse添加了构建资源（CPU）控制机制，并且针对内存使用较大场景（IVF 类型索引的 train 方法），提供了 on disk 的构建逻辑。
在查询执行方面，ByteHouse在查询的各个层次针对向量检索相关的查询进行了 Pattern 识别与 Query 改写，目前主要识别 order by L2Distance/cosineDistance + limit topK 相关查询，并针对向量检索的计算特点，实现了全新的 SelectWithSearch 算子，用来执行实际向量检索与其他属性读取操作。
新旧执行链路比较如下：

• Skip Index Based Pipeline

• New Pipeline

举例，构建语句如下：

CREATE TABLE test_ann
(
    `id` UInt64,
    `label` String,
    `vector` Array(Float32),
    INDEX v1 vector TYPE HNSW('DIM=960, METRIC=COSINE')
)
ENGINE = MergeTree
ORDER BY id

举例，查询语句如下：

select 
    id， 
    label,
    dist 
from test_ann 
prewhere label = '...'
order by cosineDistance(vector, [query_vector]) as dist 
limit 100 

优化方案

向量列读取操作消除

识别向量列是否只在向量检索操作中需要，如果是，则在最终的读盘操作中，去掉向量列，减少不必要的读取操作

向量检索计算前置

默认执行流程中，我们会为每个 data part 创建一个 SelectWithSearch 算子，计算时会针对单个 part 执行向量检索与其他属性的读取，由于读取任务最小的读取单元是一个 mark，这样的执行计划总的读取行数最大可为 (part_num * mark_size * topK) 行。造成的结果是性能会随 part 数量增多而不断下降。为了优化多 part 场景的查询性能，我们提出了一种向量检索前置的优化思路，即在执行计划实际执行之前，将所有 part 的向量检索全部先进行计算，得到全局的 topk 个结果，再进行各个 part 的其他属性读取，这样改造后，每次查询要读取的行数最高为 (mark_size * topK) ，实际场景测试中，latency 会有 2x 以上的提升。

Cache Preload

当前支持的向量索引需要加载到内存中才能进行高性能的向量检索计算。在查询执行到向量检索相关操作时，如果发现待计算的 data part 对应向量索引未存在与 vector index cache 中，则需要首先调用 load 操作将 index load 到内存中，查询则需要等待 load 结束后才能继续执行。vector index load 操作会显著增加查询的执行实现，尤其是对于新写入的 data part 或者 server 重新启动的场景。
针对这个问题，ByteHouse添加了 cache preload 的机制，在 data part 生成以及 server 启动过程中，将 index load 自动到内存中，并且添加特定的 setting，支持 table level 以及 global 的 cache preload 配置。
该机制为当前支持的 HaMergeTree、HaUniqueMergeTree 引擎都添加了支持。

ByteHouse 团队基于业界最新的 VectorDBBench 测试工具进行测试，测试机器配置为 80 核 376 GB 内存。在 cohere 1M 标准测试数据集上，recall 98 的情况下，QPS 可以达到开源向量数据库 Milvus （2.3.0）的 2 倍以上。在 recall 95 以上的情况下，QPS 最高可以达到 4200+，p99 时延在 15ms 以内，具备业界领先优势

向量检索的核心功能是能检索任意数据对象的相似度，比如文本、图片、视频、声音等一切数字化内容的相似度，因此以文本相似度检索、问答检索、图片声音视频检索、人脸识别、智能推荐为核心功能的应用场景，都可以基于向量检索能力来构建。

核心应用场景如下表所示：

大模型类应用

大模型类应用主要有企业知识库、智能问答、大模型辅助系统、创作助手（内容创作领域)等，将企业行业深度相关的内容，进行分割、整理，录入到数据库中，供下游使用。包括企业员工的检索访问、企业内部问答访问、配合大模型更加智能有逻辑地回答问题。
以企业专属问答知识库为例，实现方案可以为将文档片段向量化（通过语言模型，如bert等），存储在ByteHouse。使用者提问之后，系统对问题语句进行向量化，以余弦相似度或点积等指标，计算在向量数据库中和问题向量最相似的top k个文档片段，通过大模型的上下文组织能力，将查询结果包装成标准回答返回给应用系统。
该场景特点是数据量较大，而且需要做逻辑分割管理；对于性能要求在几十-上百ms，召回率要求较高。ByteHouse具备性能高、扩展性强，支撑海量数据集、支持SQL易用性好的特点，比较适合该类场景。

商品搜索和推荐

在电商场景中，采用标量数据条件检索与图片检索相结合的方式搜索商品，让用户能更直观地搜索到感兴趣的商品；也可以基于向量相似度检索功能，实现相似商品推荐功能。
例如用户要检索发货地在上海，价格区间为200-1000元，风格为韩版的，并与上传的一张图片相似度高的衣服。采用ByteHouse能用一条SQL同时对标量数据和向量数据进行检索、，简单易用，检索性能高。

图片视频搜索

如下图所示，支持上传一张图片，并输入时间、相似度、信息来源等条件，检索全网视频中与目标图片相似视频，该场景利用了ByteHouse的标量数据与向量数据混合检索能力，采用如下的SQL语句即可进行快速检索:

SELECT　unique_id,create_time,image_url,platform,update_time,post_category,post_id,　    post_publish_time,dist　
FROM qian.photo_vec7 
WHERE (post_publish_time >= '2023-11-22 11:00:00') AND (post_publish_time <= '2023-11-24 11:00:00') WHERE (post_category = 1)　
ORDER BY cosineDistance(vector, [10, 5, 23, 17, 9, 9, 3, 12, 32, 40, 32, 3, 8, 26, 26, 54, 93, 91, 8, 7, 41, 22, 19, 119, 5, 8, 77, 33, 61, 55,, 56]) AS dist ASC　LIMIT 100;

场景1：舆情监控

背景情况：
舆情监控对数据实时性要求高，在现有技术方案中，该企业通过自建Elasticsearch来提供舆情相似度检索能力，但从性能、成本角度来看，还无法完全满足业务需求。在性能上，业务要求系统支持数万QPS的实时检索，采用ElasticSearch方案难以达到如此高的并发指标。在成本上，使用ElasticSearch方案伴随着高机器资源成本，随着数据量不断增大，机器资源成本将愈加不可控；此外，数据写入和查询流程较为复杂，导致应用开发成本高。
问题和需求：
该企业舆情数据高达几十亿，QPS峰值达到数万。对于所有分析型数据库来说，不仅要具备处理复杂OLAP分析场景的能力，还要支持超高QPS在线点查服务，并做到高吞吐、低延时、高稳定，是非常大的挑战。
解决方案：

• ByteHouse采用多副本机制，将全量数据写入主节点，实时自动同步至多个副本，并通过网关查询实现自动负载均衡、一写多读，从而线性提高并发能力。
• ByteHouse还支持通过SQL写入、查询完成业务逻辑，进一步简化数据处理流程，提升开发效率。在资源效率上，ByteHouse采用灵活的资源模型，可支持任意节点数量和副本数量变配。用户最开始只需购买最小资源，后续可随业务增长即时扩容，让成本更加可控。

应用效果：
在10亿数据记录下，单节点QPS峰值超过3000+，20亿数据情况下单节点QPS峰值1000+，比ES性能提升数倍，机器资源从ES 32C10节点变为 ByteHouse 32C3节点。

场景2：以图搜图

背景情况：
ByteHouse 支持将图片、视频、文章等非结构化数据转换为向量，存储在ByteHouse，然后通过SQL根据条件和向量的相似度查询符合条件的类似图片。
场景和需求：
在该企业的舆情监测场景中，需要输入一张图片，选择时间范围以及目标平台（抖音，快手，微博等），然后检索相似的图片和视频。目前基于ES构建，检索响应慢，需要的资源多，难以满足业务需求。
应用效果：
在同样数据和应用场景条件下，采用ByteHouse作为查询引擎，所需的机器资源减少60%，同时图像检索性能提升8倍。

建表

采用create table语句建表，用Array类型的字段存储向量特征数据。可以给向量特征字段增加一个索引。索引可以建表时添加，也可以建完表之后添加。
create table 时定义索引如下：

CREATE TABLE test_vector
(
    `id` UInt64,
    `label` String,
    `vector` Array(Float32),
    INDEX v1 vector TYPE HNSW('DIM=960, METRIC=COSINE'),
    CONSTRAINT cons_vec_len CHECK length(vector) = 960 -- 用于数据插入检查
)
ENGINE = MergeTree
ORDER BY id
SETTINGS 
index_granularity = 1024, -- 缓解读放大问题
index_granularity_bytes = 0 -- 避免生成 adaptive mark

通过alter add index 添加索引如下：

ALTER TABLE test_vector ADD INDEX v1 vector TYPE HNSW('DIM=960, METRIC=COSINE')

查询

采用如下语句对标量数据和向量数据进行检索：

select 
    id， 
    label,
    dist 
from test_vector 
where id>100 and label='a' 
order by cosineDistance(vector, [query_vector]) as dist 
limit 100 
settings enable_new_ann=1

作为一种数据库领域的常规技术，未来将有越来越多的传统数据库支持向量检索的技术，也会有更多更易用性能更强的向量检索算法以及算法库出现。
纵观行业发展，目前我们可以看到两个方向创新：一个为检索算法与索引的创新，包括自适应参数调优、early termination、与 filter 的结合、向量压缩、分布式检索结构等方面；一个为系统方面的创新，包括实时向量检索、嵌入式向量检索模块、索引推荐、数据隐私保护等方面。
当前，ByteHouse已经实现高性能向量数据库框架建设，未来会低资源消耗向量索引、查询性能优化、易用性、大模型生态等方面进行探索和优化。