本文主要针对目前的容量规划以及性能测试两方面来进行阐述

容量规划

shard 的作用。shard 是 es 实现分布式特性的基石，文档在索引进 es 时，es 会根据一个路由算法，将每一个文档分配到对应的 shard 上。每个 shard 实际对应一个 lucene index。每个shard最多存储 2^31 个文档，即 20亿。这是 lucene 设计决定的。但随着 shard 体积的增大，其查询效率会下降，而且数据迁移和恢复的成本也会增高。官方建议单个 shard 大小不要超过 50GB。
shard数过小不一定好，如果数据量很大，导致每个 shard 体积过大，会影响查询性能。 因为 es 的每次查询是要分发给所有的 shard 来查询，然后再对结果做聚合处理，如果 shard 数过多也会影响查询性能。因此 shard 的数量需要根据自己的情况测出来。
官方文档有一节关于容量规划的章节，链接地址，其给出的步骤如下：

  1. 使用生产环境的硬件配置创建单节点集群
  2. 创建一个只有一个主分片无副本的索引，设置相关的mapping信息
  3. 将真实的文档导入到步骤 2 的索引中
  4. 测试实际会用到的查询语句

测试的过程中，关注相关指标数据，比如索引性能、查询性能，如果在某一个点相关性能数据超出预期值，那么此时的 shard size大小便是符合预期的单个 shard size的大小。通过下面的计算公式可以确定一个 index 需要设定的 shard 数量。

shard数 = index 的数据总大小/单个shard size的极限值

比如测出单个 shard size 最大为 20 GB，而预测该索引数据最大量在1年或者2年内不会超过 200GB，那么的 shard 数就可以设置为10。

测试报告模版输出

说明

  • 以下的所有指标均指的是某台机器的峰值
  • 机器配置

cpu:12 core，32G，ES 分配JVM内存18G
3台虚拟机，master、data共用
shard:5，replica:1，Indices：20，Documents：2000

  • 试验时间：2019-4-20
  • 每次试验时间 >5 minute
  • 2.2M相当于6400条doc（每一条doc15个字段，其中13个long字段，1个long型数组，数组里边元素1到2个，一个text类型字段，250个字符以下）
  • 所有数据均来自 restful api : _nodes/stats

    实验数据

    | 序号 | Index Rate (/s) | Serach Rate (/s) | JVM Heap (GB) | Index Memory (KB) | System Load | Latency (ms) | 并发数 | bulk data size | | —- | —- | —- | —- | —- | —- | —- | —- | —- | | 1 | 索引速率 | 查询速率 | 节点JVM堆情况 | index内存大小 | cpu负载 | 延迟，分为索引和查询 | 并发请求次数 | 批量操作大小 |

结论

仅仅针对上述的所有条件成立的情况下

  1. 索引的速度希望在Xs以下，那选择每次bulk XXK左右，此时较好；

  2. 根据以上各种组合条件可以分析较多种情况；

    其余问题方案

  3. 在运维和业务层面如何处理冷数据？

冷数据建议可以采用索引别名的方式建立，具体可参照官网

  1. 如何评估当前集群是符合查询型的要求

评估是否复合查询型要求，这是需要有压测指标进行验证的

  1. 当数据达到6T的时候有哪些方案可以处理集群数据

容量规划是一个长期工作，可参考正文给出的方案