干货 | Elasticsearch 趋势科技实战分享笔记

少啰嗦，直接看东西。

一、Elasticsearch 索引的设计

1.1 单一索引仍是基于时间的索引？

单一索引的问题：
1）不能更新Mapping。
好比：主分片数不能够修改（除非reindex）。
2）没法灵活、快速地扩展。
3）更适合固定、小型数据集。

基于时间的索引面临的问题：
1）如何肯定间隔？
数据量
变动频率
默认尝试每周为单位分割——建议
2）如何实施？
索引模板

1.2 定义索引注意事项

举例：

{
    "facet_internet_access_minute":{ "template":"ce-index-access-v1-*", "order":0, "settings":{ "number_of_shards":5 }, "aliases":{ "{index}-query":{ } }, "mappings":{ "es_doc":{ "dynamic":"strict", "_all":{ "enabled":false }, "_source":{ "enabled":false }, "properties":{ "CLF_Timestamp":{ "type":"long" }, "CLF_CustomerID":{ "type":"keyword" }, "CLF_ClientIP":{ "type":"ip", "ignore_malformed":true } } } } } }

注意1：不要在一个索引中定义多个type。

6.X版本已经不支持，7.X版本完全不支持。
扩展问题：5.X版本的父子文档实际实现中是一个索引中定义了多个type，到了6.X中实现方式改变为：join方式。

注意2：将Set _source设置为false。

假设你只关心度量结果，不是原始文件内容。
将节省磁盘空间并减小IO。
这个点，须要结合实际的业务场景具体问题具体分析。
举例：

“_source”:{
“enabled”:false
},

注意3：将_all设置为false。

假设你确切地知道你对哪一个field作查询操做？
能实现性能提高，缩减存储。
举例：

“_all”:{
“enabled”:false },

注意4：设置dynamic = strict。

假设你的数据是结构化数据。
字段设置严格，避免脏数据注入。
举例：

“dynamic”:”strict”,

注意5：使用keyword类型

假设你只关心彻底匹配
提升性能和缩小磁盘存储空间
举例：

“CLF_CustomerID”:{
“type”:”keyword”
},

注意6：使用别名

如何在不停机的前提从一个索引切换到另外一个索引？

举例：

“aliases”:{
“{index}-query”:{
}

或者你经过head插件建立。

二、Elasticsearch分片分配原则

社区和QQ群中常常被问到的问题：

• 1）应该分几个索引、几个分片？
• 2）每一个分片大小如何设置？
• 3）副本多少如何设置？

这里，明确给出实操可行的6个步骤。

步骤1：定义索引。

思考索引中要大体有哪些字段？
最好能列一个Excel表统计一下，包含但不限于：
序号、名称、类型、做用、备注。
以上对计算单条数据大小也有用。

步骤2：评估数据量。

评估方法举例：
1分钟有100条数据，1天=100*60*24=144000条。
1月=144000条*30天=432W条数据。
1年=432W*12=5184W条数据。
假设要保存2年，共=10368W条数据。
假设每条数据20KB，共须要存储：10368W*20/1024/1024/1024=1.977TB。

步骤3：评估索引大小和磁盘空间。

步骤4：计算分片数。

细节考虑点：
一、每一个分片大小应小于30GB。
二、分片数量= k *数据节点数目（k = 一个足够小的整数，举例：1,2,3）
三、假设你有一个小的索引，而且你有集群中有足够的节点，请尝试使用默认值分片数5。

步骤5：评估索引数和类型。

（此处可能会有屡次反馈迭代）

三、数据去重的思考？

方法1：指定惟一id

缺点：
一、惟一值没法压缩，不利于存储。
二、存在高基数问题。

方法2：用聚合方法实现

步骤1：全部文档加一个Hash值；
步骤2：检查重复；

GET *_index/_search {
“size”:0,
“aggs”:{
“duplicate”:{
“terms”:{
“field”:”hash”,
“min_doc_count”:2,
“size”:5000
},
“aggs”:{
“documents”:{
“top_hits”:{
“size”:2
}
}
}
}
} }

步骤3：批量删除步骤2中的重复id。
以上步骤，不影响写入，能够实现异步。

缺点：
一、存储量大（尤为超过3亿条+）；
二、随着数据量增长，聚合受影响，愈来愈慢。
三、存在高基数问题。

方法3：用distinct query实现

深刻方法待进一步探讨。

四、小结

以上内容是Elasticsearch南京分享会20180630上的分享核心笔记。
具体PPT地址：https://elasticsearch.cn/slides/115
很受用的分析步骤和实战经验，实战中均可以用得上。

加入知识星球，更短期更快习得更多干货！

2017-07-03 00:30 思于家中床前

做者：铭毅天下
转载请标明出处，原文地址：
https://blog.csdn.net/laoyang360/article/details/80892392 若是感受本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写做最大的动力，谢谢！