OpenSearch 权威指南——部署选项：Amazon OpenSearch Service 与 Amazon OpenSearch Serverless

数据智能老司机
137 阅读23分钟

当今以数据为驱动的世界中，能够对海量数据快速而准确地搜索、分析并获取洞察，对各行业的企业都至关重要。Amazon OpenSearch Service 是基于开源 OpenSearch 项目的全托管服务，帮助组织充分释放搜索与分析能力的潜力。本章将介绍 OpenSearch Service 的关键特性、API、用例与优势，帮助你全面理解它如何提升你的搜索与数据探索实践。

在延续上一章关于 OpenSearch 集群部署的讨论时，我们将本章聚焦于托管服务。像 OpenSearch Service 这样的托管服务会承担运行 OpenSearch 的大量运维工作，让你把精力集中在应用与数据上。OpenSearch Service 提供两种部署选项：

  • 托管集群（managed clusters） ：由你选择底层基础设施，并通过 API 进行扩缩；
  • 无服务器（serverless） ：由服务自动为你伸缩基础设施。

我们将涵盖以下主题：

  • Amazon OpenSearch Service 简介
  • 通过 API 与 SDK 访问 Amazon OpenSearch Service 域（domain）
  • Amazon OpenSearch Service 的基础设施
  • 管理 Amazon OpenSearch Service
  • Amazon OpenSearch Serverless
  • OpenSearch 托管合作伙伴

接下来先从托管集群的主要架构组件谈起。

Amazon OpenSearch Service 简介

本节将说明构成 OpenSearch 集群的基本单元，以及它们在 OpenSearch Service 托管集群中的对应关系。理解这些核心组件及其协作方式，有助于你在设计与实现搜索或日志分析方案时做出正确决策。

架构与组件

Amazon OpenSearch Service 是托管服务，但与开源 OpenSearch 共享大量核心组件。其核心依旧是由多个节点（nodes）协同工作的集群（cluster） ，用于存储、索引与搜索数据。

在使用 托管集群部署 时，你可以通过 AWS 管理控制台、CloudFormation、Terraform、AWS CLI、SDK 或 CDK 向服务发起 API 调用。服务会创建一个 域（domain） ，其中包含 OpenSearch 集群、其硬件以及各类管理组件。

对于托管集群，服务支持 数据节点（data nodes） 、专用集群管理节点（dedicated cluster manager nodes） 、专用协调节点（dedicated coordinator nodes） 与 UltraWarm 节点。

  • 数据节点 负责存储与索引实际数据；
  • 集群管理节点 协调集群操作并管理元数据（生产环境建议使用专用管理节点以提升稳定性与性能）；
  • 数据节点 上存放索引与分片（关于分片可回看第 2 章“集群基础”）；
  • 专用协调节点 负责请求的协调与分发；
  • UltraWarm 节点 为时序型数据提供更低成本的存储层。

整体架构具备高可用与容错能力，支持自动故障转移与自愈。随着数据量或查询负载增长，你可以通过增加/移除节点来扩缩域，保证性能与资源利用最优。

image.png

图 3.1：Amazon OpenSearch Service 托管集群架构

当你选择 Serverless 部署 时，你会创建一个 collection（集合） ，其中可包含一个或多个索引用于搜索与分析。尽管两种部署在一些方面有所不同，但大多数服务级特性在托管集群与 Serverless 之间是一致的。差异点会在本章后续部分展开；这里先介绍若干关键服务特性。

关键特性

服务侧的管理能力让“拥有并运营 OpenSearch”变得更简单：你可以通过 API、基础设施即代码（IaC）或控制台 来部署托管集群或 serverless 集合，从而免于自行资源规划、配置与维护。AWS 负责底层基础设施，包括打补丁与软件更新，你可以专注于应用与数据。对于托管集群，无缝的基础设施变更让你能随负载变化快速调整资源。

