干货 |《深刻理解Elasticsearch》读书笔记
题记
因为以前已经梳理过Elasticsearch基础概念且在项目中实战过Elasticsearch的增删改查、聚类、排序等相关操做，对ES算是有了必定的认知。node
可是，仍然对于一些底层的原理认知模糊，特买来《深刻理解Elasticsearch》过了一遍，将书中一些细节知识点结合官网文档梳理以下。web
1——4章偏应用，跟着敲一遍代码基本就能理解原理。
5——9章偏理论一些。
api
第5章 分布式索引架构
一、如何选择合适的分片和副本数？
目的：规划索引及配置，适应应用的变化。缓存
正确认知：分片数索引建立后不能够修改，副本数索引建立后能够经过API随时修改。安全
多副本的缺点：额外副本占据了额外的存储空间，构建索引副本的开销也随之增大。bash
同时要注意：若是不建立副本，当主分片发生问题时，可能会形成数据的丢失。服务器
配置参考：最理想的分片数量应该依赖于节点的数量。微信
参考公式：所需的最大节点数 = 分片数 *（副本数+1）
举例：你计划5个分片和1个副本，那么所须要的最大的节点数为：5*（1+1）=10个节点。网络
二、可不能够基于时间构建索引？
目的：选择感兴趣的索引上进行查询，历史索引（时间比较久）的按期删除。
正确操做方法：经过名称为logs_2017_01, logs_2017_02,…..logs_2017_12来构建索引。数据结构
第6章 底层索引控制
一、什么是段？
Elasticsearch中的每一个分片包含多个segment（段），每个segment都是一个倒排索引；在查询的时，会把全部的segment查询结果汇总归并为最终的分片查询结果返回。
在建立索引的时候，ES会把文档信息写到内存bugffer中（为了安全，也一块儿写到translog），定时（可配置）把数据写到segment缓存小文件中，而后刷新查询，使刚写入的segment可查。
虽然写入的segment可查询，可是尚未持久化到磁盘上。所以，仍是会存在丢失的可能性的。因此，ES会执行flush操做，把segment持久化到磁盘上并清除translog的数据（由于这个时候，数据已经写到磁盘上，再也不须要了）。
参考：http://t.cn/RjKOMv1
二、什么是段合并？
因为自动刷新流程每秒会建立一个新的段，这样会致使短期内的段数量暴增。而段数目太多会带来较大的麻烦。
1）消耗资源：每个段都会消耗文件句柄、内存和cpu运行周期；
2）搜索变慢：每一个搜索请求都必须轮流检查每一个段；因此段越多，搜索也就越慢。
ES经过在后台进行段合并来解决这个问题。小的段被合并到大的段，而后这些大的段再被合并到更大的段。
三、段合并作了什么？
段合并的时候会将那些旧的已删除文档从文件系统中清除。
被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
启动段合并不须要你作任何事。进行索引和搜索时会自动进行。
1）当索引的时候，刷新（refresh）操做会建立新的段并将段打开以供搜索使用。
2） 合并进程选择一小部分大小类似的段，而且在后台将它们合并到更大的段中。这并不会中断索引和搜索。
四、为何要进行段合并？
1）索引段的个数越多，搜索性能越低而且消耗更多的内存；
2）索引段是不可变的，你并不能物理上从中删除信息。（能够物理上删除document，但只是作了删除标记，物理上并无删除）
3）当段合并时，这些被标记为删除的文档并无被拷贝至新的索引段中，这样，减小了最终的索引段中的document数目。
五、段合并的好处是什么？
1）减小索引段的数量并提升检索速度；
2）减小索引的容量（文档数）——段合并会移除被标记为已删除的那些文档。
六、段合并可能带来的问题？
1）磁盘IO操做的代价；
2）速度慢的系统中，段合并会显著影响性能。
第7章 管理Elasticsearch
一、有了副本机制为何还须要集群备份？
Elasticsearch 副本提供了高可靠性；它们让你能够容忍零星的节点丢失而不会中断服务。
可是，副本并不提供对灾难性故障的保护。对这种状况，你须要的是对集群真正的备份——在某些东西确实出问题的时候有一个完整的拷贝。
二、集群如何备份？
使用 snapshot API备份你的集群。
它会拿到你集群里当前的状态和数据而后保存到一个共享仓库里。这个备份过程是”智能”的。
ES5.6集群备份官网参考： http://t.cn/RjKEH9G
三、集群备份分类？
完整备份——你的第一个快照会是一个数据的完整拷贝。
增量备份——全部后续的快照会保留的是已存快照和新数据之间的差别。随着你不时的对数据进行快照，备份也在增量的添加和删除。这意味着后续备份会至关快速，由于它们只传输很小的数据量。
四、集群能够备份到哪里？
要使用这个功能，你必须首先建立一个保存数据的仓库。有多个仓库类型能够供你选择：
- 共享文件系统，好比 NAS
- Amazon S3：亚马逊Web云服务
- HDFS (Hadoop集群分布式文件系统)
- Azure Cloud：微软云平台
五、备份操做API？
PUT _snapshot/my_backup
{
"type": "fs",
"settings": {
"location": "/mount/backups/my_backup"
}
}
注意：共享文件系统路径必须确保集群全部节点均可以访问到。
第8章 提升性能
一、什么状况下会出现堆内存泄漏？
若是没有足够的堆内存来供你的应用在堆上建立新对象，JVM会抛出一个OutOfMemeory异常，这是一个内存出了问题的迹象，要么是没有足够的内存给它，要么是有内存泄漏，致使没有释放再也不使用的对象。
二、推荐的性能测试工具？
1）JMeter
2）ab（Apache基准测试工具）
三、ES须要优化的缘由？
1）硬件问题——如机械硬盘和固态硬盘；
2）不良的数据结构；
3）糟糕的查询设计——如wildcard模糊匹配很长的字符串。
四、后台什么在运行致使CPU飙升？如何排查？
热点线程APi能向你提供查找问题根源所必需的信息。
GET /_nodes/hot_threads?pretty
五、如何扩展集群？
1）垂直扩展
向Elasticsearch集群添加更多的资源。
制约因素——如：JVM最大支持31GB物理内存。
2）水平扩展
索引多分片、多副本，集群中分散处理之。
优势：下降运行集群的成本。
版本升级后（如5.X升级到6.0），确保服务仍然可用。
六、集群架构设计考虑因素？
当你在设计架构、决定节点数量、有多少个索引以及每一个索引的分片数量时，你须要把能接受的出现故障的节点数量考虑进去。
固然了，你还须要考虑性能，只不过冗余和高可用应该是进行扩展时的一个因子。
七、大规模集群节点角色如何设定？
为了有一个彻底容错和高可用的集群，咱们应该区分节点，为每一个节点一个设计好的角色，角色分类以下：
1）路由节点或查询聚合节点；
发送子查询到其余节点，收集和合并结果，以及响应发出查询的客户端。
node.master: false
node.data: false
2）数据节点；
node.master: false
node.data: true
3）候选主节点。
node.master: true
node.data: false
http.enabled: false
候选主节点禁用Http协议是为了不意外地在这些节点上进行查询。这样候选主节点相比于数据节点和路由节点可使用更少的资源，能够确保它们仅仅被用来处理和主节点相关的工做。
八、高负载场景Elasticsearch优化的常规建议？
这里是建议，不是准则。
（1）选择正确的存储
如：选择默认的default存储类型。
（2）按需设定刷新频率
索引刷新频率定义：文档须要多长时间才能出如今搜索结果中。
正确认知：
1）刷新频率越短，查询越慢，且索引文档的吞吐率越低。
2）默认刷新频率：1s刷新一次。
3）无限的增长刷新时间是没有意义的，由于超过必定的值（取决于你的数据负载和数据量）以后，性能提高变得微乎其微。
（3）线程池优化
线程池优化的必要场景：你看到节点正在填充队列而且仍然有计算能力剩余，且这些计算能力能够被指定用于处理待处理的任务。
（4）调整合并过程
index.merge.policy.mery_factory低于默认值10，会致使更少的段，更低的RAM消耗，更快的查询速度和更慢的索引速度；
若大于10，致使索引由更多的分段组成，更高的RAM消耗，更慢的查询速度和更快的索引速度。
（5）合理数据分布
高索引量的使用场景：把索引分散到多个分片上来下降服务器CPU和I/O子系统的压力。
若是你的节点没法处理查询带来的负载，你能够增长更多的ES节点，并增长副本的数量，因而主分片的物理拷贝会部署到新增节点上。这样会使得文档索引慢一些，可是会给你同时处理更多查询的能力。
9.高负载、高查询频率场景的建议
（1）启动过滤器缓存和分片查询缓存
过滤器缓存配置：indices.cache.filter.size
分片查询缓存配置：indices.cache.query.enable
（2）优化查询语句结构
书本中的过滤器已再也不使用5.X以及更高版本。
但，依然能够优化查询语句，返回核对查询一样语句返回时间，进行权衡优化。
（3）使用路由
有着相同路由值的数据都会保存到相同的分片上。
（4）并行查询
建议数据平均分配，多个节点能够有相同的负载。
（5）字段数据缓存和断路
当使用聚合和排序等字段数据缓存相关操做时，遇到了内存相关的问题（内存泄漏或者GC停顿），能够考虑使用 doc value。
（6）控制size和shard_size
主要针对聚合操做。
增长size和shard_size能使得聚合结果更准确，代价是：更多的网络开销和内存使用；
减小size和shard_size能使得聚合不那么精确，代价是：网络开销小和内存使用率低。
十、高负载、高索引吞吐量场景
（1）批量索引
批量索引代替逐个索引文档。
（2）doc values和索引速度的取舍
一方面：咱们只关心更高的索引速度和更大的索引吞吐量，能够考虑不适用doc values。
另外一方面：若是有大量的数据，为了使用聚合和排序功能而不产生内存相关问题，惟一选择——使用 doc values。
（3）控制文档字段
方式一：_source 控制字段输出；
方式二：禁用_all。
减小文档的大小和其内文本字段的数量会让索引稍快一些。
（4）索引的结构和副本
1）主分片部署到全部的节点上，以便：并行的索引文档，加快索引的速度。
2）过多的副本致使索引速度降低。
（5）调整预写日志。
（6）存储优化
1）资金充足，建议购买SSD——缘由：速度优点明显；
2）资金不足，考虑ES使用多个数据路径。
3）不要使用共享或者远程的文件系统保存索引——缘由：速度慢，总体性能降低。
（7）索引期间的内存缓存
建议给每一个索引期间生效的分片分配512MB内存。
indices.memeory.index_buffer_size是设置节点的，而不是分片。
小结
书中基于ES1.X版本的一些优化细节，可能在5.X、6.X甚至更高版本中有所不一样，须要根据实战须要、并结合最新官网文档更新相关知识。
ES仍然有很长的路要走，坚持、加油！
《深刻理解Elasticsearch》可搜索版下载：
连接: https://pan.baidu.com/s/1i5gpCwP 密码: dm5q
——————————————————————————————————
更多ES相关实战干货经验分享，请扫描下方【铭毅天下】微信公众号二维码关注。
（每周至少更新一篇！）
和你一块儿，死磕Elasticsearch！
——————————————————————————————————
2017.11.16 19:33 于家中床前
做者：铭毅天下
转载请标明出处，原文地址：
http://blog.csdn.net/laoyang360/article/details/78554610 若是感受本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写做最大的动力，谢谢！