MyScale vs. Zilliz：成本效益之战

Tue Aug 20 2024

向量数据库和向量搜索由于其速度和可扩展性而迅速受到欢迎。与需要大量训练的传统机器学习模型不同，向量搜索可以使用基本的相似度度量（如欧氏距离和余弦相似度）在向量数据库中快速执行。这使得它们在可扩展性和成本效益方面比基于机器学习的模型更具优势。

随着向量数据库的使用不断增长，自然而然地会寻求基于特定需求的最适合的数据库，考虑吞吐量和成本等各种因素。为了帮助用户做出明智的决策，我们推出了一系列文章，详细比较不同向量数据库。在我们上一篇博客中，我们对MyScale和Pinecone进行了全面比较 (opens new window)。这一次，我们将深入比较MyScale和Zilliz。

# MyScale

MyScale是一个专为AI应用和解决方案设计的基于云的数据库，利用开源的高度可扩展的ClickHouse数据库。使用MyScale的主要优势包括：

支持和管理结构化和向量化数据的分析处理，统一平台上执行操作。
利用先进的OLAP数据库架构以异常速度执行对向量化数据的操作。
只需要SQL作为与MyScale交互的编程语言。

# 介绍Zilliz

Zilliz是基于开源Milvus项目的强大的云原生向量数据库，专为高性能相似度搜索和机器学习而设计。虽然Milvus作为基础，但Zilliz提供了一个完全托管的云服务，包括免费和按需付费的层次，专为需要可扩展的向量管理而无需管理基础设施的用户量身定制。

在本博客中，我们将比较MyScale和Zilliz的云服务，以帮助您了解哪个更适合您的需求。让我们从托管开始比较。

# 托管

托管是选择数据库解决方案时需要考虑的关键因素，它对性能、可扩展性和管理产生重大影响。强大的托管选项确保您的数据库能够处理不同的负载、保持可访问性并易于维护。此外，了解托管选项有助于确定您是否需要使用自己的资源在本地部署数据库，还是选择云托管服务。

就托管而言，MyScale和Zilliz都提供开源版本、基于云的解决方案和本地托管解决方案。云托管提供免费和付费层次，我们很快将详细介绍。

对于本地托管，Docker镜像是一个常见的选择。我们可以启动MyScale Docker镜像如下：

docker run --name MyScale --net=host myscale/MyScale:1.6

对于Zilliz，我们可以使用Docker compose如下：

curl <https://github.com/milvus-io/milvus/releases/download/v2.0.2/milvus-standalone-docker-compose.yml> -o docker-compose.yml
docker-compose up -d

# 核心功能

现在我们将从两个数据库的核心功能开始比较。

# 查询语言和API支持

Zilliz和MyScale都支持各种编程语言的客户端，包括Python、Node.js和Go。Zilliz还支持C++、.Net（部分支持）、RESTful和Ruby。

然而，MyScale真正的优势在于它对SQL的支持。您可以使用传统的SQL查询与MyScale一起使用，它将与向量数据库或甚至传统和向量数据库的组合无缝配合工作。

TL;DR：

Zilliz和MyScale都提供各种语言的SDK，但MyScale具有完整的SQL支持的独特优势。

# 元数据支持

Zilliz支持元数据过滤中的正则表达式。它还在最新版本中支持了标量反向索引（基于Milvus 2.4）。

MyScale通过与ClickHouse的集成支持元数据过滤，ClickHouse提供了强大的索引和并行处理能力。这使得MyScale能够执行高性能、准确的过滤搜索，特别是在处理大规模数据集时。此外，在主要向量搜索之前采用了预过滤策略，以缩小数据集范围，提高性能和准确性。

TL;DR：

Zilliz在元数据过滤中具有正则表达式的优势，而MyScale的元数据过滤由于ClickHouse的可扩展性而不会降低性能，即使对于较大的数据集也是如此。

# 支持的数据类型

MyScale和Zilliz都支持向量数据。Zilliz的最新版本还包括对稀疏向量和二进制向量的支持。然而，MyScale在全面支持SQL的同时，具有更强大的优势，可以处理所有SQL数据类型。例如，这是一个具有向量（body_vector）和其他一些数据类型（在此示例中为UInt64和String）作为其属性的表的示例。

CREATE TABLE default.wiki_abstract_mini(
    `id` UInt64,
    `body` String,
    `title` String,
    `url` String,
    `body_vector` Array(Float32),
    CONSTRAINT check_length CHECK length(body_vector) = 1024
)
ENGINE = MergeTree
ORDER BY id
SETTINGS index_granularity = 128;

TL;DR：

Zilliz具有稀疏向量支持的优势，而MyScale具有全面的SQL数据类型的远超优势。

# 索引