服务会将指标发布到 Amazon CloudWatch，并将审计信息写入 CloudWatch Logs，便于你对域或集合的运行做出明智决策。服务提供 7×24 监控与自愈，免去大量日常运维琐事。
安全方面，服务通过 VPC 部署实现网络隔离，并与 AWS IAM 集成实现细粒度访问控制：

  • 托管集群可基于角色访问控制（RBAC）精确到字段级；
  • Serverless 集合则通过账户级策略作用于集合与索引进行访问控制。
    此外，服务默认提供静态加密与传输加密。Amazon OpenSearch Service 遵循多项合规标准与认证（如 SOC、PCI DSS、HIPAA 等），适用于受监管行业。

弹性方面，托管集群可轻松跨多个 可用区（AZ） 部署，并提供标准或增强弹性级别，SLA 可达四个 9。服务会对域进行每小时快照并保留两周，同时提供 API 以便你将快照保存到 Amazon S3。Serverless 集合的全部数据存放在 S3，具备极高的持久性。

数据摄取方面，服务提供 Amazon OpenSearch Ingestion：一条 serverless、自动伸缩 的 ETL 管道，可采集、转换并将日志数据投递到托管集群或 serverless 集合。该能力基于开源 Data Prepper，并可对接 Amazon MSK（Kafka） 、Kinesis Data Streams、DynamoDB、DocumentDB 等多种数据源。服务还提供额外集成，便于查询驻留在 S3 与 CloudWatch Logs 的数据。

服务为托管集群与 serverless 集合都提供 OpenSearch Dashboards 访问；借助 OpenSearch Service UI Applications，你可以在工作区（workspace）中整合来自域、集合、S3 与 CloudWatch 的数据进行分析可视化。

最后，服务提供多种成本控制与优化特性：

  • 托管集群支持数据分层，可将数据存入更低成本的存储层，如 UltraWarm 与 Cold Storage（S3） ；
  • Serverless 集合会自动为你分层数据并自动伸缩基础设施，让你只为实际工作负载付费。

image.png

图 3.2：Amazon OpenSearch Service 的生态集成

下一节将介绍 **Amazon OpenSearch Service 域（domain）**的基础设施。

Amazon OpenSearch Service 域的基础设施

要开始使用托管集群，首先需要创建一个 OpenSearch Service 域，并为不同节点角色选择 EC2 实例类型。

你可以通过多种方式来创建与配置域：

  • AWS 管理控制台（可视化配置）
  • 基础设施即代码（IaC） ：AWS CDK、CloudFormation、Terraform
  • AWS 命令行界面（CLI）
  • 通过 AWS SDK 编程化创建

创建域时，请参考 Amazon OpenSearch Service 开发者指南中的最新步骤：
docs.aws.amazon.com/pdfs/opense…。
截至 2025 年 6 月，Amazon OpenSearch Service 托管集群支持 OpenSearch 2.19，其中引入了多项高级特性，如ML 推理搜索请求扩展，以及允许用户传递不属于搜索查询的附加输入字段等。

接下来，我们将深入托管集群的管理要点，重点讨论在工作负载与需求演进过程中，如何实施扩缩策略与合理定型（rightsizing） 。

管理 Amazon OpenSearch Service 域（Domains）

本节将围绕 定型（rightsizing） 、扩缩（scaling） 、快照（snapshots） 与 存储（storage） 等关键方面，讲解如何管理 OpenSearch 基础设施。这些扩缩策略建立在第 2 章「索引洞察：在 OpenSearch 中组织数据」中介绍的分片与索引基础之上，有助于理解 OpenSearch 的数据组织方式。

定型（Rightsizing）

为 OpenSearch Service 域做合理定型，是实现最佳性能、成本效率与可扩展性的关键。需要综合评估数据体量、查询模式、资源需求，以确定节点数量、分片配置与硬件规格。第 14 章将深入展开，此处先给出核心概念，便于后续章节理解。

