es bucket和metric

1、ES 聚合的核心概念：桶（bucket）和指标（metric）

桶（bucket）: 满足特定条件的文档的集合
指标（metric）: 对桶内的文档进行聚合分析的操作
聚合是由桶和指标组成的。聚合可能只有一个桶，可能只有一个指标，或者可能两个都有。转换成成对应的sql语句如下：

select count() from Table_A group by FieldA
其中：bucket 相当于 group by FieldA --> FieldA 字段内相同的数据，就会被划分到一个bucket中
　　　metric 相当于 count() --> 对每个FieldA bucket中所有的数据计算一个数量

虽然我们可以调大返回size的个数来提高精确度，但是size个数的提升，也意味着有更多的数据会被返回，从而会导致检索性能的下降，这一点是需要找到平衡点的, 为解决这种不精确的统计，可以尝试的方案：
聚合操作在单个shard时是精确的，也就是说我们索引的数据全部插入到一个shard的时候 它的聚合统计结果是准确的。
在索引数据的时候，使用route路由字段，将所有聚合的数据分布到同一个shard即可，这样再聚合时也是精确的。 参见：ES Route
第一种适合数据量不大的场景下，我们直接把数据放在一份索引里面，第二种办法适合数据量比较大的场景下，我们通过业务字段将相同属性的数据路由在同一个shard里面即可，具体使用哪个需要和具体的业务场景相结合。

2. size与shard_size

size参数规定了最后返回的term个数(默认是10个)
shard_size参数规定了每个分片上返回的个数
如果shard_size小于size，那么分片也会按照size指定的个数计算
通过这两个参数，如果我们想要返回前5个，size=5;shard_size可以设置大于5，这样每个分片返回的词条信息就会增多，相应的误差几率也会减小。
上面提到那个例子，如果聚合的key本来就很少，那么它的聚合结果也是准确的，比如按性别，月份聚合，因为这些返回的key，都是有限的，所以结果没问题，但是一旦对分组的个数没法确定，这种情况下出现问题的几率就比较大，跨表或者跨分片聚合其实在任何db系统里面都会存在这种问题，所以我们应该尽量在设计业务时就考虑到这种特殊情况，然后最终做特殊处理。