在 Manticore Search 中的向量搜索：深入探讨

在 Manticore Search 中的向量搜索：深入探讨

已发布: May 20, 2025
自动翻译: Vector Search in Manticore Search: A Deep Dive

在 Manticore 中的向量搜索：详细信息
什么是嵌入（以及你为什么应该关心）？
向量搜索是如何工作的？
入门：设置向量搜索
高级搜索功能
现实世界的应用
加快向量搜索：性能技巧
保护你的向量数据安全：备份选项
保持你的搜索系统可用：复制
查看向量搜索的实际应用：现场演示
在生产中运行向量搜索
结论：向量搜索的未来

1. 在 Manticore 中的向量搜索：详细信息

如果你一直在关注我们的博客，你已经知道 Manticore Search 提供强大的向量搜索功能。在这篇文章中，我们将超越基础知识，展示它在幕后是如何工作的——以及你如何充分利用它。

在我们进入技术细节之前，快速公告：在 2025 年 6 月 6 日，Manticore 团队将赞助向量搜索大会 2025

我们将进行两场专注于现实世界向量搜索的演讲：

速度与精度的结合：向量量化如何提升搜索 — Sergey Nikolaev
RAG 时间：通过检索增强生成获得更智能的答案 — Dmitrii Kuzmenkov

如果你正在从事语义搜索、推荐或检索增强生成（RAG），这是你绝对不想错过的活动。

现在，回到主题。

Manticore 的向量搜索建立在我们的 Columnar Library 之上，它让你可以：

找到具有相似含义的内容，即使单词不同
构建感觉个性化的推荐系统
将相似项目聚集在一起，无需手动标记
提供比基本关键字匹配更相关的搜索结果

在后台，Manticore 使用一种高效的算法，称为 HNSW（层次可导航小世界）进行向量搜索。它旨在快速找到最相关的结果，即使在大型数据集中——就像在一个巨大的城市中寻找最近的邻居，但不需要地图。

让我们分解一下嵌入如何驱动这一切，以及 HNSW 如何帮助将这些嵌入转化为快速、准确的搜索结果。

2. 什么是嵌入（以及你为什么应该关心）？

要理解向量搜索，你首先需要了解嵌入。它们是这一切的核心概念。

将嵌入视为一种将事物——如单词、图像或声音——转换为表示其含义的数字列表的方法。这是一种帮助计算机“理解”世界的方式，更接近我们自己的理解方式。

嵌入是如何工作的？

想象一张巨大的地图，每个点代表一个事物：一个单词、一句话、一张图像等。两个点越接近，它们所代表的事物就越相似。这就是嵌入的作用——它们将数据转换为向量（仅仅是数字序列），使得：

将相似的事物放在这个多维空间中彼此靠近
捕捉数据背后的含义
– 这让我们可以对想法进行数学运算（还记得谷歌研究人员的著名例子吗： king – man + woman = queen ？）

多维“星系”的点

你可以将什么转化为向量？

几乎任何东西。一些常见的例子包括：

文本：单个单词、完整句子，甚至整本书。“海滩”的向量会比“山”的向量更接近“岸”。
图像：旅行照片、产品图片或表情包。狗的图片会比汽车的图片更接近。
音频：语音、音乐或音效。重金属曲目聚集在一起，远离安静的钢琴音乐。

这些嵌入是起点。一旦你拥有它们，像 HNSW 这样的算法可以帮助你快速搜索。

我们如何测量相似性？

一旦我们有了这些向量，我们需要一种方法来测量它们的相似性。Manticore Search 支持三种相似性度量：

欧几里得距离 (L2)
余弦相似性
内积（点积）

然而，重要的是要注意，相似性度量的选择并不是任意的。最佳度量通常取决于用于生成向量的嵌入模型。许多嵌入模型是针对特定相似性度量进行训练的。例如，一些模型针对余弦相似性进行了优化，而其他模型可能是为内积或欧几里得距离设计的。使用与模型训练时不同的相似性度量可能会导致次优结果。

在为向量搜索设置 Manticore Search 表时，你在表创建过程中指定相似性度量。这个选择应该与嵌入模型的特征相一致，以确保准确和高效的搜索结果。

以下是每种度量的简要概述：

欧几里得距离 (L2)：测量空间中两个向量之间的直线距离。它对向量的大小敏感，适用于绝对差异有意义的情况。
余弦相似度：测量两个向量之间角度的余弦，侧重于它们的方向而非大小。它通常用于文本分析，其中向量的方向（代表概念）比其长度更重要。
内积（点积）：计算两个数字序列对应条目的乘积之和。当向量的大小和方向都很重要时，它是有效的。