虽然不存在通用的一刀切方案，但别担心！在为数据节点选择实例类型与数量时，可先基于存储需求、并发量以及查询特性（偏计算或偏内存）做一次估算。建议先估算存储，再选择节点类型：

  • 存储计算（Storage calculations） ：
    总存储取决于多项因素：

    • 数据体量：计划写入 OpenSearch 的原始数据大小
    • 索引开销（Index overhead） ：OpenSearch 用于索引与元数据的额外空间
    • 副本数（Replicas） ：每个主分片配置的副本数量

    计算公式：
    Total Storage = (Data Volume + Index Overhead) × (1 + Number of Replicas)
    另再乘以 1.25 以预留 25% 的空闲空间。

    索引开销通常约为原始数据的 -30% 到 +30% （取决于字段压缩、字段类型与索引设置）。可先以 +30% 作为保守估计。

  • CPU 与内存（CPU and memory） ：
    估算完存储后关注 CPU。经验法则：每个活跃分片配约 1.5 个 CPU。高并发负载可能需要更高比例。
    OpenSearch 使用实例内存的一部分作为 Java 堆（heap） ，并将索引数据缓存于 堆外。一般而言，内存越多性能越好。对大型负载，单实例可为 Java 堆分配最高约 32GB，并尽量提供额外内存（理想情况下可与所有分片总量相当）。

  • 分片配置（Shard configurations） ：
    分片与副本数直接影响性能、可用性与存储。默认创建索引时主分片为 1（托管集群默认 5）。
    建议将未复制的索引数据量拆分为：

    • 搜索型工作负载：每个分片 ≈ 30 GB
    • 时序型工作负载：每个分片 ≈ 50 GB

  • 性能监控与调优（Performance monitoring and tuning） ：
    定型是迭代过程，需持续监控与调优。OpenSearch Service 提供多种指标与监控工具以跟踪集群健康、资源使用与瓶颈。通过分析 CPU 使用率、磁盘 I/O、查询延迟、缓存命中率 等指标，定位潜在问题并据此调整：例如增减节点、调整分片配置、微调索引设置与映射。

扩缩 Amazon OpenSearch Service 域（Scaling）

根据负载与数据量波动调整域的基础设施，是管理 OpenSearch Service 的关键。服务提供多种扩缩选项以适配变化的需求。

垂直扩展（Vertical scaling / resizing）

通过修改实例类型或存储容量来扩展数据节点。当需要提升或降低单节点的计算或存储能力时适用。
OpenSearch Service 支持调整数据节点的实例类型与 EBS 卷大小。尽管垂直扩展有效，但出于分布与弹性的考量，水平扩展（增减节点）通常更优。需要注意的是，单节点存放的数据越多，恢复时该节点承担的工作越重，恢复时间可能更长（恢复在节点间并行进行）。

水平扩展（Horizontal scaling / adding or removing nodes）

通过增加或移除数据节点来改变集群总能力，适用于需要整体扩容或缩容的场景。OpenSearch Service 简化了增删节点的过程。但要注意，水平扩展会在跨节点搜索/聚合时引入一定节点间通信开销。

当面临节点本地资源的限制（如存储上限、堆大小上限、队列大小、带宽限制、每节点软分片数上限）时，水平扩展尤为有效。通过增加节点，OpenSearch 能在保持性能与可用性的同时，处理更大的数据量、更高吞吐与更复杂的查询。

托管集群中的快照（Snapshots）

快照会将集群的完整状态保存到你指定的仓库中，是 OpenSearch 数据保护与灾备的关键手段——一旦发生数据丢失或损坏，可据此恢复整个集群或指定索引。

OpenSearch Service 提供两类快照：

  • 手动快照（Manual snapshots） ：
    由用户发起的备份，可按需创建或按计划定期执行，存放在你指定的 Amazon S3 存储桶中。
  • 自动快照（Automated snapshots） ：
    按预定义频率（如每小时、每日、每周）自动运行。服务负责完整的快照生命周期：创建、保留、删除，依据你设定的保留期执行。自动快照同样存储在你选择的 S3 存储桶中。

