es使用与原理6 -- 聚合分析剖析

有些聚合分析的算法，是很容易就可以并行的，比如说max

有些聚合分析的算法，是不好并行的，比如说，count(distinct)，并不是说，在每个node上，直接就出一些distinct value，就可以的，因为数据可能会很多，假设图中的协调节点3百万个数据去重后还剩下100万distinct的数据，那么内存需要来存储这100万条数据，这是不可能的

es会采取近似聚合的方式，就是采用在每个node上进行近估计的方式，得到最终的结论，cuont(distcint)，100万，1050万/95万 --> 5%左右的错误率
近似估计后的结果，不完全准确，但是速度会很快，一般会达到完全精准的算法的性能的数十倍

precision_threshold优化准确率和内存开销

brand去重，如果brand的unique value，在100个以内，小米，长虹，三星，TCL，HTL。。。
在多少个unique value以内，cardinality，几乎保证100%准确
cardinality算法，会占用precision_threshold 8 byte 内存消耗，100 8 = 800个字节
占用内存很小。。。而且unique value如果的确在值以内，那么可以确保100%准确
100，数百万的unique value，错误率在5%以内
precision_threshold，值设置的越大，占用内存越大，1000 8 = 8000 / 1000 = 8KB，可以确保更多unique value的场景下，100%的准确
field，去重，count，这时候，unique value，10000，precision_threshold=10000，10000 8 = 80000个byte，80KB

doc value正排索引
搜索+聚合 是怎么实现的？
假设是倒排索引实现的

倒排索引来实现是非常不现实的，因为我们搜索的那个字段search_field 有可能是分词的，这就需要去扫描整个索引才能实现聚合 *** 作，效率是及其低下的。
正排索引结构：
doc2: agg1
doc3: agg2
1万个doc --> 搜 -> 可能跟搜索到10000次，就搜索完了，就找到了1万个doc的聚合field的所有值了，然后就可以执行分组聚合 *** 作了
doc value原理

1、doc value原理

（1）index-time生成

PUT/POST的时候，就会生成doc value数据，也就是正排索引

（2）核心原理与倒排索引类似

正排索引，也会写入磁盘文件中，然后呢，os cache先进行缓存，以提升访问doc value正排索引的性能
如果os cache内存大小不足够放得下整个正排索引，doc value，就会将doc value的数据写入磁盘文件中

（3）性能问题：给jvm更少内存，64g服务器，给jvm最多16g

es官方是建议，es大量是基于os cache来进行缓存和提升性能的，不建议用jvm内存来进行缓存，那样会导致一定的gc开销和oom问题
给jvm更少的内存，给os cache更大的内存
64g服务器，给jvm最多16g，几十个g的内存给os cache
os cache可以提升doc value和倒排索引的缓存和查询效率

2、column压缩

doc1: 550
doc2: 550
doc3: 500

合并相同值，550，doc1和doc2都保留一个550的标识即可
（1）所有值相同，直接保留单值
（2）少于256个值，使用table encoding模式：一种压缩方式
（3）大于256个值，看有没有最大公约数，有就除以最大公约数，然后保留这个最大公约数

重点：
对分词的field，直接执行聚合 *** 作，会报错，大概意思是说，你必须要打开fielddata，然后将正排索引数据加载到内存中，才可以对分词的field执行聚合 *** 作，而且会消耗很大的内存
先修改 字段的fielddata属性为true,再查 就能查找到数据

当然，我们也可以使用内置field(keyword)不分词，对string field进行聚合,如果对不分词的field执行聚合 *** 作，直接就可以执行，不需要设置fieldata=true

分词field+fielddata的工作原理

doc value --> 不分词的所有field，可以执行聚合 *** 作 --> 如果你的某个field不分词，那么在index-time，就会自动生成doc value --> 针对这些不分词的field执行聚合 *** 作的时候，自动就会用doc value来执行
分词field，是没有doc value的。。。在index-time，如果某个field是分词的，那么是不会给它建立doc value正排索引的，因为分词后，占用的空间过于大，所以默认是不支持分词field进行聚合的
分词field默认没有doc value，所以直接对分词field执行聚合 *** 作，是会报错的

