Version: nightly 🚧

系统要求

kumosearch 是一种内存数据存储，针对快速、低延迟的检索而优化。它将整个搜索索引存储在内存中，并在磁盘上保留原始数据的副本。

为了使用 kumosearch 获得理想的性能，选择合适的系统配置至关重要。

内存选择

kumosearch 进程本身相当轻量，在没有数据索引时仅占用约 20MB 的 RAM。所需的 RAM 量完全取决于您要索引的数据大小。

关键字搜索

如果数据集的大小（仅包括要搜索的字段）为 X MB，则通常需要 2X-3X MB 的 RAM 来索引 kumosearch 中的数据。

例如：如果数据集大小为 5GB，而您要搜索字段的子集大小为 1GB，那么您需要 2GB - 3GB 的 RAM 来存储内存中的搜索索引。

您仍然可以在 kumosearch 中存储未索引的字段（例如用于显示目的的字段），这些未索引的字段只会存储在磁盘上，不会占用 RAM。

如果数据集中有许多文档包含相似的词语（或标记），则 RAM 使用量会较低；如果多个文档包含独特的词语（或标记），则 RAM 使用量会较高。

计算记录大小

假设您有一个 JSON 文档:

{
  "album_name": "John Denver Rare and Unreleased",
  "country": "US",
  "genres": ["country"],
  "id": "31401733",
  "primary_artist_name": "John Denver",
  "release_date": 1104537600,
  "release_decade": "2010s",
  "release_group_types": [
    "Album"
  ],
  "title": "Annie's Song",
  "track_id": "58ac90d0-d6fe-4395-9e65-f714ae4c23c0",
  "urls": []
}

如果您只想搜索 album_name 和 primary_artist_name，并过滤 genres 和 release_date。计算 RAM 使用情况时，只需将这些字段的值作为一条记录的大小。

因此，即使您的文档有其他字段，如 track_id、urls、release_decade 等，因为您没有搜索它们并且可能仅将它们用于显示目的，它们不会计入 RAM 使用量。

例如，如果专辑名称平均有 100 个字符（即 100 个字节），主要艺术家姓名有 50 个字符（即 50 个字节），流派有 50 个字符（即 50 个字节），发行日期是一个整数（即 4 个字节），则平均记录大小为 100 + 50 + 50 + 4 = 204 字节 = 0.204 KB。

如果有 1M 条记录，那么数据集总大小为 0.204KB * 1M 条记录 = 204MB。因此，RAM 消耗在低端为 204MB * 2 = 408MB，在高端为 204MB * 3 = 612MB。

向量搜索

为向量搜索索引文档时，每个向量需要 7 字节内存。

因此，如果您的嵌入模型返回 N 维向量，并且您有 X 条记录，则内存消耗将为 7 字节 * N 维度 * X 记录字节。

例如，如果使用具有 384 个维度的 S-BERT 模型并且您有 100K 条记录，则内存消耗将为 7 字节 * 384 维度 * 100,000 条记录 = 268.8 MB。

语义和混合搜索

当使用带有内置 ML 模型（如 S-BERT、E-5 等）的语义/混合搜索时，kumosearch 需要将这些模型加载到内存中，除了所需的内存之外，这还需要 2GB - 6GB 的 RAM用于存储向量（如上面向量搜索部分所述）。

当使用语义/混合搜索与远程嵌入服务（如 OpenAI、PaLM API、Vertex AI 等）时，除了存储这些模型生成的向量所需的内存（如上面向量搜索部分所述）之外，kumosearch 不需要任何额外的 RAM 。

CPU容量选择

CPU 容量对处理并发搜索流量和索引操作至关重要。

::: warning 重要提示 kumosearch 需要至少 2 vCPU 的计算能力才能运行。 :::

kumosearch 设计为高度可扩展，开箱即用，无需额外配置即可自动利用所有可用的计算能力。因此，特定 CPU 配置下每秒可处理的最大请求数完全取决于您的搜索查询模式和索引数据的形状和大小。

虽然很难对理想的 CPU 容量做出准确的建议，因为这取决于您的数据，但以下一些参考数据可以让您更好地了解 CPU 容量需求：

4 vCPU kumosearch 节点能够处理 每秒 104 个并发搜索查询，数据量为 220 万条记录。
4 vCPU kumosearch 节点能够处理 每秒 46 个并发搜索查询，数据量为 2800 万条记录。
8 vCPU 3 节点 kumosearch 集群能够处理 每秒 250 个并发搜索查询，数据量为 300 万条记录。

使用 GPU（可选）

使用内置嵌入模型进行语义搜索或混合搜索时，可以通过使用 GPU 来加速嵌入生成过程。

内置模型可以仅使用 CPU 运行，但由于运行它们需要大量计算，因此在 GPU 上运行 kumosearch 时性能会有显着提高。

使用 OpenAI、PaLM API 或 Vertex AI API 等远程嵌入模型时，GPU 不是必需的，因为嵌入生成发生在这些远程服务的服务器上，而不是在 kumosearch 内部。

kumosearch 目前仅支持 Nvidia GPU。

磁盘选择

kumosearch 在磁盘上存储原始数据的副本，然后构建内存索引。在搜索时，确定要在 API 响应中返回的最终文档集后，kumosearch（仅）从磁盘获取这些文档并将它们放入 API 响应中。

您需要足够的磁盘空间（至少等于原始数据集的大小）来运行 kumosearch。 SSD 比传统硬盘快得多，推荐使用。

节点数量选择

kumosearch 可以在单节点配置中运行，也可以在高可用多节点集群配置中运行。

我们强烈建议在生产环境中使用高可用的 3 节点或 5 节点配置，以确保您的搜索服务能够应对不可避免的基础设施问题。

kumosearch 使用 Raft 作为其共识算法，由于 Raft 需要一定数量的节点才能达成共识，因此您需要运行至少 3 个节点来容忍 1 个节点的故障。运行 5 节点集群可以容忍最多 2 个节点的故障，但代价是更高的写入延迟。

内存选择​

关键字搜索​

向量搜索​

语义和混合搜索​

CPU容量选择​

使用 GPU（可选）​

磁盘选择​

节点数量选择​