存储管理（Storage management）

在 Amazon OpenSearch Service 中，优化的存储管理对性能与可靠性至关重要。可选方案包括：

  • EBS 存储：
    对某些实例类型，Service 使用 EBS 卷存放域数据。EBS 具备高可用与冗余容错能力。可在创建域时配置卷大小，亦可后续在线扩容以适配变化的存储需求。

  • 索引状态管理（Index State Management, ISM） ：
    ISM 面向时序工作负载的索引生命周期管理（见图 3.3）。你可基于索引年龄、大小等条件定义策略，实现自动rollover（滚动） 、shrink / freeze 冷数据、删除老索引等动作，从而优化存储占用、降低成本。

image.png

**示例说明**：

-   **Index 1** 为当前**写入索引**；满足 rollover 条件（大小 / 文档数 / 时间）时，系统自动创建 **Index 2** 并将其设为新的写入索引。建议将旧的 **Index 1** 置为**只读**，以避免继续写入，同时不影响查询与分析访问历史数据。
-   下例策略使用 `_rollover` API，当索引大小达到 **40GB** 时触发；匹配模式为 `logs-*`。同样也可使用**基于时间**的策略（如 `"min_index_age": "10d"`）：

```
{
  "policy": {
    "policy_id": "rollover_policy",
    "default_state": "rollover",
    "states": [
      {
        "name": "rollover",
        "actions": [
          { "rollover": { "min_size": "40gb" } }
        ],
        "transitions": []
      }
    ],
    "ism_template": {
      "index_patterns": ["logs-*"],
      "priority": 0,
      "last_updated_time": 1627132417234
    }
  }
}
```
  • UltraWarm 存储：
    一种性价比高的历史/低频访问数据存储层。其底层使用 Amazon S3，相较 EBS 或实例本地 SSD，存储成本显著更低。适用于需要长期留存大量数据以满足合规或分析需求、同时又要控制成本的场景。

至此，我们已介绍了托管集群的管理实践。接下来将转向 Amazon OpenSearch Serverless：它进一步简化 OpenSearch 的部署与运维，让你把精力放在构建基于搜索的应用与数据分析上，而不必耗费心力在集群管理上。

Amazon OpenSearch Serverless

Amazon OpenSearch Serverless 为希望拥有全托管、可扩展且具成本效益的搜索与分析方案的组织带来诸多收益。

其一大优势在于 Serverless（无服务器） 模式：你无需预置、扩容或管理基础设施，可以把精力放在应用逻辑与数据上，而不必操心底层资源。

此外，它还提供：

  • 自动伸缩（Automatic scaling） ：根据使用模式自动扩容/缩容，无需人工干预，确保在流量波动下依然具备最佳性能与成本效率。
  • 按用量计费（Pay-per-use） ：只为实际消耗的资源付费，无需前期投入或长期承诺。对负载波动或不可预测、预算有限或资源受限的团队尤为友好。

在 Amazon OpenSearch Serverless 的架构中（见图 3.4），collection（集合） 是面向特定工作负载（如时序、全文检索或向量检索）的一组一个或多个索引的逻辑分组。
Collections 将存储与计算解耦：使用 Amazon S3 存放索引数据，同时为写入与查询按需分配计算资源——即 OpenSearch compute units（OCUs） 。这种分离使索引与搜索可独立伸缩，并提供高可用与资源隔离。创建集合时需要指定集合类型，类型将决定数据存储策略、API 能力与支持的搜索特性。

image.png

图 3.4：Amazon OpenSearch Serverless 中的 Collections

同一账户内、使用相同加密密钥的所有集合可以共享 OCU。当你增加索引并向集合发送查询时，Serverless 会按需扩展 OCU 容量以满足需求。每个 OCU 提供 1 vCPU、120 GB 存储与 6 GB RAM。默认情况下，创建首个集合时会部署 4 个 OCU；若关闭冗余，可降为 4 个半 OCU 以节省成本。计费按小时对 OCU、关联的 S3 存储以及外发流量收费。

