在提到数据库时,关系数据库因其简单性和易用性,长期以来一直是数据存储的默认选择。然而,在当今以数据为驱动的互联网行业中,非结构化数据(如文本、图像和音频)的存储需求日益增多,使得向量数据库成为了一个可行的替代方案。
向量数据库与传统数据库有显著的功能差异。传统数据库的数据存储和管理仅限于整数和字符串等原始数据类型,而向量数据库以向量为单位进行数据存储和管理,能够高效处理非结构化数据,因而逐渐变得很受欢迎。目前市场上有大量公司提供向量数据库产品和向量搜索服务,而 MyScale 作为独特的 SQL 向量数据库在市场中脱颖而出。我们将通过一系列文章全面对比 MyScale 和其他一些热门向量数据库,第一个就是 Pinecone。Pinecone 是一个闭源的,专门用于高维向量数据高效处理的向量数据库。它在存储、索引和查询向量嵌入方面表现出色,是相似性搜索和需要实时和高维向量操作的机器学习应用的理想解决方案。
在开始对比 MyScale 和 Pinecone 之前,我们需要先对与向量数据库相关的重要概念进行简答说明。
为什么向量搜索很重要
向量可以表示多种数据:值数组、文本数据、空间数据、图像等等。执行基本的向量算术或进行点积运算以找到这些数据的对齐/相似性是比较简单的。
非结构化数据通过转化为 vector embedding 存储在向量数据库中。然后,我们可以使用余弦相似度或欧氏距离等原始相似度度量快速高效地执行向量的相似性搜索。与传统数据库的搜索模式相比,这种向量搜索更快速、更低成本,非常适合在短时间内处理大量非结构化数据。
什么是SQL向量数据库
除了专业向量数据库外,一些 SQL 数据库还通过扩展功能提供了向量搜索功能。这些集成解决方案被称为 SQL 向量数据库,旨在在结构化数据环境中提供基于向量的相似性搜索功能,并在统一的数据库框架内管理向量和结构化数据。
MyScale 是一个扩展了 ClickHouse 功能的开源 SQL 向量数据库。它是唯一一个在速度和性能方面能够超越专用向量数据库的集成数据库。
在 LLM 领域的重要性
随着LLM的出现,相关的应用在不同细分领域中快速扩展。这些基础模型可以通过多种方法适应应用程序的特定要求,这些方法可以广义地分为两类:微调和检索增强生成(RAG)。
就微调来说,我们使用现有模型并对其进行微调以适应新的/相关的数据。由于涉及机器学习,微调模型会消耗非常大的计算计算资源,因此成本过高。尽管市场上有 LoRA 等技术,但开发者仍然需要一些强大的 GPU 来进行 LLM 的微调。
而 RAG 和微调截然不同,RAG 不涉及传统的学习过程,而是基于向量数据库使用 vector embedding 进行向量搜索。这种方法利用原始相似度度量,使搜索过程显著加快。
到这里我们基本已经了解了所有基本概念。现在让我们开始比较 MyScale 和 Pinecone。
托管
在选择数据库解决方案时,托管是一个关键方面,它对性能、可扩展性和管理产生重大影响。强大的托管方式可以确保数据库能够处理不同的负载、保持可访问性并且易于维护。此外,了解托管方式有助于用户使用自己的资源在本地部署数据库和云托管服务之间做出选择。
MyScale 和 Pinecone 都可以通过在云上创建项目来以云为基础的模式进行使用。Pinecone 仅支持专有云服务; 而 MyScale 同时提供云版本 MyScale Cloud,和在 Github (https://github.com/myscale/myscaledb) 上提供的开源版本。用户可以使用以下Docker 命令启动开源版本:
docker run --name MyScale --net=host myscale/MyScale:1.6
此外,MyScale Cloud 还额外提供免费套餐,让您可以快速注册并上手实验。有关更多详细信息,请查看快速入门文档。
核心功能
查询语言和API支持
在采用新的数据库技术时,用户的一个关键考虑因素是其与现有开发工作流程的集成易用性和对查询语言的熟悉程度。幸运的是,MyScale 通过使用在关系型数据库中广泛使用的SQL 来解决这个问题。
MyScale 的优势不只于此,它还提供了集成的各种开发工具,如 Python 客户端、Node.js、Go 客户端、ClientJDBC 驱动程序和 HTTPS 接口。
TL;DR:Pinecone和MyScale都提供了各种语言的SDK,但MyScale在全面支持SQL方面具有明显优势。
支持的数据类型
Pinecone 专门用于存储向量。而 MyScale 则更加灵活,允许我们存储文本或图像等不同的数据类型。
我们可以创建一个具有标量和向量属性的表用于进行无缝切换。由于使用了 SQL API ,这个过程就像创建一个普通的关系型数据库表一样简单。以下 SQL 代码展示如何创建一个具有长度为512的body_vector
的表。
CREATE TABLE default.wiki_abstract(
id UInt64,
body String,
title String,
url String,
body_vector Array(Float32),
CONSTRAINT check_length CHECK length(body_vector) = 512
)
ENGINE = MergeTree
ORDER BY id;
此外,由于它使用了表格格式,行长度没有限制。因此,MyScale 的文档大小没有限制,这明显优于市场上的竞争对手。
索引
向量数据库中使用了多种索引算法,如 IVF 和 KD tree。Pinecone 使用了 Hierarchical Navigable Small Worlds(HNSW)算法和 FreshDiskANN 算法。FreshDiskANN 专为高效的实时更新而设计,支持大规模数据集的高召回率和性能。
而 MyScale 自研了多尺度树图(MSTG)算法,这是一种将分层树聚类和基于图的搜索相结合的算法。MSTG 提供更快的搜索速度和更少的资源消耗,显著优于现有算法。如果用户需要一个选择 MyScale 而不是 Pinecone的理由,MSTG 具有充足的说服力。
过滤向量搜索
Pinecone 具有元数据过滤功能,支持每个向量最多 40KB 的元数据。这些元数据可以包括字符串、数字和布尔值,从而实现详细的基于属性的搜索。Pinecone 的单阶段过滤机制将搜索限制在满足指定条件的项目上,通过避免蛮力搜索使过程更快速、更准确。
MyScale 使用 MST G算法与 ClickHouse 的高级索引和并行处理能力来优化过滤向量搜索。此外,还采用了预过滤策略,在主要向量搜索之前缩小数据集范围,提高性能和准确性。ClickHouse 的列式存储、向量化查询执行、高级索引和并行处理使其成为 MyScale 处理大型数据集的理想基础。这使它在保持速度和精度的同时不会出现后过滤的缺点。
TL;DR:Pinecone在具有丰富的元数据支持的详细属性搜索方面表现出色。而MyScale通过预过滤策略和基于SQL的架构,在处理大型数据集方面提供了更优越的性能和可扩展性。
全文搜索
通过使用 Tantivy,MyScale 还提供了高级的全文搜索(FTS)功能,包括模糊搜索和通配符搜索,以及基于 BM25 算法的相关性评分。这个功能使 MyScale 能直观、高效地访问非结构化文本数据,允许用户根据主题或核心内容进行搜索。MyScale 现在提供了一个强大高效的解决方案,用于复杂的文本搜索需求。要创建一个基本的 FTS 索引,可以按照以下步骤进行操作:
-- 创建全文搜索索引
ALTER TABLE [table_name] ADD INDEX [index_name] [column_name]
TYPE fts;
-- 进行查询
SELECT
id,
title,
body,
TextSearch(body, 'non-profit institute in Washington') AS score
FROM default.en_wiki_abstract
ORDER BY score DESC
LIMIT 5;
相比之下,Pinecone仅可用于向量搜索,而不具备内置的全文搜索功能。
TL;DR:MyScale的全文搜索功能使其成为需要全面数据查询和分析的应用程序的更优选择。
LLM API 集成
在这方面,我们对比的两个数据库之间没有太大区别,因为它们都支持常见的 API,如LangChain、LlamaIndex 等。这里提供一个使用 LangChain 和MyScale 的基本代码:
from langchain_community.vectorstores import MyScale
docsearch = MyScale.from_documents(docs, embeddings)
output = docsearch.similarity_search("How LLMs operate?", 3)
定价
Pinecone 和 MyScale 都提供免费套餐。这有利于新用户在作出正式选择之前先尝试一种新工具是否可用(或不可用)。对于新用户来说,Pinecone 的免费套餐提供了高达 2GB 的存储空间,可以处理大约每个向量具有 1536 维的 30 万个向量。
但 MyScale 提供的免费存储空间,可容纳高达 500 万个 768 维向量,或者大约 250 万个1536 维向量。这比 Pinecone 的免费套餐要多得多,使 MyScale 成为需要管理更大数据集而不希望有初始成本的用户的更优选择。
Pinecone 和 MyScale 都根据用户的需求提供性能和存储优化的 Pod。这种灵活性使用户能够根据自己的特定需求选择最佳解决方案。而在定价方面,MyScale 也比 Pinecone 便宜很多。
Capacity-optimized Pod 的定价
以下表格适用于需要更高存储容量的用户。它展示了 MyScale 和 Pinecone 在容量优化类别下提供的定价和容量选项。
Pod类型(MyScale) | Pod大小 | MyScale基本价格(每小时美元) | MyScale预估容量 | Pod类型(Pinecone) | Pinecone基本价格(每小时美元) | Pinecone近似容量 |
---|---|---|---|---|---|---|
容量优化Pod | x 1 | 0.094美元/小时 | 1000万个向量 | s1 | 0.11美元 | 500万个向量 |
容量优化Pod | x 2 | 0.189美元/小时 | 2000万个向量 | s1 | 0.22美元 | 1000万个向量 |
容量优化Pod | x 4 | 0.378美元/小时 | 4000万个向量 | s1 | 0.44美元 | 2000万个向量 |
容量优化Pod | x 8 | 0.756美元/小时 | 8000万个向量 | s1 | 0.89美元 | 4000万个向量 |
容量优化Pod | x 16 | 1.511美元/小时 | 1.6亿个向量 | - | - | - |
容量优化Pod | x 32 | 3.022美元/小时 | 3.2亿个向量 | - | - | - |
MyScale 的 capacity-optimized Pod 价格合理,提供更高的容量。与 Pinecone 相比,MyScale以更低的每小时成本存储更多的向量。
Performance-Optimized Pod 的定价
以下表格适用于性能优先级高于容量的用户。它展示了 MyScale 和 Pinecone 在性能优化类别下提供的定价和容量选项。
Pod类型(MyScale) | Pod大小 | MyScale基本价格(每小时美元) | MyScale预估容量 | Pod类型(Pinecone) | Pinecone基本价格(每小时美元) | Pinecone近似容量 |
---|---|---|---|---|---|---|
标准Pod | x 1 | 0.167美元/小时 | 500万个向量 | P2 | 0.17美元 | 100万个向量 |
标准Pod | x 2 | 0.333美元/小时 | 1000万个向量 | P2 | 0.33美元 | 200万个向量 |
标准Pod | x 4 | 0.667美元/小时 | 2000万个向量 | P2 | 0.67美元 | 400万个向量 |
标准Pod | x 8 | 1.333美元/小时 | 4000万个向量 | P2 | 1.33美元 | 800万个向量 |
标准Pod | x 16 | 2.667美元/小时 | 8000万个向量 | - | - | - |
标准Pod | x 32 | 5.333美元/小时 | 1.6亿个向量 | - | - | - |
在性能优化 Pod 方面,MyScale 的基本价格和 Pinecone P2 的相当,但 MyScale 的解决方案更具成本效益,可以在提供相同性能的情况下以更低的每小时成本存储更多的向量。
TL;DR:在存储优化 Pod 方面,MyScale 以更具成本效益的方式提供了与 Pinecone 的5个 p2 Pod 相媲美的性能。这使得 MyScale 成为需要高容量管理数据集的用户的理想选择。
基准测试
现在,我们将通过一些关键指标对 MyScale 和 Pinecone 的性能进行基准测试比较。在整个比较过程中,我们将使用带有 MSTG 的 MyScale,同时使用 Pinecone 的两个变体(1个节点和5个pods)。
吞吐量(每秒查询数)
吞吐量是系统性能的一个基本衡量标准,客户会关注每秒处理的查询数量。在单线程搜索中,Pinecone 的 s1 pod 明显落后于 MyScale。然而,Pinecone 的 5 个 p2 pods 可以处理与MyScale 相当的每秒查询量。当线程数增加到 2 个时,两者性能差距拉大,而在 8 个线程时,即使是 5 个 p2 pods 也落后于 MyScale 的吞吐量。
注意:在图表中,黄色代表MyScale,四个不同的点表示不同的精度级别。更高的精度需要更多的计算。Pinecone 的一个限制是无法像 MyScale 那样调整精度,因此最大召回率仅为94%。
TL;DR:Pinecone 的 s1 pod 无法与 MyScale 竞争,但 5 个 p2 pods 可以匹敌其性能。由于 Pinecone 无法调节精度,导致其召回率无法达到 99%,而MyScale则可以。
平均查询延迟
下一个关注的指标是平均查询延迟,它衡量处理查询所需的平均时间。在我们的测试中,Pinecone 的 s1 pod 无法与 MyScale 匹敌,而 5 个 p2 pods 才能具有竞争力。
为了让比较更有意义,我们排除了 s1 pod,专注于对比 5 个 p2 pods 与 MyScale 的性能。结果显示,MyScale 和 Pinecone 达到 4 个线程时表现出相似的延迟。然而,当线程数达到 8 或更多时,MyScale 的平均查询延迟会显著增加。
TL;DR:在对比 Pinecone 的 5 个 p2 pods 与 MyScale 时,两者在低精度下表现出相似的平均查询延迟。然而,Pinecone 无法调节精度,导致其召回率无法超过 94%,但 MyScale 可以。
数据导入时间
另一个有用的指标是数据导入时间——上传和构建数据库所需的时间。
MyScale 在处理 500 万个数据点时拥有更快的导入时间,约为 30 分钟。Pinecone s1 则需要约 53 分钟。
成本比较
在本次测试中,我们使用了 Pinecone 的 5 个 p2 pods,它们的性能相当于一个标准的MyScale pod。然而,5 个 p2 pods 的月成本约为 600 美元,比 MyScale 贵五倍。这种显著的成本差异凸显了 MyScale 的优越性:它以更低的价格提供了相同的性能。
数据库 | Pod类型 | 月成本(美元) | 备注 |
---|---|---|---|
MyScale | 标准Pod,大小x1 | 120 | 提供与五个Pinecone p2 pods相当的吞吐量和延迟 |
MyScale | 容量优化Pod | 68 | 成本效益高的容量优化选项 |
Pinecone | s1.x1 Pod | 80 | 针对存储进行优化 |
Pinecone | 5 x p2.x1 Pods | 600 | 通过水平扩展优化性能 |
尽管 MyScale 的平均 Pod 成本高 于Pinecone的s1 pod,但它提供的吞吐量和延迟相当于Pinecone 的 5 个 p2 pods,而成本仅为其五分之一。
TL;DR:MyScale 的标准 pod 更加划算,提供的性能与 Pinecone 的 5 个 p2 pods 相当,但后者的成本却高出五倍。
结论
在比较 MyScale 和 Pinecone 时,MyScale 凭借其基于 SQL 的集成、多样的数据类型支持和MSTG 算法的卓越性能脱颖而出。MyScale 具有更优秀的查询吞吐量和数据导入时间,更具成本效益的存储选项以及完善的全文搜索功能。这使得它成为管理大型、多样化数据集的绝佳选择。
Pinecone 在详细的基于属性的搜索和丰富的元数据支持方面表现出色。然而,MyScale 的开源性质、可扩展性和性能优势使其成为拥有更多功能的优秀选择。MyScale 在性能、灵活性和成本方面的优势使其成为应对处理多样化和大规模数据管理需求的理想向量数据库。