数据量涨到一定规模，很多团队会同时碰到两个问题。一是日志散落在几十台服务器上，出故障时只能逐台登录翻文件。二是商品搜索越来越慢，用户打错一个字就搜不到结果。Elasticsearch 是解决这类问题的常见选择，阿里云ES把集群的部署、扩容和运维托管起来，团队可以把时间放在业务数据上。下面先说它能做什么、适合哪些场景，再重点讲日志检索集群的节点数和磁盘怎么定。
阿里云ES是什么
阿里云ES 基于开源 Elasticsearch 构建，提供集群创建、版本选择、节点扩缩容、备份恢复和监控告警，并内置 Kibana 用于可视化。没有专职搜索运维的团队，托管方式能少处理很多节点故障和版本升级的事。但托管不代替设计。索引怎么建、数据保留多久、磁盘够不够，仍然要自己判断。
三个典型场景
集中式日志分析
某中型在线教育公司有上百台应用服务器。过去排查接口超时，工程师要逐台看日志文件。后来他们用 Logstash 或 Filebeat 统一采集，写入阿里云ES，并按天建索引。现在在 Kibana 里按请求 ID、接口路径和响应时长筛选，定位问题的时间从半小时左右缩短到几分钟。索引按天滚动，再配合生命周期策略，超过 30 天的数据转冷或删除，存储成本也容易控制。
电商站内搜索
一家服饰电商原来用数据库模糊查询做商品搜索。商品超过 80 万条以后响应明显变慢，同义词和拼音输入也处理不了。迁到阿里云ES 后，团队给商品标题配了中文分词器，并维护同义词词典，比如把“牛仔裤”和“丹宁裤”关联起来。平均响应时间降到百毫秒以内，搜索转化率也有所提升。这类项目的日常工作集中在分词和同义词维护上，集群配好以后反而省心。
语义相似推荐
内容平台想在用户读完一篇文章后推荐相似内容，只靠关键词匹配效果有限。团队把标题和摘要转成向量，写入带 dense_vector 字段的索引，查询时做向量近邻搜索，同时保留分类、发布时间等关键词过滤条件。这样推荐结果既有语义相关性，也不会跨分类或超出发布时间范围。
日志集群的节点数怎么定
定节点数之前，先算三个数：每天写入多少原始数据，保留多少天，以及索引后每条数据占多少存储。写入量乘以保留天数，就是原始数据总量。再乘以 (1 + 副本数)，得到包含副本的数据量。索引本身还会占空间，倒排索引和 doc values 都要落盘，所以还要预留膨胀余量。膨胀比例没有统一的值，最靠谱的办法是用真实日志写一批数据到测试索引里，按实测结果估算。
假设一个团队每天写入 200 GB 原始日志，保留 15 天，副本数为 1。原始数据约 3 TB，加上副本是 6 TB。实际需要的磁盘要比 6 TB 再多出一截，多多少取决于实测的膨胀比例。节点数由磁盘总量和单节点可用磁盘共同决定，同时还要看写入峰值时 CPU 是否扛得住。
磁盘水位要留足余量
单节点能用的磁盘要扣掉系统和 ES 自身占用。开源 Elasticsearch 默认在磁盘使用率超过 85% 时不再向该节点分配新分片，超过 90% 尝试把分片迁走，超过 95% 把索引设为只读。所以不能按写满磁盘来算。比较稳妥的做法是把日常使用率压在七成左右，告警阈值也要设在 85% 之前，留出反应时间。
内存和 CPU 不能只看磁盘
写入量大、查询并发高的时候，节点数往往由 CPU 和 JVM 堆内存决定。堆内存通常设为物理内存的一半，且不超过 31 GB 左右，超过这个界限后 JVM 无法继续使用压缩指针，内存利用率反而变差。具体规格以控制台实际可选的配置为准。
冷热分层控制成本
最近几天的日志经常被查询和写入，适合放在性能较好的 SSD 上。超过一定时间的冷数据可以转到容量型存储，或者直接删除。分层能明显省钱，但不要把最近的数据放在慢盘上，否则故障排查时查询会卡住。
落地步骤
- 先定场景：日志分析、全文检索和向量检索对分片、内存和磁盘的要求差别很大。日志场景重点算磁盘和保留周期，检索场景更看内存和分片设计。
- 选版本：新项目选当前主流的稳定版本。老系统迁移前，要确认客户端 SDK、插件和采集端与 Kibana 版本是否匹配。
- 规划索引：提前设计 mapping，区分需要分词的字段和只用于过滤的字段。日志字段多，不需要检索的字段可以设置 index: false，能省下不少磁盘。
- 配置安全：开启访问控制，收窄公网访问范围，业务服务通过 VPC 内网连接。
- 设置监控与备份：为 CPU、磁盘使用率和 JVM 堆内存配置告警。定期验证快照恢复，快照只有恢复过，才能确定它是否可用。
常见误区
- 分片设得过多：每个小索引都占用内存和线程资源，分片过多会拖慢查询。按天建索引时，先估算单个分片的目标大小，再决定主分片数。
- 拿它当主数据库：Elasticsearch 不适合替代事务型数据库。需要强一致和复杂事务的数据应放在别处，ES 更适合承担查询和分析。
- 只看写入速度：写入快不代表查询快。mapping 没有按查询模式设计，后面往往要重建索引。
- 历史数据全放高性能盘：超过查询需求的旧日志仍占着 SSD，成本会一直往上走。
阿里云ES 能降低搜索系统的运维门槛，但节点数和磁盘仍要按自己的写入量和保留周期来算。建议先接入一个服务的日志，跑一两周，拿到真实的写入量和膨胀比例，再决定扩容规模。
