Amazon OpenSearch Serverless 实践指南 - OCU 设计与按集合类型的优化策略
Amazon OpenSearch Serverless 是一项无需集群运维管理、通过自动扩展处理搜索和分析工作负载的全托管服务。从实务角度解析 OCU 计费模型、集合类型的选择标准以及索引设计的最佳实践。
从集群管理中解放 - OpenSearch Serverless 解决的运维课题
传统的 Amazon OpenSearch Service 中，域的实例类型选择、分片数调整、节点故障时的重平衡等集群运维不可避免。特别是流量波动大的工作负载，要么为峰值过度预置，要么接受扩展延迟导致的延迟恶化。OpenSearch Serverless 通过将计算和存储完全分离来解决这一课题。索引数据存储在 S3 上，计算节点根据负载自动扩缩。用户只需创建集合（Collection）并写入数据，无需关心底层节点数和分片分配。
正确理解 OCU 的计费结构 - 最低成本与自动扩展的实际情况
决定 OpenSearch Serverless 成本的是 OCU (OpenSearch Compute Unit) 机制。1 OCU 提供 6 GiB RAM 和对应的 vCPU，分为索引用和搜索用两个系统分配。重要的是，创建集合时索引用最低 2 OCU、搜索用最低 2 OCU，合计 4 OCU 的最低费用始终产生。按东京区域每 OCU 约 0.334 美元/小时计算，即使零流量月费也约 975 美元。这意味着「不用就不花钱」的 Lambda 式 Serverless 预期并不适用。适合的是流量变动大但始终有一定基础负载的工作负载。
三种集合类型 - 按工作负载特性的选择标准
OpenSearch Serverless 提供搜索 (Search)、时序 (Time series)、向量搜索 (Vector search) 三种集合类型。各自内部索引策略不同，选错类型会在性能和成本两方面受损。搜索集合适用于 EC 网站商品搜索和文档搜索等随机访问为主的工作负载，内部优化了倒排索引的缓存策略。时序集合针对日志和指标等按时间顺序追加的数据优化，自动按时间范围分区以高效执行范围查询。向量搜索集合支持 k-NN 搜索，适用于语义搜索和 RAG 的嵌入检索。
索引设计要点 - 分片策略与映射定义的实践
虽然 OpenSearch Serverless 不需要手动设置分片数，但索引的映射设计仍直接影响性能。首先，必须创建明确定义字段数据类型的映射。依赖动态映射会导致想作为数值处理的字段被注册为 text 类型，大幅降低聚合查询效率。keyword 类型和 text 类型的区分也很重要，精确匹配和排序用 keyword，全文搜索用 text。嵌套对象使用 nested 类型可保持文档内数组元素的独立性。日期字段统一为 ISO 8601 格式，数值字段根据范围选择 integer 或 long。
安全与访问控制 - 加密策略与数据访问策略的设计
OpenSearch Serverless 的安全模型与传统 OpenSearch Service 根本不同。取代细粒度访问控制 (FGAC)，采用加密策略、网络策略和数据访问策略的三层结构管理。加密策略需在创建集合前定义，选择 AWS 托管密钥或客户托管 KMS 密钥。合规要求严格的环境选择客户托管密钥以保留密钥轮换和删除的控制权。网络策略控制集合端点的公开范围，可限制为仅 VPC 端点访问。数据访问策略以 JSON 格式定义 IAM 主体对集合和索引的操作权限。
导入判断框架 - Serverless 与传统集群的分界点
OpenSearch Serverless 与传统 OpenSearch Service 的选择基于工作负载特性和成本结构判断。Serverless 适合流量变动大且难以预测的工作负载、运维团队少的环境、需要快速搭建搜索平台的场景。另一方面，流量稳定且需严格管理成本的场景，或需要自定义插件的场景，传统集群更合适。成本分界点大致在月费 1,000 美元左右：低于此值时传统集群的小型实例更经济，高于此值时 Serverless 的自动扩展优势显现。 关于搜索引擎的深入学习，相关书籍 (Amazon)也可供参考。