1 容量规划案例1
固定大小的数据集
被搜索的数据集很大，但是增长相对比较慢（不会有大量的写入）。更关心搜索和聚合的读取性能
数据的重要性与时间范围无关。关注的是搜索的相关度
一些案例：唱片信息库 产品信息
一些特性
估算索引的的数据量，然后确定分片的大小
单个分片的数据不要超过 20 GB
可以通过增加副本分片，提高查询的吞吐量
2 拆分索引
如果业务上有大量的查询是基于一个字段进行 Filter，该字段又是一个数量有限的枚举值，例如订单所在的地区
如果在单个索引有大量的数据
如果要对多个索引进行查询，还是可以在查询中指定多个索引得以实现
如果业务上有大量的查询是基于一个字段进行 Filter，该字段数值并不固定，可以启用 Routing 功能，按照 filter 字段的值分布到集群中不同的 shard，降低查询时相关的 shard， 提高 CPU 利用率，示例：
PUT my-index-000001/_doc/1?routing=user1&refresh=true { "title": "This is a document"}
3 容量规划案例2
基于时间序列的数据
每条数据都有时间戳；文档基本不会被更新（日志和指标数据）
用户更多的会查询近期的数据；对旧的数据查询相对较少
对数据的写入性能要求比较高
日志 指标 / 安全相关的 Events
舆情分析
相关的用案
特性
4 创建基于时间序列的索引
创建 time-based 索引
在索引的名字中增加时间信息
按照 每天 / 每周 / 每月 的方式进行划分
好处
更加合理的组织索引，例如随着时间推移，便于对索引做的老化处理
利用 Hot & Warm Architecture
备份和删除的效率高
5 写入时间序列的数据：基于 Date Math 的方式
容易使用
如果时间发生变化，需要重新部署代码
6 写入时间序列的数据 – 基于 Index Alias
Time-based 索引
创建索引，每天 / 每周 / 每月
在索引的名字中增加时间信息
7 集群扩容
增加 Coordinating / Ingest Node
解决 CPU 和 内存开销的问题
增加数据节点
解决存储的容量的问题
为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点（70%）
关注公众号：领取精彩视频课程&海量免费语音课程