理解了 collections 的核心概念后，下面介绍如何创建与管理这些资源。

创建与管理 Amazon OpenSearch Serverless 集合

创建新集合的步骤：

  1. 在 AWS 管理控制台打开 Amazon OpenSearch Service，在左侧导航选择 Serverless。
  2. 点击 Create collection，为集合命名。
  3. 配置集合：选择集合类型、冗余级别与安全配置。
  4. 检查并创建。创建后即可在 Serverless 控制台进行管理，包括：

  • 修改集合设置：如数据保留周期与安全配置等。

  • 删除集合：不再需要时可删除以停止产生费用。

  • 监控集合：通过 Amazon CloudWatch 监控性能与用量指标。

  • 为集合打标签（Tagging） ：便于组织与治理。

  • 管理容量上限：为集合设置最大 OCU（CPU/内存/磁盘的组合）以控制资源与成本。

    • 路径：Serverless 控制台 → Serverless > Dashboard → Capacity Management 区域中配置最大容量。

此外，Serverless 还对单集合与区域内所有集合的最大容量设有硬上限，帮助在性能与预算之间取得平衡，同时保持 Serverless 架构的灵活性。

向 Amazon OpenSearch Serverless 集合导入数据（Ingestion）

你可以使用多种 AWS 提供的方法与集成把数据写入 Serverless 集合，常见方式包括：

  • OpenSearch APIs：直接使用 OpenSearch API 索引文档；可通过各语言的 OpenSearch 客户端库或直接发送 HTTP 请求至 API 端点。
  • Amazon OpenSearch Ingestion：全托管的 Serverless 自动伸缩 ETL 管道（基于开源 Data Prepper），可对数据进行过滤、富化、转换、规范化与聚合，并将其投递到托管域或Serverless 集合；可与 Amazon MSK、Kinesis Data Streams、DynamoDB、DocumentDB 等多源集成。
  • AWS Lambda 集成：用 Lambda 处理并写入数据；可由 S3、Kinesis Data Streams 等事件触发，完成转换后索引到集合。
  • AWS Glue 集成：无服务器 ETL（支持 Python 与 Spark/Scala）构建数据处理作业，从多源抽取、转换后加载进集合。
  • Amazon Data Firehose 集成：从 CloudWatch Logs、S3 等源捕获、转换并加载数据流到集合。

无论采用哪种方式，务必确保数据格式正确，并映射到集合中合适的索引与文档结构，以便进行高效的搜索与分析。

Amazon OpenSearch Serverless 的安全性

到目前为止，你已经了解了如何摄取（ingest）、扩缩与管理 collections。接下来来看 Amazon OpenSearch Serverless 的多维安全能力。在使用 Serverless 时，你需要创建策略（policies）来控制数据访问、数据加密与网络访问。这些策略既可以广泛生效（跨多个 collection 与 index），也可以精细到单个 collection，甚至单个 index。

  • 数据访问策略（Data access policies） ：指定哪些 AWS IAM 身份可以访问哪些 Serverless 资源，并授予相应权限。
  • 加密策略（Encryption policies） ：指定是使用 AWS 自有密钥还是经 AWS KMS 提供的**客户管理密钥（CMK）**对数据进行加密。
  • 网络策略（Network policies） ：决定某个 Serverless collection 的 API 端点及其关联的 OpenSearch Dashboards 端点是公网可达，还是仅可通过服务托管的 VPC 端点访问。VPC 端点通过 ENI 提供安全连接，并基于 IAM 进行认证；网络流量经 PrivateLink 隧道传输，确保 TLS 1.2+ 加密，并可通过 ConnectionTimeout 参数配置连接超时。访问控制使用与安全组规则绑定的资源策略，按“五元组”（协议/源/目的/IP/端口）过滤流量；Network ACL 在子网边界提供无状态包过滤，与有状态的安全组形成互补。
  • 审计日志（Audit logging） ：OpenSearch Serverless 与 Amazon CloudTrail 集成以进行 API 审计，记录管理事件。需要配置专用 trail、指定 S3 存储桶作为投递目标并授予 GetObject 所需的 IAM 权限。服务维护不可变事件记录，并支持多区域能力；条目为 JSON 格式，包含 requestParameters、userIdentity、responseElements 等，便于安全事件取证。
  • 合规认证（Compliance） ：通过细粒度访问控制与静态加密（AES-256 + KMS）满足严格合规框架。请在 AWS Services in Scope by Compliance Program 页面查看 OpenSearch Serverless 与托管集群的最新合规列表：aws.amazon.com/compliance/…。
  • 安全更新（Security updates） ：OpenSearch Serverless 通过在线热补丁透明修复 CVE，无需传统维护窗口。