MyScale和Zilliz都支持许多索引算法，如HNSW、IVF（及其变体）、FLAT等。Zilliz提供了自动索引，使用动态缓存和动态量化等功能。自动索引不是一个全新的索引算法，它在后台使用这些支持的索引算法。

MyScale不仅支持Zilliz，而且还支持所有流行的向量数据库，它支持多尺度树图（MSTG），这是一种将分层树聚类和基于图的搜索相结合的算法。MSTG通过提供更快的搜索和减少资源消耗，优于现代算法。

# 过滤向量搜索和全文搜索

MyScale通过其多尺度树图（MSTG）算法和位掩码技术优化了过滤向量搜索。这种组合加上ClickHouse的高级索引和并行处理能力，使MyScale能够高效处理大型数据集。通过使用预过滤策略，MyScale在主要向量搜索之前缩小数据集范围，确保只处理最相关的数据，从而显著提高性能和准确性。

另一方面，Zilliz也利用位掩码来有效地管理和应用大型数据集上的过滤条件。这种方法使Zilliz能够执行复杂的过滤操作，对性能影响很小。

由于Tantivy的支持，这两个数据库在搜索功能方面都非常丰富。它们支持全文搜索，而大多数其他向量数据库不支持。显然，两者之间没有什么区别，因为它们都支持混合搜索 (opens new window)。不过，在MyScale上执行混合搜索要简单得多，只需使用函数HybridSearch()。它将全文搜索和向量搜索的结果组合起来，以提供更好的结果。上面的图像很好地解释了对于给定的表wiki_abstract_mini。

# 多向量搜索

MyScale和Zilliz都支持多向量搜索。此外，Zilliz还提供了分组搜索，可以将存储在多个向量中的实体在搜索结果中分组，以得到综合的结果。类似地，MyScale通过SQL中的GROUP BY子句支持分组搜索。这使用户能够高效地聚合和分组搜索结果，更容易处理和分析MyScale中的大型数据集。

# 地理搜索

地理搜索对于不仅仅是地图和GIS应用程序，而且对于许多其他应用程序都非常重要。即使是像FoodPanda或一些杂货店这样的简单应用程序也可能需要它。虽然Zilliz不提供此功能，但MyScale具有许多地理空间函数 (opens new window)来支持地理搜索。例如，此函数可以找到地球上两点之间的距离（以流形为基础）：

greatCircleDistance(lon1Deg, lat1Deg, lon2Deg, lat2Deg)

# LLM API集成

MyScale和Zilliz都支持许多LLM API，如OpenAI、LLamaIndex、LangChain等。它们两者还支持Cohere模型和DSPy进行自动提示。以下是一个将LangChain与MyScale集成的代码示例。

from langchain_community.vectorstores import MyScale

docsearch = MyScale.from_documents(docs,embeddings)
output= docsearch.similarity_search("How LLMs operate?",3)

# 定价

最后，每个解决方案都受到两个最终参数的限制：价格和效率。关于效率，我们很快将对它们进行基准测试。首先，我们将在经济上对它们进行比较。

Zilliz和MyScale都提供免费和付费层次。我将在这里简要（并简洁）地比较两者。

# 免费层

Zilliz的免费层支持两个集合，最多可容纳0.5M个768维向量（使用GCP托管；Azure和AWS仅在专用服务器上可用）。

另一方面，MyScale为最多可容纳500万个768维向量提供免费存储空间，这意味着比集合容量多10倍或两个集合的总容量多5倍。这比Zilliz的免费层高得多（相当于付费层中的1CU容量优化），使得MyScale成为需要管理更大数据集而无需初始成本的用户更具吸引力的选择。

# 付费层

免费层对于实验是很好的，但最终我们必须将我们的解决方案部署在专用服务器上，这需要花钱。MyScale或Zilliz对您的投资有多有价值将在此进行分析。

注意：

Zilliz的物理节点称为计算单元（CU），而MyScale的物理节点称为Pod（以后将相应地引用）。

Zilliz和MyScale都提供两种类型的付费托管：

容量优化：旨在每个Pod/CU拥有更大的存储空间。MyScale每个Pod提供1000万个向量，而Zilliz每个CU提供最多500万个向量。
性能优化：适用于优先考虑性能（较低的延迟，更高的QPS）的应用程序。在这里，MyScale每个Pod提供最多500万个向量。Zilliz每个CU提供最多150万个向量。

如果您不确定选择哪个，请选择容量优化托管。

在一个数据驱动的世界中，展示确切的数字将非常有用，因为它将使您能够更轻松地进行比较。为了比较，我们将使用768维的向量维度，假设一个30天的月份，除非另有说明，否则将使用GCP托管。

Boost Your AI App Efficiency now

Free Trial

Explore our product

# 无服务器Zilliz