对于分词field，必须打开和使用fielddata，完全存在于纯内存中。。。结构和doc value类似。。。如果是ngram或者是大量term，那么必将占用大量的内存。。。

如果一定要对分词的field执行聚合，那么必须将fielddata=true，然后es就会在执行聚合 *** 作的时候，现场将field对应的数据，建立一份fielddata正排索引，fielddata正排索引的结构跟doc value是类似的，
但是只会讲fielddata正排索引加载到内存中来，然后基于内存中的fielddata正排索引执行分词field的聚合 *** 作

如果直接对分词field执行聚合，报错，才会让我们开启fielddata=true，告诉我们，会将fielddata uninverted index，正排索引，加载到内存，会耗费内存空间

为什么fielddata必须在内存？因为大家自己思考一下，分词的字符串，需要按照term进行聚合，需要执行更加复杂的算法和 *** 作，如果基于磁盘和os cache，那么性能会很差

我们是不是可以预先生成加载fielddata到内存中来？？？
query-time的fielddata生成和加载到内存，变为index-time，建立倒排索引的时候，会同步生成fielddata并且加载到内存中来，这样的话，对分词field的聚合性能当然会大幅度增强

在ES站上做OS站,运行没有问题,但是C/S结构,就不建议在ES上运行服务器项目,如果ES启动服务器,就会造成客户机数据混乱,即使关闭ES,也会在数据库上留下信息,造成错误建议用模拟OS运行

elasticsearchyml 服务配置文件

参数：

配置es的集群名称，默认是elasticsearch，es会自动发现在同一网段下的es，如果在同一网段下有多个集群，就可以用这个属性来区分不同的集群。

设置默认索引分片个数，默认为5片。Since elasticsearch 5x index level settings can NOT be set on the nodes configuration like the elasticsearchyaml, in system properties or command line argumentsIn order to upgrade all indices the settings must be updated via the /${index}/_settings API Unless all settings are dynamic all indices must be closed

in order to apply the upgradeIndices created in the future should use index templates

to set default values

Please ensure all required values are updated on all indices by executing:

curl -XPUT ' >

1查询性能不同。当实时建立索引的时候,solr会产生io阻塞,而es则不会,es查询性能要高于solr;

2检索效率不同。在不断动态添加数据的时候,solr的检索效率会变的低下,而es则没有什么变化;

3管理方式不同。Solr利用zookeeper进行分布式管理,而es自身带有分布式系统管理功能。Solr一般都要部署到web服务器上;

4文件格式不同。Solr支持更多的格式数据[xml,json,csv等],而es仅支持json文件格式;

工程测试版CPU一般型号后面都会加上ES标识；也就是说ES版CPU可以看成工程样品版CPU，可能会有某些缺陷；
QS版CPU严格来说也属于ES版的，QS版是CPU厂商在该型号CPU正式上市以前，提供给商家或测试人员测试用的；
通常来说，QS版CPU质量上都会比ES版好得多，毕竟不像ES版本本来就是用来做各种超频和热功耗等的极限测试用的，更多的可能是用来测试整个平台的稳定性的，因此降低了一定程度上的对CPU本身的体制造成永久是损坏的概率。
QS是英文Qualification Sample的缩写，即品质确认样品。 QS版，也叫ES正显版，一般是最后一版ES。一般其步进和型号，都较正式版一模一样了，其稳定性不存在任何风险，在所有测试版中，属最好的版本，其货源也不像ES那样是免费供应，是INTEL向工厂收取少量费用卖出的，价格仍低于正式版不少，稳定性各方面和正式版一样，对不愿承担一点点风险，又追求性价比的来讲，是最好的选择。

---