Elasticsearch最佳实践之Index与Shard设计

  Index与Shard，这两个概念在《Elasticsearch最佳实践之核心概念与原理》一文有详细的介绍，分别对应了Elasticsearch的两种数据组织方式：逻辑组织和物理组织。逻辑层面上，Index与业务数据的结构、类型、使用方式等息息相关；而物理层面上，Shard关系到数据在不同机器上的分布情况。作为专栏的第三篇，本文主要探讨实际应用中Index与Shard的设计方法。所谓设计，即通过合理组合Elasticsearch的特性与功能来完成业务需求，尽可能实现业务的灵活性，保证系统的高性能与稳定性。当然，前提是得先知晓这些特性与功能以及何时使用。本文将从以下几个方面进行介绍，写作背景是Elasticsearch 5.5。（文中使用的一些示例和图片来自于笔者在2018年Elasticsearch南京Meetup中的幻灯片。）

• 基于时间的Index设计
• Mapping设计技巧
• 巧妙的Alias
• Shard分配原则
• 整体思路

1. 基于时间的Index设计

  Index设计时要考虑的第一件事，就是基于时间对Index进行分割，即每隔一段时间产生一个新的Index。为什么要这样做呢？因为现实世界的数据是随着时间的变化而不断产生的，切分管理可以获得足够的灵活性和更好的性能。

• 如果数据都存储在一个Index中，很难进行扩展和调整，因为Elasticsearch中Index的某些设置在创建时就设定好了，是不能更改的，比如Primary Shard的个数。而根据时间来切分Index，则可以实现一定的灵活性，既可以在数据量过大时及时调整Shard个数，也可以及时响应新的业务需求。
• 大多数业务场景下，客户对数据的请求都会命中在最近一段时间上，通过切分Index，可以尽可能的避免扫描不必要的数据，提高性能。

  当然，并不排除某些特定的业务场景下，不用对Index进行切分管理，比如一个固定的数据集或者一个增长非常缓慢的数据集。大多数情况下，笔者都建议按照时间进行分割。那么，要考虑的第二件事就是，按照什么规则来设定切分的间隔呢？根据上面的分析，自然是时间越短越能保持灵活性，但是这样做就会导致产生大量的Index，而每个Index都会消耗资源来维护其元信息的，因此需要在灵活性、资源和性能上做权衡。建议按照如下几点来思考：

• 常见的间隔有小时、天、周和月。先考虑总共要存储多久的数据，然后选一个既不会产生大量Index又能够满足一定灵活性的间隔。比如，你需要存储6个月的数据，那么一开始选择“周”这个间隔就会比较合适。
• 考虑业务增长速度。假如业务增长的特别快，比如上周产生了1亿数据，这周就增长到了10亿，那么就需要调低这个间隔来保证有足够的弹性能应对变化。
• 结合业务特性和性能测试来决定要不要调整间隔。这点更多的是从业务角度来考虑的&