火山引擎ByteHouse：“专用向量数据库”与“数据库+向量扩展”，怎么选？

本文主要是介绍火山引擎ByteHouse：“专用向量数据库”与“数据库+向量扩展”，怎么选？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

背景

随着LLM（Large Language Model）的不断发展，向量检索也逐渐成为关注的焦点。LLM通过处理大量的文本数据，获取丰富的语义信息，从而能够更好地理解和生成自然语言。然而，LLM的输出通常是一系列概率分布，这使得检索过程变得复杂。向量检索作为一种有效的检索方法，它将LLM的输出转化为向量表示，并利用向量之间的相似性来进行匹配。这种方式不仅能够直观地展示语义关系，还提高了检索的效率和准确性。因此，随着LLM的发展，向量检索也相应地迎来了更多关注和研究。

对于向量检索来说，一方面Milvus、Qdrant等专用向量数据库的出现提供了完备的向量检索能力，另一方面，也有一些数据库在自身基础上扩展出向量检索能力。作为火山引擎推出的一款云原生数据仓库，ByteHouse近期推出高性能向量检索功能，通过支持多种向量检索算法以及高效的执行链路，可以支撑级大规模向量检索场景，并达到毫秒级的查询延迟。

本篇内容将主要主要介绍向量检索的基本原理，分析“专用向量数据库”与“数据库+向量扩展”优劣势，并介绍以ByteHouse为代表的具备向量检索能力的数据仓库应用场景。

向量检索介绍

概念解析

向量数据库的核心实现原理是向量化存储和索引技术。向量化存储是将向量数据转换为二进制格式进行存储，以提高存储效率和查询速度。向量索引是将向量数据进行索引，以便快速地进行相似度匹配和聚类分析等操作。

向量数据库中的向量是由多个维度组成的，每个维度代表向量的一个特征。例如，一张图片可以表示为一个三维向量，分别代表图片的宽度、高度和颜色。向量数据库中的向量可以是稠密向量或稀疏向量，稠密向量是指向量中大部分维度都有值，稀疏向量是指向量中只有少数维度有值。

工作原理

向量数据库能够快速检索与查询相似的对象，是因为它们已经预先计算了这些相似度。其中的基本概念称为近似最近邻（ANN）搜索，它使用不同的算法进行索引和相似度计算。

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

数据预处理

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

向量编码

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

存储管理

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

数据查询

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

索引方式

向量检索算法基于其存储结构大致可分为四种。

第一种是 Table-based，典型算法如 LSH。LSH 算法的核心思想是通过哈希函数将相似的向量映射到相同的哈希桶中，从而实现高效的相似性搜索。这种方法能够在高维向量空间中快速找到相似的向量对，为相似性搜索提供了一种高效的近似解决方案。
第二种是 Tree-based。这是一种用于向量检索的索引方法。它利用树形数据结构（如B树或平衡树）来组织和管理向量数据，使得向量的查找、插入和删除操作能够在对数时间内完成。这种索引方法对于大规模和高维度的向量数据集非常有效，能够显著提高向量检索的效率。
第三种是 Cluster-based，也称为 IVF（Inverted File），把向量先进行聚类处理，检索时首先计算出最近的 k 个聚类中心，再在这些聚类中心中计算出最近的 k 个向量。这种索引的优点是构建速度快，因为构建时只需要多一个 training 的过程。相比于其他常用索引（主要是 Graph-based 索引），只需要额外存储倒排表和聚类中心结构，所以内存额外占用比较少。但也存在相应的缺点，由于每次查询要把聚类中心里面所有的向量都遍历一遍，所以它的查询速度受维度信息影响较大且高精度查询计算量比较大，计算开销大。这类索引通常还会结合一些量化算法来使用，包括 SQ、PQ等。
第四种是Graph-based，把向量按照相似度构建成一个图结构，检索变成一个图遍历的过程。常用算法是HNSW。它基于关系查询，并以构建索引时以及构建向量之间的关系为核心，而主要技术则是highway和多层优化方式。这种算法的优点是查询速度快、并发性能好；而缺点则表现为构建速度慢、内存占用高。

目前实际场景中，使用较多的方法主要是后面的两种，即 Cluster-based 和 Graph-based。

为什么OLAP引入向量检索

向量数据库目前还处于一个快速发展的阶段，目前看有两个趋势：

第一种是以专用向量数据库为基础，不断添加更多复杂的数据类型支持以及更多的数据管理机制，比如存算分离、一致性支持、实时导入等。此外，查询上也在不断添加前后置过滤等复杂查询策略的支持。

第二种构建思路是数据库加向量检索扩展，继续去支持更多的向量检索算法，并且不断按照向量检索的需求，添加特殊的过滤策略、简化对应的执行计划。

以上两种构建思路都在向一个统一的目标去汇合，即带有高性能向量检索，与完备数据管理和查询支持的数据库形态。

提升多维数据处理能力

随着大数据时代的来临，数据量呈爆炸式增长，用户需要更高效、更精准的数据分析工具来帮助他们快速理解数据背后的趋势和模式。向量检索能力的引入，可以将数据从表格形式转化为向量表示，利用机器学习算法对数据进行相似性匹配和聚类分析。这使得用户能够更快速地找到与查询条件相似的数据，进行更深入的数据探索和洞察。因此，引入向量检索能力是OLAP产品提升用户体验和满足用户需求的重要方向之一。