这些向量是如何创建的？

要使用向量搜索，您首先需要将数据转换为向量——这就是嵌入模型的作用。这些模型将原始数据（如文本、图像或音频）转换为捕捉意义、上下文或特征的数值表示。

以下是一些广泛使用的生成嵌入的模型：

Word2Vec：最早的词嵌入模型之一。它帮助展示了单词之间的关系可以通过数学方式捕捉——例如“国王”与“女王”的关系就像“男人”与“女人”的关系。
GloVe：由斯坦福大学开发，该模型通过分析全局单词共现统计数据来创建词嵌入。它高效且仍被广泛使用。
FastText：来自Facebook，该模型通过理解子词信息来改进Word2Vec。它可以通过将未见过的单词拆分成片段来生成嵌入。
BERT：来自Google的基于变换器的模型，能够理解上下文中的单词。例如，它区分“河岸”中的“银行”和“银行账户”中的“银行”。它可以为句子、段落或整个文档生成嵌入。
MPNet / MiniLM / all-MiniLM-L6-v2：这些是来自SentenceTransformers家族的优化句子嵌入模型，适合语义搜索、FAQ匹配和重复检测等任务。
OpenAI嵌入（例如，text-embedding-3-small）：这些是用于搜索、聚类和分类等应用的高度通用嵌入。
CLIP：OpenAI的一个模型，能够在同一空间中理解图像和文本。给它一张小狗的照片，它可以将其与“可爱的小狗”这段文本匹配。
ResNet：一种深度卷积神经网络，擅长将图像转换为嵌入。通常用于视觉相似性和图像分类。
VGG / EfficientNet / 视觉变换器（ViT）：其他强大的图像模型，广泛用于将图片转换为向量嵌入。
Whisper：OpenAI的模型，用于将音频转录为文本，然后可以嵌入以进行语音搜索或音频分类等任务。

Manticore Search与所有这些模型及更多模型兼容。它不会将您锁定在特定模型中——您可以使用最适合您项目的模型，无论您是在处理文本、图像还是音频。只要您能够将数据转换为向量，Manticore就可以对其进行搜索。

3. 向量搜索是如何工作的？

现在我们已经讨论了嵌入是什么以及它们如何表示相似性，让我们看看Manticore实际上是如何执行向量搜索的。真正的幕后力量来自一个聪明的算法，称为HNSW——即层次可导航小世界的缩写。

是的，这听起来像是科幻小说中的东西——老实说，确实有点像。但HNSW并不是引导宇宙飞船穿越虫洞，而是帮助我们快速导航大量的向量集合。

HNSW：这个名字糟糕的算法

在一个巨大的向量索引中搜索有点像在干草堆中寻找针——只是干草堆里有数百万根稻草，其中一些看起来与针非常相似。如果您必须逐个检查，那将需要永远。

这就是HNSW的用武之地。它构建了一个巧妙的结构，以便您可以快速跳过大部分干草堆，迅速锁定最佳候选项。

它的工作原理如下：

它创建了几层向量——有点像多层建筑或分层蛋糕。
底层包含每一个向量——您的完整数据集。
每个高层有更少的向量和更长的链接。
当您搜索时，它从顶层开始，这有助于您快速跳过数据。
在每个层级，它逐渐接近正确的区域，随着向下的搜索不断细化。
当它到达底层时，已经在正确的邻域中。

这种分层方法意味着您可以避免扫描整个数据集。相反，您可以快速放大——这使得Manticore中的向量搜索超级高效。

但准确性如何？

有一个小的权衡。由于HNSW在搜索过程中跳过了很多数据，因此有可能找不到绝对最佳匹配——只是一个非常好的匹配。在大多数现实场景中，这完全没问题。无论您是在进行语义搜索、产品推荐还是聚类相似文档，“非常接近”已经足够好。

但如果您的用例要求100%的精确度——例如匹配DNA序列或进行科学分析——您可能需要一种暴力方法。它会更慢，但绝对准确。

对于其他所有情况，HNSW为您提供了两全其美的选择：闪电般的速度与高准确性。

HNSW算法结构

HNSW架构

根据您的喜好进行调整

Manticore中的向量搜索不仅快速——而且灵活。您可以调整几个关键设置，以更好地适应您的特定用例，具体取决于您最关心的是什么：速度、准确性、内存使用或索引构建时间。