Amazon OpenSearch Serverless 支持的操作与插件

Serverless 基于 OpenSearch 引擎，支持其大量核心操作与插件。概览如下：

  • 搜索（Search operations）

    • 全文检索（Full-text）
    • 结构化搜索（Structured）
    • 相关性排序（Relevance ranking）
    • 聚合与分析（Aggregations & analytics）
    • 向量数据的近似/精确/混合检索

  • 数据摄取（Data ingestion operations）

    • 单条与批量文档索引
    • 索引管理（创建/删除/更新）
    • 重新索引与数据迁移

  • 数据管理（Data management operations）

    • 索引别名（Index aliases）
    • 索引滚动与生命周期管理
    • 集合统计（Collection statistics）

  • 安全与访问控制（Security & access control）

    • 集合级与索引级访问控制
    • 客户管理密钥（CMK）
    • 传输中加密

  • 支持的插件（Supported plugins）

    • OpenSearch Dashboards
    • OpenSearch PPL 与 SQL

注：尽管 Serverless 覆盖了许多核心能力，但相较自管集群或OpenSearch Service 托管集群，部分高级/特定功能可能不可用或存在限制。AWS 会随服务演进陆续发布新功能与插件支持，最新信息请查阅官方文档与发行说明。

监控 Amazon OpenSearch Serverless

OpenSearch Service 可与多种 AWS 监控/可观测性服务集成，以监控集合的性能、用量与健康状况：

  • Amazon CloudWatch 指标：Serverless 会上报多项指标，例如：

    • 集合内可搜索文档数
    • 索引指标：索引速率、成功率、延迟
    • 搜索指标：搜索速率、成功率、延迟
    • 账户消耗的搜索/索引 OCU 数量

  • AWS CloudTrail：记录与 Serverless 的每次 API 交互，形成管理操作的审计轨迹。比如在调查无法解释的集合删除事件时，可通过 CloudTrail 找到发起的 IAM 角色、时间戳与源 IP，对响应安全事件与合规验证至关重要。

  • Amazon EventBridge：服务可将事件发送到 EventBridge；你可以基于特定事件/条件触发后续动作或工作流（如阈值告警、关键日志触发通知等）。

利用上述监控能力，你可以洞察集合的性能、使用情况与健康度，从而主动定位与解决问题，优化资源利用，并确保搜索与分析工作负载的可用性与可靠性。

在托管集群与 Serverless 之间做选择

在 OpenSearch Service 托管集群 与 OpenSearch Serverless 间做选择，取决于用例需求与可接受的权衡：

  • 托管集群（Managed clusters）
    适合需要专用资源与稳定性能的工作负载。你能更便捷地部署基础设施，并对索引/分片策略有更深的掌控，以在延迟与成本之间做精细权衡。托管集群通常支持多个 OpenSearch 版本，可利用新版本引入的高级特性。

    • 电商场景：对商品目录、用户评价与订单数据进行索引与检索，满足低延迟与高相关性需求。
    • 日志场景：结合高级实例类型与分层存储降低成本。

  • Serverless
    适合间歇性或不可预测流量的负载，如事件驱动架构或 IoT 应用。

    • 医疗场景：对患者记录或科研数据进行索引/检索，按需自动扩缩，减少运维负担。
    • 成本优势：对可变/突发流量尤其友好——按使用计费，仅为活跃处理时间付费，适合初创团队或中小企业。
    • 生成式 AI：Amazon Bedrock 可将 OpenSearch Serverless 作为知识库进行无缝集成。

