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亿,那么就需要调低这个间隔来保证有足够的弹性能应对变化。
- 结合业务特性和性能测试来决定要不要调整间隔。这点更多的是从业务角度来考虑的&