以下是您可以调整的主要参数：

hnsw_m（默认值：16）：这控制每个向量与其他向量之间的连接数量——有点像每个人在社交网络中有多少个朋友。更多的连接意味着更好的搜索准确性，但也意味着更多的内存使用和稍慢的查询。
hnsw_ef_construction (默认值: 200): 此设置影响索引构建的彻底程度。更高的值会导致更好的质量（因此更好的搜索结果），但也会使索引过程变得更慢且更占用内存。

这两个参数让您找到以下之间的正确平衡：

🔍 搜索准确性 — 结果与真实最近邻的接近程度
⚡ 搜索速度 — 结果返回的速度
🧠 内存使用 — 索引消耗的内存
🏗️ 索引时间 — 构建索引所需的时间

默认设置适用于大多数用例，但如果您想调整，以下是一些提示：

想要超准确的结果？ 增加 hnsw_m 和 hnsw_ef_construction
内存紧张？ 降低 hnsw_m 以减少连接
需要更快的索引？ 降低 hnsw_ef_construction

随意尝试 — 关键是找到适合您工作负载的最佳平衡点。

4. 开始使用：设置向量搜索

理解理论很好 — 但现在让我们动手。在 Manticore 中设置向量搜索简单灵活，您可以在几步之内启动并运行。

您需要的东西

要启用向量搜索，您需要定义一个至少包含一个 float_vector 属性的表。这是您的向量 — 实际的嵌入 — 将被存储的地方。

需要定义的关键设置

创建表时，您需要设置三个基本参数：

knn_type: 将其设置为 hnsw。（目前这是唯一支持的选项，因此这里没有决策要做。）
knn_dims: 这定义了您的向量的维度数量。该值取决于您使用的嵌入模型：
- BERT 通常使用 768
- CLIP 通常使用 512
- 一些句子变换器使用 384 或 1024
- 只需确保它与您将要插入的向量的大小匹配
hnsw_similarity: 选择与您的嵌入模型训练方式相匹配的相似性度量。选项包括：
- L2 (欧几里得距离): 用于几何数据、图像特征以及任何物理距离重要的情况
- COSINE: 最适合文本嵌入、语义搜索，以及当您关心方向而不是大小时
- IP (内积): 适用于归一化向量或像推荐这样的用例，其中大小和方向都很重要

🔍 专业提示: 大多数现代文本嵌入模型都是以余弦相似度为基础进行训练的。如果您不确定，请查看模型文档 — 或者直接从 COSINE 开始并进行实验。

一旦您使用这些设置定义了表，您就可以插入向量并开始进行快速的基于相似性的搜索。

向量搜索工作流程

让我们看看一个真实的例子

是时候动手了。以下是您如何在 Manticore Search 中创建一个表以存储图像向量：

create table cool_images (
    id int,
    title text,
    image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2'
);

现在让我们添加一些数据：

insert into cool_images values 
    (1, 'yellow bag', (0.653448,0.192478,0.017971,0.339821)),
    (2, 'white bag', (-0.148894,0.748278,0.091892,-0.095406));

（当然，您的真实向量可能有数百个维度 — 为了清晰起见，我们在这里保持较小。）

向量操作的事务支持

Manticore 中的向量操作是完全事务性的，这意味着您可以连续执行多个操作，并确保它们要么全部成功，要么全部失败。当您需要同时更新向量和非向量字段并保持所有内容同步时，这非常有用。

事务基础

事务支持具有向量属性的实时表
每个事务是原子的 - 要么所有操作成功，要么都不成功
事务与二进制日志集成，以确保持久性和一致性
默认情况下，每个命令都是其自己的迷你事务（autocommit = 1）

您可以在事务中执行的操作

您可以在事务中包含以下操作：

INSERT: 添加新向量
REPLACE: 更新现有向量
DELETE: 删除向量

向量字段不支持 UPDATE 命令。您可以在这里了解 REPLACE 和 UPDATE 之间的区别。

如何控制事务

您可以通过两种方式控制事务：

自动模式（默认）：

SET AUTOCOMMIT = 1

在此模式下，每个操作会自动提交。

手动模式：

SET AUTOCOMMIT = 0

这允许您将多个操作分组为一个事务：

BEGIN;
INSERT INTO cool_images VALUES (3, 'red bag', (0.1, 0.2, 0.3, 0.4));
INSERT INTO cool_images VALUES (4, 'blue bag', (0.5, 0.6, 0.7, 0.8));
COMMIT;

