集群规模
在本指南中，我们将讨论如何确定您的 Quickwit 集群和节点的规模。如 架构部分 所示，一个 Quickwit 集群有 5 个主要组件：索引器、搜索器、控制面、元存储和清洁工。每个组件有不同的资源需求并且可以独立扩展。我们还将讨论如何确定元存储 PostgreSQL 数据库的规模。
note
本指南提供了通用指导原则。实际的资源需求强烈依赖于您的工作负载。我们建议监控资源使用情况并相应地调整集群规模。
Quickwit 服务
索引器
以下是一些关于确定您的索引器节点规模的高层次指导原则：
- Quickwit 每个核心每秒可以索引大约 7.5MB 的数据
- 对于一般用例，每个核心配置 4GB 的 RAM
- 包含大量索引或数据源的工作负载会消耗更多 RAM
- 不要使用内存少于 8GB 的实例
- 将数据目录挂载到至少 110GB 的卷上，以存储 split 缓存 和 导入队列。
- 推荐使用本地 SSD 部署索引器，因为它们通常提供最佳的性能性价比并节省一些网络带宽。然而，如果使用导入 API 时每核心提供约 20 MB/s 的写入吞吐量或依赖其他来源时提供 10 MB/s 的写入吞吐量，也可以使用远程磁盘。对于 Amazon EBS 卷，这相当于每核心 320 或 160 IOPS（假设 64 KB IOPS）。
搜索器
搜索性能高度依赖于工作负载。例如，术语查询通常比聚合查询成本低。确定搜索器节点规模的一个好的起点是：
- 使用高延迟/低带宽的对象存储（如 AWS S3）时，每个核心配置 8GB 的 RAM
- 使用更快的对象存储时减少 RAM/核心的比例（例如 4GB/核心）
- 如果预计有许多并发聚合请求，则增加 RAM 配置。默认情况下，每个请求在每个节点上最多可以使用 500MB 的 RAM
- 避免使用内存少于 4GB 的实例
- 除非明确启用了 split 缓存，否则搜索器节点不会使用磁盘
Quickwit 的一个优势是其搜索器是无状态的，这使得根据工作负载轻松地扩展它们变得容易。根据以下因素来扩展搜索器节点的数量：
其他服务
控制面、元存储和清洁工都是轻量级组件。每个服务都需要 1 个副本。
控制面需要一个核心和 2GB 的 RAM。它不需要任何磁盘。
元存储也需要一个核心和 2GB 的 RAM。对于处理数百个索引的集群，您可以将其规模增加到 2 个核心和 4GB 的 RAM。它不写入磁盘。
一般来说，清洁工需要 1 个核心和 2GB 的 RAM，并且不使用磁盘。如果您使用 删除 API，则应像索引器一样确定清洁工的规模。
单节点部署
对于实验和小规模的 POC，可以在单个节点上部署所有服务（参见 教程）。我们建议至少使用 2 个核心和 8GB 的 RAM。
PostgreSQL 元存储后端
对于大多数用例，一个具有 4GB RAM 和 1 个核心的 PostgreSQL 实例就足够了：
- 使用 AWS RDS 托管服务时，请使用 t4g.medium 实例类型。启用带有 1 个备用实例的多 AZ 以实现高可用性。