Elasticsearch数据规划
1.1 为什么数据规划很重要
任何系统都有一套更为适用的规则或者其系统规格，前期的详细设计能为我们后期维护优化节约大量的精力。在我们实际的经验中，发现大部分问题（分片严重超规格，单个分片超大，索引mapping设置不合理等问题）都是由于数据的前期规划不够，大大增加了后期整改和优化的难度和成本。
在进行数据规划之前，首先要对数据有充分的了解，包括不限于：
l 数据量有多大，包括总量，增量，以及未来的趋势？
l 数据的生命之旅是怎么样的，即从写入到删除的过程？
l 我们期望从数据里面挖掘出什么，即数据是用来做什么的？
1.2 合理的规格
常见的系统规格如下所示：
单Elasticsearch集群实例数 | 建议控制在300个EsNode实例范围内 |
单Elasticsearch集群支持的最大shard数 | 建议控制在5万以内 |
单EsNode实例，最大shard数 | 建议控制在500以内 |
单shard支持存储的数据量 | 建议单个shard大小20-30GB |
单EsNode实例，最大存储量 | 建议单个EsNode存储数据5TB以内 |
单index分片总数 | 建议控制在EsNode实例个数的2倍以内 |
单index字段个数 | 建议控制在1024个字段范围内 |
单批次查询返回的数据量 | 建议控制在10000以内 |
1.3 分片如何规划
每个分片都可以处理索引和查询请求，在设定分片数目时，可从以下几个方面考虑：
l 建议单个分片保存的数据量在20GB左右，最大不超过30GB，过大的分片会降低查询以及索引恢复的性能。
l 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。
l 为了提升数据可靠性，合理设置副本分片个数，至少设置为1，如果集群的存储空间足够，推荐设置为2。
l 每个node可以支撑的shards个数是有限的，node是物理资源分配的对象，随着shards中数据的增大，shards中的数据在查询时被不断加载到内存，达到一定量时，将会把HeapSize耗尽，导致频繁GC，系统将不能正常工作。推荐1GB内存管理15个shard，以一个Elasticsearch实例内存最大31G为例，单实例管理的shard数保持在500以内。
l 配置total_shards_per_node参数，让分片更加均匀的分布在各个实例上。表示限制每个实例上分布该该索引的分片最大个数，如2，即表示每个实例上最多分布2个该索引的分片。
l 说明：total_shards_per_node参数值=索引总分片数/数据实例数（向上取整）。