批量操作

对于批量操作，您可以使用支持多个向量操作事务的 /bulk 端点：

POST /bulk
{
    "insert": {"table": "cool_images", "id": 5, "doc": {"title": "green bag", "image_vector": [0.1, 0.2, 0.3, 0.4]}},
    "insert": {"table": "cool_images", "id": 6, "doc": {"title": "purple bag", "image_vector": [0.5, 0.6, 0.7, 0.8]}}
}

需要记住的注意事项

事务仅限于单个实时表
事务中的向量操作是原子且一致的
更改在明确提交之前不可见
二进制日志确保向量操作的持久性
当您需要在向量数据和其他属性之间保持一致性时，事务特别有用

搜索相似内容

现在是有趣的部分——搜索相似的图像：

使用 SQL：

select id, title, knn_dist() 
from cool_images 
where knn (image_vector, 5, (0.286569,-0.031816,0.066684,0.032926), 2000);

这给我们：

+------+------------+------------+
| id   | title      | knn_dist() |
+------+------------+------------+
|    1 | yellow bag | 0.28146550 |
|    2 | white bag  | 0.81527930 |
+------+------------+------------+

黄色的包更接近我们的查询向量（距离值更小），因此它更类似于我们要寻找的内容。

使用 HTTP API：

Manticore 提供了一个用于向量搜索操作的 RESTful HTTP API。向量搜索的主要端点是：

POST /search

请求体应为 JSON 格式，具有以下结构：

{
    "table": "<table_name>",
    "knn": {
        "field": "<vector_field_name>",
        "query_vector": [<vector_values>],
        "k": <number_of_results>,
        "ef": <search_accuracy>
    }
}

关键参数：

table: 要搜索的表的名称
knn.field: 要搜索的向量字段的名称
knn.query_vector: 作为浮点值数组的查询向量
knn.k: 要返回的最近邻数量
knn.ef: （可选）搜索期间使用的动态列表的大小。更高的值提供更准确但更慢的结果

示例请求：

POST /search
{
    "table": "products",
    "knn": {
        "field": "image_vector",
        "query_vector": [0.1, 0.2, 0.3, 0.4],
        "k": 5,
        "ef": 2000
    }
}

响应将为 JSON 格式：

{
    "took": 6,
    "timed_out": false,
    "hits": {
        "total": 2,
        "total_relation": "eq",
        "hits": [
            {
                "_id": 1,
                "_score": 1,
                "_knn_dist": 0.28146550,
                "_source": {
                    "title": "yellow bag",
                    "image_vector": [0.653448, 0.192478, 0.017971, 0.339821]
                }
            },
            {
                "_id": 2,
                "_score": 1,
                "_knn_dist": 0.81527930,
                "_source": {
                    "title": "white bag",
                    "image_vector": [-0.148894, 0.748278, 0.091892, -0.095406]
                }
            }
        ]
    }
}

响应包括：

took: 搜索所用的时间（以毫秒为单位）
timed_out: 搜索是否超时
hits.total: 找到的匹配总数
hits.hits: 匹配文档的数组，每个文档包含：
- _id: 文档 ID
- _score: 搜索分数（对于 KNN 搜索始终为 1）
- _knn_dist: 到查询向量的距离
- _source: 原始文档数据

您还可以将 KNN 搜索与其他过滤器结合使用：

POST /search
{
    "table": "products",
    "knn": {
        "field": "image_vector",
        "query_vector": [0.1, 0.2, 0.3, 0.4],
        "k": 5,
        "filter": {
            "bool": {
                "must": [
                    { "match": {"_all": "white"} },
                    { "range": { "id": { "lt": 10 } } }
                ]
            }
        }
    }
}

我找到了

5. 高级搜索功能

在掌握了基本的设置和配置后，让我们探索向量搜索为您的应用程序带来的强大功能。这些功能远远超出了传统的关键词搜索。

两种搜索方式

您可以通过两种主要方式进行搜索：

直接向量搜索：给我与这个向量相似的东西。当您拥有想要的内容的向量表示（如图像嵌入或文本嵌入）时，这种方式非常有效。
```
-- 示例：查找与特定向量相似的项目
SELECT id, knn_dist() 
FROM products 
WHERE knn(image_vector, 5, (0.286569,-0.031816,0.066684,0.032926));
```
相似文档搜索：给我与我索引中的这个文档相似的东西。非常适合“更多类似于此”的功能，用户可以点击他们喜欢的内容并找到相似的项目。
```
-- 示例：查找与 ID 为 1 的文档相似的项目
SELECT id, knn_dist() 
FROM products 
WHERE knn(image_vector, 5, 1);
```