归根结底，应依据性能需求、成本考量、工作负载特征与运维复杂度来确定选型。理解两种模式的优势与权衡点，有助于你做出与自身需求相匹配的决策，从而优化数据搜索与分析能力。

OpenSearch 的托管合作伙伴

OpenSearch 获得了众多技术合作伙伴的支持。这些伙伴提供托管平台与服务，帮助组织无缝利用 OpenSearch 的能力。包括 Oracle、AWS、Instaclustr、Bonsai 等在内的服务商都提供全托管的 OpenSearch 服务，代管部署、扩展与维护。下面来看几个常见的合作伙伴。

  • Oracle Cloud Infrastructure（OCI）Search with OpenSearch
    这是一项全托管的 OpenSearch 服务，能够充分利用 OpenSearch 的高级搜索、日志分析以及 AI/ML 能力。OCI 会负责集群的部署、扩缩与打补丁等运维任务，并支持细粒度资源配置（CPU、内存、存储可选）。同时开放 Observability 与 Security Analytics 插件用于基础设施与安全监控，并提供语义搜索与 RAG（检索增强生成） 的完整能力套件。
  • Bonsai
    Bonsai 提供全托管、可扩展且高可用的 OpenSearch 服务，其核心卖点是多云架构：可在 AWS、Google Cloud、Azure 等多家云上部署集群。Bonsai 的专有控制平面负责编排与管理集群，确保无缝的数据复制与高可用。还提供自动备份、滚动升级、实时性能监控等高级特性，并可通过易用的 Web 界面或 API 进行管理。多云策略带来更强的灵活性、数据主权与灾备能力。
  • Instaclustr
    Instaclustr 是开源数据技术的领先托管服务提供商，涵盖 OpenSearch。其 OpenSearch 服务面向日志分析、应用监控与搜索等场景，提供全托管、可扩展方案。架构基于 Kubernetes，便于资源管理与平滑扩容；关键组件包括专用集群管理节点、数据节点与客户端节点。内建高可用、自动备份与安全最佳实践，并提供专家支持与 7×24 监控，简化部署与运维。
  • Aiven
    Aiven 是领先的托管云数据平台，简化开源数据技术的部署、管理与扩展。其 OpenSearch 服务在云上提供全托管与可扩展的集群运行环境，架构同样基于 Kubernetes，实现高可用、自动故障转移与无缝扩容。关键组件包括数据、集群管理与摄取（ingest）等专用角色节点，以获得最佳性能与资源利用率。平台还提供备份/恢复、可观测性工具与完善的安全措施，适合寻求可靠与安全 OpenSearch 方案的企业。

小结

本章深入介绍了 Amazon OpenSearch Service 的关键特性，讲解了如何创建 域（domain）或 集合（collection） ，以及合理定型与最佳实践，以充分发挥搜索与分析能力。我们强调了 AWS 提供的托管、可扩展、高可用服务如何简化集群的部署与运维，使企业能更专注于核心应用与数据洞察。同时也介绍了 OpenSearch 在 AWS 生态中的高级特性与无缝集成。
此外，我们还梳理了 Oracle、Aiven、Bonsai、Instaclustr 等合作伙伴的托管方案，它们提供全托管、可维护的 OpenSearch 集群选择。

下一章将更深入讲解 OpenSearch 的数据存储与索引 API，并配以示例查询进行说明。

avatar
文章
阅读
粉丝