对于无服务器的Zilliz托管（使用虚拟CU），我们将假设一个月内在所有设置中进行100万次读取和100万次写入操作。

向量容量	每小时费用
100万	0.09美元
---	---
500万	0.21美元
1000万	0.31美元
2000万	0.47美元
4000万	0.74美元
8000万	1.15美元

现在我们将MyScale与专用的Zilliz（使用实际的CU）进行比较。如前所述，MyScale和Zilliz都提供两种类型的托管：容量优化和性能优化。将分别进行比较。

# 容量优化

对于容量优化的CU，Zilliz每个CU提供500万个向量，而MyScale每个Pod提供1000万个向量。这种差距使得MyScale的每小时成本更低。

向量容量	Zilliz（美元）	计算单元（CUs）	MyScale（美元）	Pods
1000万	0.276	2	0.094	1
---	---	---	---	---
2000万	0.55	4	0.19	2
4000万	1.1	8	0.38	4
8000万	2.2	16	0.76	8

# 性能优化

虽然我们上面讨论了MyScale在性能优化设置中每个Pod提供500万个向量，这比Zilliz提供的限制（每个Pod提供150万个向量）多3倍多，但实际上还有更多。

Zilliz收取额外的CU费用（显然没有理由）。如果计算一下10万个向量所需的CU数量，应该是：

1.510=6.67≈7

但它显示了8个CU。对于2000万个向量也是如此，它应该收取14个CU，但是收取了额外的几个CU。最后，它在4000万个向量上进行了修正，向您收取了准确的CU数量（尽管仍然远远低于MyScale相应解决方案的每小时费用）。

向量容量	Zilliz（美元）	CUs	MyScale（美元）	Pods
500万	0.55	4	0.17	1
---	---	---	---	---
1000万	1.1	8（应该是7）	0.33	2
2000万	2.2	16（应该是14）	0.67	4
4000万	3.84	28	1.33	8
8000万	7.68	56	2.67	16

TL;DR：

就费用效益而言，MyScale无与伦比。它提供的向量容量比容量优化和性能优化层次的Zilliz多2倍和3倍以上，而每小时费用仍然较低。

# 基准测试

以一些基本属性对它们进行基准测试是一个公平的比较。为了进行基准测试，我们将使用MyScale（使用MSTG）与这两个不同配置的Zilliz进行比较。为了给用户一个公正的比较，我们将使用Zilliz的最新版本：

2024-容量优化（1 CU）
2024-性能优化（4 CUs）

# 吞吐量

每秒查询数是对向量数据库的一个很好的基本度量。我们可以清楚地看到MyScale（较深的酸橙绿色）在单个计算单元的Zilliz节点上表现优异。具有多个计算单元的Zilliz（橙色）在QPS方面优于MyScale。然而，MyScale由于精确调整，可以达到更高的精度。

吞吐量

TL;DR：

MyScale在单个计算单元的Zilliz之上表现出色。对于4个计算单元，Zilliz优于MyScale，尽管MyScale具有更好的精度。

# 平均查询延迟

平均查询延迟可以定义为数据库平均返回查询结果所需的时间（时间越短越好）。MyScale在单个计算单元的Zilliz节点上表现出色。即使对于更高的计算单元，MyScale和Zilliz的查询延迟也是同一数量级的。对于16个线程，Zilliz的4个CU节点在延迟方面表现出一些改进。

平均查询延迟

# P95延迟

在P95延迟方面，我们得到了类似的结果。一旦线程超过8个，Zilliz的4个CU节点在延迟方面优于MyScale，而对于单个CU，MyScale在延迟方面优于Zilliz相当多。

P95延迟

# 数据导入时间

此基准测试仅限于单个线程，因此我们在这里只显示一个图。MyScale（此处为海绿色）在上传和构建所需的时间方面明显优于Zilliz。

数据导入时间

# 月度成本比较

对于单个计算单元，Zilliz在每月成本（每100 QPS）方面与MyScale相当，但仍然落后。而4个CU设置比MyScale要昂贵得多。

月度成本比较

TL;DR：

就每QPS的每月成本而言，MyScale为您提供了最佳的成本效益，提供了最低的每小时费用。

Join Our Newsletter

# 结论

如果您的预算充裕，Zilliz和MyScale都提供了具有竞争力的功能，使得根据特定用户需求选择其中之一变得具有挑战性。

然而，就成本效益而言，MyScale脱颖而出。虽然Zilliz的最新版本包括了多向量搜索和对稀疏向量的支持等先进功能，但这些增强功能仍处于测试阶段，并不能弥补显著的定价差距。

MyScale在付费层面提供更好的价值。此外，它还提供其他引人注目的优势，如全面的SQL支持、卓越的MSTG索引算法和更慷慨的免费层。这些因素使得MyScale成为那些同时重视性能和预算的用户更具吸引力的选择。