这两种方法返回的结果按与您的查询的相似性（距离）排序，最相似的项目首先出现。

微调您的搜索

有两个重要设置控制您的搜索行为：

k 参数：您希望返回多少结果。太少可能会错过好的匹配。太多可能会得到无关的内容。
ef 参数：算法尝试找到最佳匹配的难度。更高的值会提供更准确的结果，但需要更长的时间。

结果按接近度排序

所有搜索结果自动按与您的查询向量的接近程度排序。knn_dist() 函数显示每个结果的实际距离值，因此您可以看到它们有多相似（或不同）。

例如，如果我们搜索与查询向量相似的图像：

select id, title, knn_dist() 
from images 
where knn (image_vector, 3, (0.1, 0.2, 0.3, 0.4));

结果将自动按距离排序，最近的匹配项首先出现：

+------+----------------+------------+
| id   | title          | knn_dist() |
+------+----------------+------------+
|    1 | sunset beach   | 0.12345678 |
|    3 | ocean view     | 0.23456789 |
|    2 | mountain lake  | 0.34567890 |
+------+----------------+------------+

注意 knn_dist() 值在列表中向下增加 - 这表明每个结果与我们的查询向量逐渐不那么相似。

与常规搜索混合搭配

真正的魔力发生在您将向量搜索与传统过滤器结合时。例如，您可以找到与向量相似的图像，同时匹配文本：

select id, title, knn_dist() 
from cool_images 
where knn (image_vector, 5, (0.286569,-0.031816,0.066684,0.032926)) 
and match('white');

这会找到与我们的向量相似的图像，但仅当它们包含“白色”时：

+------+-----------+------------+
| id   | title     | knn_dist() |
+------+-----------+------------+
|    2 | white bag | 0.81527930 |
+------+-----------+------------+

尽管黄色包在技术上更相似（向量方面），但它没有匹配我们的文本过滤器，因此只有白色包出现。

6. 现实世界应用

现在我们已经涵盖了核心功能，让我们看看一些现实世界的应用，向量搜索如何改变您的用户体验。这些示例将帮助您理解如何在自己的项目中应用这些概念。

理解您意思的智能搜索

这不是我想要的

您是否曾经搜索某个东西并想“这不是我想要的！”？智能搜索理解您查询背后的含义，而不仅仅是确切的词语。

通过向量搜索，您可以：

找到与您所寻找的内容匹配的结果，即使它们使用不同的词语
跨语言搜索（意思被翻译，而不仅仅是词语）
实际理解用户在寻找什么

现实世界示例：一个知识库，客户即使使用与您的文档不同的术语，也能找到正确的帮助文章。

合理的推荐系统

我们看到您昨天买了一个冰箱。再来5个怎么样？

我们都经历过糟糕的推荐：“您买了一个冰箱，您想再要一个冰箱吗？”向量搜索有助于构建合理的推荐：

找到与客户喜欢的产品相似的产品
匹配用户偏好与商品
根据潜在属性跨类别推荐
根据浏览历史个性化搜索结果

现实世界示例：一个电子商务网站，在您查看蓝色皮革包后，可以推荐一件蓝色皮革夹克，因为它理解风格之间的联系。

像您一样看待的图像搜索

传统的图像搜索依赖于文本标签和元数据。向量搜索让您：

找到看起来相似的图像
上传一张图像并找到匹配的图像（反向图像搜索）
在没有手动标记的情况下对相似图像进行分组
检测重复或近似重复的图像

现实世界示例：一个库存照片网站，设计师可以通过上传参考图像或概念草图找到视觉上相似的图像。

超越标签的视频和音频搜索

将相同的原则应用于视频和音频：

根据内容查找相似的视频片段
按“听起来像这个”而不仅仅是按流派标签搜索音乐
在视频中查找具有相似视觉元素的时刻
检测重复或相似的音轨

现实世界示例：一个视频编辑平台，可以立即找到您所有项目中具有相似视觉构图的所有片段。

跨不同语言的搜索

当涉及多语言应用时，向量搜索真正闪耀。通过正确的嵌入，您可以跨不同语言进行搜索——无需手动翻译查询或文档。

