介绍
Elastic Cloud Serverless 的出现改变了企业使用 Elasticsearch 的方式，不再需要管理集群、节点或资源扩展。Elastic Cloud Serverless 的一个关键创新是其自动扩展功能，它能够实时适应工作负载和流量的变化。这篇文章将探讨自动扩展的技术细节、Elastic Cloud Serverless 在负载下的性能，以及广泛压力测试的结果。
什么是 Elastic Cloud Serverless？
Elastic Cloud Serverless 提供了一个自动化的、托管版的 Elasticsearch，根据需求进行扩展。不同于传统的 Elasticsearch 部署，用户必须配置和管理硬件或云实例，Elastic Cloud Serverless 负责基础设施扩展和资源分配。这对具有可变工作负载的组织特别有利，因为手动扩展基础设施既麻烦又容易出错。系统内置的自动扩展功能可以在没有人工干预的情况下处理大量的写入任务、搜索查询和其他操作。
Elastic Cloud Serverless 包含两个不同的层次：搜索层和索引层，每个层次都针对特定的工作负载进行了优化。搜索层专门处理查询执行，确保搜索请求的快速高效响应。而索引层则负责数据的写入和处理，管理写操作，确保数据被正确存储并可搜索。通过将这些任务分开，Elastic Cloud Serverless 允许每个层次根据工作负载的需求独立扩展。这种分离提高了资源效率，因为用于高吞吐量写入的计算和存储需求不会影响搜索操作期间的查询性能。同样，搜索层资源可以扩展以处理复杂查询或流量激增，而不会影响写入过程。这种架构确保了最佳性能、成本效益和弹性，使 Elastic Cloud Serverless 能够在保持一致用户体验的同时动态适应波动的工作负载。
您可以在以下 博客文章[1] 中了解更多有关 Elastic Cloud Serverless 架构的信息。
Elastic Cloud Serverless 的压力测试
我们进行了全面的压力测试，以评估 Elastic Cloud Serverless 处理大规模波动工作负载的能力。这些测试旨在衡量系统在极端条件下的数据写入、搜索查询和性能维持能力。需要注意的是，系统的性能可能超出我们在这里展示的结果，这取决于客户端数量和批量索引大小等因素。下面，我们将介绍这些测试的方法和发现。
测试范围和方法
我们的压力测试主要目标是回答以下关键问题：
• Elastic Cloud Serverless 如何应对大量数据写入和高并发客户端搜索查询？
• 它能否动态扩展以适应突发的工作负载激增？
• 系统在长时间内能否保持稳定？
搜索用例的压力测试
在 Elastic Cloud Serverless 中，您可以选择三种项目类型：Elasticsearch、Observability 和 Security。我们首先在 Elasticsearch 的搜索用例上进行压力测试，使用 GitHub Archive 数据集并模拟可能的写入和搜索行为。测试前，我们通过 DataStreams 使用 Bulk APIs 预先写入了 186GB 4300万文档 的基础数据，然后在十分钟内逐渐增加客户端数量，以便 Elasticsearch 有时间适当扩展。
索引层的压力测试
首先，让我们谈谈数据写入（ingest）。Elastic Cloud Serverless 中的写入自动扩展功能会根据数据写入需求动态调整资源，确保最佳性能和成本效益。系统会持续监控指标，如写入吞吐量、资源利用率（CPU、内存和网络）以及响应延迟。当这些指标超过预定阈值时，自动扩展器会按比例增加容量，以应对当前和预期的需求，同时为意外激增保留缓冲。数据管道的复杂性和系统施加的资源限制也会影响扩展决策。通过动态添加或删除容量，写入自动扩展确保无缝扩展，无需人工干预。
在像 Elastic Cloud Serverless 这样的自动扩展系统中，资源效率得到优化，但在某些情况下，突然的大量工作负载可能会超出系统立即扩展的能力。在这种情况下，客户端可能会收到 HTTP 429 状态码，表示系统负载过重。为应对这些情况，客户端应实施指数退避策略，逐渐延长重试请求的间隔。在压力测试期间，我们积极跟踪 429 响应，以评估系统在高需求下的反应，提供关于自动扩展有效性的重要见解。您可以在这篇 博客文章[2] 中详细了解我们如何自动扩展写入。现在，让我们看看我们在索引层压力测试中遇到的一些结果。
扩展中的索引：
| 数据集 | 批量大小 | 实际容量 | 索引时间（分钟） | 每小时容量 | 中位吞吐量（文档/秒） | 90百分位索引延迟（秒） | 平均错误率（429及其他） |
| 1TB | 2500 | 1117.43 GB | 63 | 1064.22 GB | 70,256.96 | 7.095 | 0.05% |
| 2TB | 2500 | 2162.02 GB | 122 | 1063.29 GB | 68,365.23 | 8.148 | 0.05% |
| 5TB | 2500 | 5254.84 GB | 272 | 1159.16 GB | 74,770.27 | 7.46 | 0 |
在初始测试中，我们在 1TB 和 2TB 数据集上分别达到了 1064 GB/小时 和 1063 GB/小时 的吞吐量。在 5TB 数据集上，我们达到了 1160 GB/小时 的更高吞吐量，因为写入层继续扩展，提供了更好的吞吐量。
完全扩展的索引：
| 客户端 | 批量大小 | 实际容量 | 持续时间 | 每小时容量 | 中位吞吐量（文档/秒） | 99百分位索引延迟（秒） | 平均错误率（429及其他） |
| 3,000 | 2,000 | 1 TB | 8 分钟 | 7.5 TB | 499,000 | 33.5 | 0.0% |
在完全扩展的索引层上，Elastic Cloud Serverless 在 8 分钟 内写入了 1TB 数据，写入速度为 ~499K 文档/秒。这相当于每天 180TB 的写入能力。
从最小规模到最大规模的索引：
| 客户端 | 批量大小 | 实际容量 | 持续时间 | 每小时容量 | 中位吞吐量（文档/秒） | 99百分位索引延迟（秒） | 平均错误率（429及其他） |
| 2,048 | 1,000 | 13 TB | 6 小时 | 2.1 TB | 146,478 | 55.5 | 1.55% |
在 2TB 数据 的测试中，我们逐步扩展到 2048 客户端，并以 146K 文档/秒 的速度完成了 2TB 数据的写入，耗时 1 小时。按此计算，每天可写入 48TB 数据。
72小时稳定性测试：
| 客户端 | 批量大小 | 实际容量 | 索引时间（小时） | 每小时容量 | 中位吞吐量（文档/秒） | 99百分位索引延迟（秒） | 平均错误率（429及其他） |
| 128 | 500 | 61 TB | 72 | ~868.6 GB | 51,700 | 7.7 | <0.05% |
在 72小时稳定性测试 中，我们使用 128 客户端 写入了 60TB 数据。Elastic Cloud Serverless 保持了 870GB/小时 的吞吐量，并且错误率极低，同时扩展了索引和搜索层。这展示了 Elasticsearch 在长时间内保持高吞吐量和低故障率的能力。
搜索层的压力测试
Elastic Cloud Serverless 中的搜索层自动扩展功能会根据数据集大小和搜索负载动态调整资源，以保持最佳性能。系统将数据分类为两类：增强数据和非增强数据。增强数据包括在用户定义的增强窗口内的时间序列文档（具有 @timestamp
字段）和所有非时间序列文档，而非增强数据则在此窗口之外。用户可以设置增强窗口来定义增强数据的时间范围，并选择搜索能力级别（按需、性能或高吞吐量）来控制资源分配。您可以在 这里[3] 阅读更多关于配置搜索能力和搜索增强窗口的信息。
自动扩展器会监控指标，如查询延迟、资源利用率（CPU 和内存）以及查询队列长度。当这些指标显示需求增加时，系统会相应地扩展资源。此扩展是按项目进行的，对最终用户透明。
负载下的搜索稳定性：
| 数据集 | 实际容量 | 持续时间 | 平均搜索速率（请求/秒） | 最大搜索速率（请求/秒） | 响应时间（P50） | 响应时间（P99） |
| 5TB | 5254.84 GB | 120 分钟 | 891 | 3,158 | 36 ms | 316 ms |
在 5TB 数据 的测试中，我们进行了 2 小时的 8 次搜索，包括复杂查询、聚合和 ES|QL。客户端数量从 4 增加到每次搜索 64 个，共有 32 到 512 个客户端进行搜索。随着客户端数量从 32 增加到 512，性能保持稳定。在 512 个客户端 运行时，我们观察到搜索请求速率为 3,158 次查询/秒，P50 响应时间为 36ms。整个测试过程中，搜索层按预期进行扩展以满足需求。
24小时搜索稳定性测试：
| 数据集 | 实际容量 | 持续时间 | 平均搜索速率（请求/秒） | 最大搜索速率（请求/秒） | 响应时间（P50） | 响应时间（P99） |
| 40TB | 60 TB | 24 小时 | 183 | 250 | 192 ms | 520 ms |
我们使用 7 次搜索、聚合和一次 ES|QL 查询来查询 40TB 的（主要是增强的）数据。客户端数量从每次搜索 1 增加到 12 个，总计 7 到 84 个搜索客户端。在设置为平衡的搜索能力下，我们观察到 192ms（P50）响应时间。您可以在 这里[4] 阅读更多关于配置搜索能力和搜索增强窗口的信息。
并发索引和搜索
在运行 同时索引 和 搜索 的测试中，我们计划在 6 个“块”中写入 5TB 数据。写入客户端从 24 增加到 480，批量大小为 2500 文档。搜索方面，客户端数量从每次搜索 2 增加到 40 个。总计有 16 到 320 个客户端进行搜索。
我们观察到两个层次都进行了自动扩展，搜索延迟始终保持在 24ms（P50）和 1359ms（P99）。系统在同时进行索引和搜索时保持性能，对于许多用例至关重要。
结论
上述压力测试集中在 Elasticsearch 项目中的搜索用例，设计了特定的字段类型、字段数量、客户端和批量大小配置。这些参数旨在评估 Elastic Cloud Serverless 在特定条件下的性能，提供有价值的见解。然而，重要的是要注意，这些结果可能不直接反映您的工作负载，因为性能取决于查询复杂性、数据结构和索引策略等各种因素。
这些基准测试结果仅作为参考，实际结果可能会因您的具体用例和需求而有所不同。需要注意的是，这些结果并不代表系统的性能上限。
压力测试的主要结论是 Elastic Cloud Serverless 展示出了显著的稳定性。它能够每天写入数百 TB 的数据，同时保持强大的搜索性能。这使得它成为大规模搜索工作负载的强大解决方案，确保在高数据量下的可靠性和效率。在接下来的文章中，我们将进一步探讨 Elastic Cloud Serverless 在 observability 和 security 用例中的压力测试，展示其在不同应用领域的多功能性，并提供更深入的见解。)
erless 的出现改变了企业使用 Elasticsearch 的方式，不再需要管理集群、节点或资源扩展。Elastic Cloud Serverless 的一个关键创新是其自动扩展功能，它能够实时适应工作负载和流量的变化。这篇文章将探讨自动扩展的技术细节、Elastic Cloud Serverless 在负载下的性能，以及广泛压力测试的结果。
什么是 Elastic Cloud Serverless？
Elastic Cloud Serverless 提供了一个自动化的、托管版的 Elasticsearch，根据需求进行扩展。不同于传统的 Elasticsearch 部署，用户必须配置和管理硬件或云实例，Elastic Cloud Serverless 负责基础设施扩展和资源分配。这对具有可变工作负载的组织特别有利，因为手动扩展基础设施既麻烦又容易出错。系统内置的自动扩展功能可以在没有人工干预的情况下处理大量的写入任务、搜索查询和其他操作。
Elastic Cloud Serverless 包含两个不同的层次：搜索层和索引层，每个层次都针对特定的工作负载进行了优化。搜索层专门处理查询执行，确保搜索请求的快速高效响应。而索引层则负责数据的写入和处理，管理写操作，确保数据被正确存储并可搜索。通过将这些任务分开，Elastic Cloud Serverless 允许每个层次根据工作负载的需求独立扩展。这种分离提高了资源效率，因为用于高吞吐量写入的计算和存储需求不会影响搜索操作期间的查询性能。同样，搜索层资源可以扩展以处理复杂查询或流量激增，而不会影响写入过程。这种架构确保了最佳性能、成本效益和弹性，使 Elastic Cloud Serverless 能够在保持一致用户体验的同时动态适应波动的工作负载。
您可以在以下 博客文章[5] 中了解更多有关 Elastic Cloud Serverless 架构的信息。
Elastic Cloud Serverless 的压力测试
我们进行了全面的压力测试，以评估 Elastic Cloud Serverless 处理大规模波动工作负载的能力。这些测试旨在衡量系统在极端条件下的数据写入、搜索查询和性能维持能力。需要注意的是，系统的性能可能超出我们在这里展示的结果，这取决于客户端数量和批量索引大小等因素。下面，我们将介绍这些测试的方法和发现。
测试范围和方法
我们的压力测试主要目标是回答以下关键问题：
• Elastic Cloud Serverless 如何应对大量数据写入和高并发客户端搜索查询？
• 它能否动态扩展以适应突发的工作负载激增？
• 系统在长时间内能否保持稳定？
搜索用例的压力测试
在 Elastic Cloud Serverless 中，您可以选择三种项目类型：Elasticsearch、Observability 和 Security。我们首先在 Elasticsearch 的搜索用例上进行压力测试，使用 GitHub Archive 数据集并模拟可能的写入和搜索行为。测试前，我们通过 DataStreams 使用 Bulk APIs 预先写入了 186GB / 4300万文档 的基础数据，然后在十分钟内逐渐增加客户端数量，以便 Elasticsearch 有时间适当扩展。
索引层的压力测试
首先，让我们谈谈数据写入（ingest）。Elastic Cloud Serverless 中的写入自动扩展功能会根据数据写入需求动态调整资源，确保最佳性能和成本效益。系统会持续监控指标，如写入吞吐量、资源利用率（CPU、内存和网络）以及响应延迟。当这些指标超过预定阈值时，自动扩展器会按比例增加容量，以应对当前和预期的需求，同时为意外激增保留缓冲。数据管道的复杂性和系统施加的资源限制也会影响扩展决策。通过动态添加或删除容量，写入自动扩展确保无缝扩展，无需人工干预。
在像 Elastic Cloud Serverless 这样的自动扩展系统中，资源效率得到优化，但在某些情况下，突然的大量工作负载可能会超出系统立即扩展的能力。在这种情况下，客户端可能会收到 HTTP 429 状态码，表示系统负载过重。为应对这些情况，客户端应实施指数退避策略，逐渐延长重试请求的间隔。在压力测试期间，我们积极跟踪 429 响应，以评估系统在高需求下的反应，提供关于自动扩展有效性的重要见解。您可以在这篇 博客文章[6] 中详细了解我们如何自动扩展写入。现在，让我们看看我们在索引层压力测试中遇到的一些结果。
扩展中的索引：
| 数据集 | 批量大小 | 实际容量 | 索引时间（分钟） | 每小时容量 | 中位吞吐量（文档/秒） | 90百分位索引延迟（秒） | 平均错误率（429及其他） |
| 1TB | 2500 | 1117.43 GB | 63 | 1064.22 GB | 70,256.96 | 7.095 | 0.05% |
| 2TB | 2500 | 2162.02 GB | 122 | 1063.29 GB | 68,365.23 | 8.148 | 0.05% |
| 5TB | 2500 | 5254.84 GB | 272 | 1159.16 GB | 74,770.27 | 7.46 | 0 |
在初始测试中，我们在 1TB 和 2TB 数据集上分别达到了 1064 GB/小时 和 1063 GB/小时 的吞吐量。在 5TB 数据集上，我们达到了 1160 GB/小时 的更高吞吐量，因为写入层继续扩展，提供了更好的吞吐量。
完全扩展的索引：
| 客户端 | 批量大小 | 实际容量 | 持续时间 | 每小时容量 | 中位吞吐量（文档/秒） | 99百分位索引延迟（秒） | 平均错误率（429及其他） |
| 3,000 | 2,000 | 1 TB | 8 分钟 | 7.5 TB | 499,000 | 33.5 | 0.0% |
在完全扩展的索引层上，Elastic Cloud Serverless 在 8 分钟 内写入了 1TB 数据，写入速度为 ~499K 文档/秒。这相当于每天 180TB 的写入能力。
从最小规模到最大规模的索引：
| 客户端 | 批量大小 | 实际容量 | 持续时间 | 每小时容量 | 中位吞吐量（文档/秒） | 99百分位索引延迟（秒） | 平均错误率（429及其他） |
| 2,048 | 1,000 | 13 TB | 6 小时 | 2.1 TB | 146,478 | 55.5 | 1.55% |
在 2TB 数据 的测试中，我们逐步扩展到 2048 客户端，并以 146K 文档/秒 的速度完成了 2TB 数据的写入，耗时 1 小时。按此计算，每天可写入 48TB 数据。
72小时稳定性测试：
| 客户端 | 批量大小 | 实际容量 | 索引时间（小时） | 每小时容量 | 中位吞吐量（文档/秒） | 99百分位索引延迟（秒） | 平均错误率（429及其他） |
| 128 | 500 | 61 TB | 72 | ~868.6 GB | 51,700 | 7.7 | <0.05% |
在 72小时稳定性测试 中，我们使用 128 客户端 写入了 60TB 数据。Elastic Cloud Serverless 保持了 870GB/小时 的吞吐量，并且错误率极低，同时扩展了索引和搜索层。这展示了 Elasticsearch 在长时间内保持高吞吐量和低故障率的能力。
搜索层的压力测试
Elastic Cloud Serverless 中的搜索层自动扩展功能会根据数据集大小和搜索负载动态调整资源，以保持最佳性能。系统将数据分类为两类：增强数据和非增强数据。增强数据包括在用户定义的增强窗口内的时间序列文档（具有 @timestamp
字段）和所有非时间序列文档，而非增强数据则在此窗口之外。用户可以设置增强窗口来定义增强数据的时间范围，并选择搜索能力级别（按需、性能或高吞吐量）来控制资源分配。您可以在 这里[7] 阅读更多关于配置搜索能力和搜索增强窗口的信息。
自动扩展器会监控指标，如查询延迟、资源利用率（CPU 和内存）以及查询队列长度。当这些指标显示需求增加时，系统会相应地扩展资源。此扩展是按项目进行的，对最终用户透明。
负载下的搜索稳定性：
| 数据集 | 实际容量 | 持续时间 | 平均搜索速率（请求/秒） | 最大搜索速率（请求/秒） | 响应时间（P50） | 响应时间（P99） |
| 5TB | 5254.84 GB | 120 分钟 | 891 | 3,158 | 36 ms | 316 ms |
在 5TB 数据 的测试中，我们进行了 2 小时的 8 次搜索，包括复杂查询、聚合和 ES|QL。客户端数量从 4 增加到每次搜索 64 个，共有 32 到 512 个客户端进行搜索。随着客户端数量从 32 增加到 512，性能保持稳定。在 512 个客户端 运行时，我们观察到搜索请求速率为 3,158 次查询/秒，P50 响应时间为 36ms。整个测试过程中，搜索层按预期进行扩展以满足需求。
24小时搜索稳定性测试：
| 数据集 | 实际容量 | 持续时间 | 平均搜索速率（请求/秒） | 最大搜索速率（请求/秒） | 响应时间（P50） | 响应时间（P99） |
| 40TB | 60 TB | 24 小时 | 183 | 250 | 192 ms | 520 ms |
我们使用 7 次搜索、聚合和一次 ES|QL 查询来查询 40TB 的（主要是增强的）数据。客户端数量从每次搜索 1 增加到 12 个，总计 7 到 84 个搜索客户端。在设置为平衡的搜索能力下，我们观察到 192ms（P50）响应时间。您可以在 这里[8] 阅读更多关于配置搜索能力和搜索增强窗口的信息。
并发索引和搜索
在运行 同时索引 和 搜索 的测试中，我们计划在 6 个“块”中写入 5TB 数据。写入客户端从 24 增加到 480，批量大小为 2500 文档。搜索方面，客户端数量从每次搜索 2 增加到 40 个。总计有 16 到 320 个客户端进行搜索。
我们观察到两个层次都进行了自动扩展，搜索延迟始终保持在 24ms（P50）和 1359ms（P99）。系统在同时进行索引和搜索时保持性能，对于许多用例至关重要。
结论
上述压力测试集中在 Elasticsearch 项目中的搜索用例，设计了特定的字段类型、字段数量、客户端和批量大小配置。这些参数旨在评估 Elastic Cloud Serverless 在特定条件下的性能，提供有价值的见解。然而，重要的是要注意，这些结果可能不直接反映您的工作负载，因为性能取决于查询复杂性、数据结构和索引策略等各种因素。
这些基准测试结果仅作为参考，实际结果可能会因您的具体用例和需求而有所不同。需要注意的是，这些结果并不代表系统的性能上限。
压力测试的主要结论是 Elastic Cloud Serverless 展示出了显著的稳定性。它能够每天写入数百 TB 的数据，同时保持强大的搜索性能。这使得它成为大规模搜索工作负载的强大解决方案，确保在高数据量下的可靠性和效率。在接下来的文章中，我们将进一步探讨 Elastic Cloud Serverless 在 observability 和 security 用例中的压力测试，展示其在不同应用领域的多功能性，并提供更深入的见解。
引用链接
[1]
博客文章: https://www.elastic.co/blog/elastic-serverless-architecture[2]
博客文章: https://www.elastic.co/search-labs/blog/elasticsearch-ingest-autoscaling[3]
这里: https://www.elastic.co/guide/en/serverless/current/elasticsearch-manage-project.html#elasticsearch-manage-project-search-ai-lake-settings[4]
这里: https://www.elastic.co/guide/en/serverless/current/elasticsearch-manage-project.html#elasticsearch-manage-project-search-ai-lake-settings[5]
博客文章: https://www.elastic.co/blog/elastic-serverless-architecture[6]
博客文章: https://www.elastic.co/search-labs/blog/elasticsearch-ingest-autoscaling[7]
这里: https://www.elastic.co/guide/en/serverless/current/elasticsearch-manage-project.html#elasticsearch-manage-project-search-ai-lake-settings[8]
这里: https://www.elastic.co/guide/en/serverless/current/elasticsearch-manage-project.html#elasticsearch-manage-project-search-ai-lake-settings