作为一款OLAP引擎，ByteHouse在支持结构化数据的单表、多表复杂查询计算基础上，扩展了向量检索能力，支持向量数据存储、索引和高效检索，从而支持商品推荐、智能问答系统、图片搜索、视频检索等应用场景。

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

支持更复杂的分析场景

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

行业	应用场景
互联网电商	商品以图搜搜
互联网－社交	图像去重、视频原创验证、风控审核、关联推荐、舆情监控
政府机构	视频检索、指纹搜索、人体图像检索、车辆查找、内容查重
金融	文本检索、智能客服
零售	商品识别、自动售货机

大模型场景

大模型类应用主要有企业知识库、智能问答、大模型辅助系统、创作助手（内容创作领域)等，将企业行业深度相关的内容，进行分割、整理，录入到数据库中，供下游使用，包括企业员工的检索访问、企业内部问答访问、配合大模型更加智能有逻辑地回答问题。

以企业专属问答知识库为例，将文档片段全部向量化（通过语言模型，如bert等），存到ByteHouse。如果用户输入问题，则对问题语句进行向量化，以余弦相似度或点积等指标，计算在向量数据库中和问题向量最相似的top k个文档片段，通过大模型的上下文组织能力，将查询结果包装成标准回答返回给应用系统。

：在数据量较大，而且需要做逻辑分割管理；对于性能要求在几十ms到一两百ms；对召回率要求较高。ByteHouse的优势是性能好、扩展性好能支撑海量数据集、支持SQL易用性好。

商品搜索和推荐

在电商场景中，采用标量数据条件检索与图片检索相结合的方式搜索商品，让用户能更直观地搜索到感兴趣的商品；也可以基于向量相似度检索功能，实现相似商品推荐功能。

例如用户要检索发货地在上海，价格区间为200-1000元，风格为韩版，并与上传的一张图片相似度高的衣服。采用ByteHouse能用一条SQL同时对标量数据和向量数据进行检索，简单易用，检索性能高。

图片视频搜索

以图搜图：这是向量检索在图片搜索中的常见应用。用户可以通过上传一张图片，系统会返回与该图片相似的图片。这背后的原理是将图片转化为向量，然后计算查询向量与数据库中其他向量之间的相似度，从而找出相似的图片。
视频处理：在视频处理方面，向量检索可以用于实时跟踪视频中的对象轨迹，或者检索与特定动作或场景相似的视频片段。

如下图所示，ByteHouse支持上传一张图片，并输入时间、相似度、信息来源等条件，检索全网视频中与目标图片相似视频，该场景利用了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;

向量检索产品如何选型

向量检索能力比较

目前支持向量检索功能的产品主要有专业的向量数据库，例如Milvus、Qdrant；另外其他数据库产品，如开源社区ClickHouse也支持了向量检索。我们从扩展性、易用性、混合负载能力等角度对比，如下：

	Milvus	Qdrant	ES	ClickHouse	ByteHouse
易扩展性	存储计算分离	存储计算耦合	存储计算耦合	存储计算耦合	存储计算分离
易用性	自定义API，不支持SQL	自定义 API，不支持 SQL	自定义 API，不支持 SQL	支持较全的SQL语法	支持较全的SQL语法
混合负载能力	支持基于简单类型标量的过滤，不支持聚合	支持基于简单标量类型过滤支持基于某个特定标量的 group by 操作（group by key 必须为 string 或 integer 类型）		支持OLAP和vector search混合场景	1.支持OLAP和vector search混合场景2.支持optimizer，可以实现混合负载的CBO自动优化
索引类型	HNSW/IVF类索引/DiskANN 等	HNSW		Annoy	HNSW/IVFPQ/DiskANN等
支持的数据类型	较少	较少		支持常见数据类型	支持常见数据类型
单表是否支持多个vector	否	是		是	是
检索性能	高	中	低	中	高

选型总结

总结来看，与专用向量数据库相比，ByteHouse作为一款OLAP引擎，还支持结构化&非结构化数据，具备更广泛的应用场景，并且ByteHouse存储计算分离架构更容易解决向量数据库 index 构建任务重影响正常读写的问题。

在性能上，一方面ByteHouse本身高性能查询特性，为向量搜索相关查询提供高效率的执行底座，另一方面，ByteHouse 查询优化器能力，在混合查询下可以根据 cost 去选择最优计划，让查询性能更优。在功能上，ByteHouse具备较全的 SQL 语法支持，并且还提供了大量的函数支持用户构造复杂的结构化数据与非结构化数据的混合查询语句，具备灵活性、易用性。

通过将向量能力扩展到OLAP引擎上，企业可以获得高效性能、集成便利、丰富的分析功能、可扩展性和成熟的生态系统等优势。这些优势可以帮助企业更好地利用向量数据进行高效的数据分析和挖掘，从而更好地支持决策和业务发展。

点击跳转火山引擎ByteHouse了解更多

这篇关于火山引擎ByteHouse：“专用向量数据库”与“数据库+向量扩展”，怎么选？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！