跨语言搜索的工作原理

语言无关的嵌入
现代多语言模型如 mBERT、XLM-R 和 LaBSE 被训练以将语义上相似的文本——即使在不同语言中——放置在同一向量空间中靠近在一起。
这意味着英语中的“apple”和西班牙语中的“manzana”最终会靠近在一起。因此，当您用一种语言搜索时，可以找到用另一种语言写的结果。

简单表格设置

create table multilingual_docs (
    id bigint,
    content text,
    language string,
    content_vector float_vector knn_type='hnsw' knn_dims='768' hnsw_similarity='cosine'
);

以原始语言存储文档
使用多语言模型生成嵌入
搜索正常工作 — 无论查询或文档使用何种语言

跨语言搜索：

select id, content, language, knn_dist() 
from multilingual_docs 
where knn (content_vector, 5, (0.1, 0.2, ...));

以任何支持的语言输入查询
结果基于意义返回，而不是语言
无需翻译或语言检测

现实世界应用

多语言向量搜索解锁了广泛的全球用例，例如：

全球电子商务：跨语言搜索和推荐产品，并支持国际客户查询
内容管理：查找相似文档，检测重复，并构建多语言知识库
客户支持：跨语言匹配问题与答案，并智能路由支持工单
社交媒体与社区：跨语言边界发现内容、趋势和用户

通过正确的多语言嵌入，您可以构建无缝的搜索体验 — 无论用户说什么语言。

实施建议

选择合适的模型
根据您的语言需求和任务选择多语言嵌入模型，如 LaBSE、XLM-R 或 mBERT。确保您使用的模型支持您在查询和文档中预期的语言。
深思熟虑地预处理
在生成嵌入之前，确保在不同语言中一致地规范化和清理输入文本。即使是小的预处理差异（如标点或大小写）也会影响向量质量。
存储语言信息
在您的数据中保留一个 language 字段。虽然向量搜索不需要它，但它可以帮助过滤、分析或改善用户体验。
设计清晰
在搜索结果中显示语言信息，并允许用户轻松过滤或切换语言 — 尤其是当您的应用混合多种语言时。

有了这些，您将准备好构建自然跨语言工作的搜索功能 — 无需翻译层。

7. 使向量搜索快速：性能提示

构建酷炫的功能很好，但它们在生产中需要良好的性能。让我们深入探讨性能考虑和优化策略，以确保您的向量搜索实现顺利运行。

理解 RAM 与磁盘存储

在 Manticore 中，向量搜索的工作方式取决于您的向量是存储在 RAM 块还是磁盘块中：

磁盘块：
- 每个磁盘块维护其独立的 HNSW 索引
- 对于跨多个磁盘块的 KNN 查询，分别搜索每个块的索引
- 这可能会影响搜索准确性，因为每个块的 HNSW 图仅限于该块内的向量
- 当跨多个磁盘块搜索时，查询性能可能会较慢
- 对于具有向量属性的表，Manticore 会自动设置较低的 optimize_cutoff 值（物理 CPU 核心除以 2），以提高向量搜索性能
RAM 块：
- 对向量使用更直接的搜索方法
- 对于最近添加的数据可能提供更快的结果
- 随着 RAM 块的增长，向量搜索性能可能会逐渐下降
- 每个 RAM 块在达到 rt_mem_limit（默认 128M）定义的大小限制时，最终会变成磁盘块，或者当您使用 FLUSH RAMCHUNK 显式转换时

为了获得最佳的向量搜索性能，请考虑：

使用批量插入以最小化 RAM 块段的碎片
利用 Manticore 的 auto-optimize 功能，该功能会自动合并磁盘块以保持最佳性能
根据您的特定工作负载和 CPU 资源调整 optimize_cutoff
使用 diskchunk_flush_write_timeout 和 diskchunk_flush_search_timeout 设置来控制自动刷新行为

跨磁盘块的向量搜索性能取决于块的数量及其分布。较少的磁盘块通常会提供比许多小块更好的 KNN 搜索性能。

理解 `ef` 参数

ef 参数允许您在速度和准确性之间取得平衡：

它的作用：
- 较高的值提供更准确的结果，但需要更长时间
- 较低的值更快，但可能会错过一些好的匹配
找到最佳平衡点：
- 从默认值（200）开始
- 如果准确性至关重要，则增加
- 如果速度至关重要，则减少
- 使用您的实际数据进行测试！

8. 保护您的向量数据安全：备份选项

随着您的向量搜索实现的增长，确保数据安全变得至关重要。让我们探讨专门为 Manticore 中的向量数据设计的备份策略。

物理备份

物理备份特别适合向量数据，因为：

速度：它们直接复制原始向量数据文件，这对大型向量数据集至关重要
一致性：它们确保所有向量数据和 HNSW 索引一起备份
较低的系统负载：它们不需要额外处理向量数据

您可以使用以下任一工具：

manticore-backup 命令行工具：

manticore-backup --backup-dir=/path/to/backup --tables=your_vector_table

SQL BACKUP 命令：

BACKUP TABLE your_vector_table TO /path/to/backup

逻辑备份

当您需要以下内容时，逻辑备份对向量数据可能很有用：

可移植性：在不同系统之间移动向量数据
选择性恢复：恢复特定的向量属性或维度
版本迁移：在不同的 Manticore 版本之间切换。较新的版本通常支持向后兼容，因此在升级时您可能不需要使用数据转储。然而，如果您降级到较旧的版本，使用数据转储可能会很有用。

您可以使用 mysqldump 进行向量数据的逻辑备份：

mysqldump -h0 -P9306 -e "SELECT * FROM your_vector_table" > vector_backup.sql

向量数据备份的最佳实践

就像其他类型的备份一样，在备份您的向量数据时，有一些好的实践需要遵循。

定期备份：
- 设置定期备份，特别是在对您的向量数据进行重大更新后
- 在决定备份频率时考虑您的向量数据的大小
备份位置：
- 将备份保存在有足够空间存放大型向量数据的地方
- 如果您的向量数据非常大，请使用压缩
测试：
- 定期测试您的备份，以确保它们可以恢复
- 恢复后，检查向量搜索是否仍然正常工作
版本控制：
- 保留您正在使用的 Manticore 版本的记录
- 确保您的备份在需要恢复时可以与该版本兼容
监控：
- 关注备份的大小和所需时间
- 设置警报以防任何备份失败

9. 保持您的搜索系统可用：复制

除了备份，高可用性对于生产系统至关重要。让我们来看看 Manticore 的复制功能如何与向量搜索配合工作，以确保您的系统保持可用和一致。

多主复制

Manticore 支持 Galera 库进行复制，并提供几个关键特性：

真正的多主：可以在任何节点上随时执行读写操作
几乎同步：没有从属延迟，节点崩溃后没有数据丢失
热备份：在故障转移场景中零停机时间
紧密耦合：所有节点保持相同状态，没有数据分歧
自动节点配置：新节点无需手动备份/恢复
基于认证的复制：确保集群中的数据一致性

为向量搜索设置复制

要为向量搜索启用复制：

配置要求：
- data_dir 选项在 searchd 配置中默认设置
- 带有可访问 IP 地址的 listen 指令是可选的 - 复制在没有它的情况下也能工作
- 可选地为每个节点设置唯一的 server_id 值
创建复制集群：
```
CREATE CLUSTER vector_cluster
```

将向量表添加到集群：

ALTER CLUSTER vector_cluster ADD vector_table

将节点加入集群：

JOIN CLUSTER vector_cluster AT 'host:port'

在复制环境中处理向量数据时：

写操作：
- 所有向量修改（INSERT、REPLACE、DELETE、TRUNCATE）必须使用 cluster_name:table_name 语法
- 更改会自动传播到所有副本
- 向量操作在集群中保持一致性
事务支持：
- 向量操作在集群中是原子的
- 更改在明确提交之前不可见
- 二进制日志确保向量操作的持久性

限制和注意事项

复制支持具有向量属性的实时表
Windows 原生二进制不支持复制（请使用 WSL）
macOS 的复制支持有限（仅推荐用于开发）
每个表只能属于一个集群

10. 观看向量搜索的实际应用：现场演示

理论和配置很重要，但眼见为实。让我们探索一些真实世界的演示，展示 Manticore 的向量搜索能力的强大。

GitHub 问题搜索

我们的 GitHub 问题搜索演示让您可以通过理解单词背后的含义来搜索 GitHub 问题。与仅匹配关键字的 GitHub 原生搜索不同，我们的演示理解您在寻找什么。

此演示基于 Manticore Search 的向量能力，完全开源。您可以在 GitHub 上查看源代码，了解我们是如何实现的。

尝试搜索概念而不仅仅是关键字 - 即使确切的单词不匹配，搜索也能理解您在寻找什么！

GitHub 问题演示的工作原理

GitHub 问题搜索演示使用强大的嵌入模型将 GitHub 问题和您的搜索查询转换为语义向量表示。这使得系统能够找到与您的查询在概念上相似的问题，即使它们使用不同的术语。

关键特性：

在数千个 GitHub 问题中智能搜索
按存储库、标签等实时过滤
具有语法高亮的用户友好界面
由 Manticore 的 HNSW 算法提供快速响应时间

这种方法显著提高了搜索质量，相较于传统的基于关键字的搜索，帮助开发人员更高效地找到解决方案。

图像搜索演示

我们的图像搜索演示展示了向量搜索如何驱动视觉相似性搜索。上传任何图像，系统将根据图片中的实际内容找到视觉上相似的图像，而不仅仅是标签或元数据。

此演示使用机器学习模型将图像转换为向量，然后使用 Manticore 的 KNN 搜索找到相似图像。源代码可在我们的 manticore-image-search 仓库中找到。

图像搜索演示的工作原理

The Image Search demo leverages a pre-trained vision model to extract meaningful features from images and represent them as high-dimensional vectors. When you upload an image or select one from the gallery:

The image is processed by the vision model to generate a feature vector
Manticore's vector search finds the nearest neighbors to this vector
The most similar images are returned, ranked by their similarity score
All of this happens in milliseconds, providing a smooth user experience

The demo handles a diverse range of image types and can find similarities based on content, style, color patterns, and even abstract concepts present in the images.

Create Your Own Demo

Both demos are excellent starting points for building your own vector search applications. Whether you're interested in:

Smart document search
Image or video retrieval systems
Recommendation engines
Content classification

You can leverage the same architecture and adapt it to your specific use case. The source code for both demos provides practical examples of how to:

Generate embeddings for your data
Structure your Manticore tables for vector search
Implement efficient search APIs
Build user-friendly interfaces

These demos demonstrate how vector search can be applied to real-world problems with impressive results. They're also fully open source, so you can learn from them or even deploy your own version!

By tweaking these settings, you can make vector search lightning-fast for your specific needs. Remember, the right configuration depends on your data, your hardware, and what you're trying to accomplish. Don't be afraid to experiment!

11. Running Vector Search in Production

After exploring all these features and capabilities, it's time to discuss what it takes to deploy vector search in a production environment. Let's cover the critical factors that will ensure your implementation is reliable, scalable, and performs optimally.

What You Need: Infrastructure Requirements

Hardware Considerations:
- CPU: Vector operations are CPU-intensive
  - Modern multi-core processors recommended
  - Consider CPU cache size for vector operations
  - Monitor CPU utilization during peak loads
- Memory:
  - HNSW indexes require significant RAM
  - Plan for 2-3x the size of your vector data
  - Consider memory fragmentation over time
- Storage:
  - Fast SSDs recommended for disk chunks
  - Consider RAID configurations for reliability
  - Plan for backup storage requirements
Network Configuration:
- High bandwidth for replication
- Low latency for distributed setups
- Proper firewall rules for cluster communication
- Load balancer configuration for high availability

12. Conclusion: The Future of Vector Search

Vector search represents a fundamental shift in how we approach search and similarity matching in modern applications. Throughout this deep dive, we've explored how Manticore Search implements this powerful technology, from the underlying concepts of embeddings to production-ready deployment strategies.

Key takeaways from our exploration:

Powerful Capabilities: Vector search enables understanding the meaning behind the words, going beyond traditional keyword matching to find truly relevant results based on meaning and context.
Flexible Implementation: Manticore's vector search can be applied to various use cases, from text search to image matching, recommendations, and multilingual applications.
Production-Ready: With features like replication, backup options, and performance optimization, Manticore's vector search is ready for enterprise deployment.
Easy to Get Started: Despite its sophisticated capabilities, vector search in Manticore is accessible and can be implemented with minimal configuration.

As we look to the future, vector search will continue to evolve and become even more integral to modern applications. The ability to understand and match content based on meaning rather than just keywords is transforming how users interact with data. Whether you're building a search engine, recommendation system, or content discovery platform, vector search provides the foundation for creating more intelligent and user-friendly applications.

To get started with vector search in your own projects, check out our GitHub repository and join our community . We're excited to see what you'll build with Manticore's vector search capabilities!

Remember: The best way to understand the power of vector search is to try it yourself. Start with our demos and experiment with your own use cases. The possibilities are endless, and we're here to help you explore them.