关于elasticsearch:ES性能调优与其它特性

一，写优化

1. 批量提交。每次提交的数据量为多大能力达到最优，受文件大小，数据类型，网络状况，集群状态等因素影响，一般来说一次批处理的数据大小应从 5M-15M 开始逐步减少直到没有性能提花为止。
2. 优化存储设置。尽量应用固态硬盘(solid state disk)
3. 正当应用段合并。段合并的计算宏大，会耗费大量的 I /O，为了避免因段合并影响搜寻性能，咱们须要管制正当的合并速度，可通过参考进行配置
4. 缩小 refresh 次数。这个须要依据理论状况来看，如果咱们对搜寻的时效性不高，则能够减少提早 refresh 的工夫，这样还能够缩小段合并的数量。
5. 缩小 flush 的次数。这个同样须要结合实际状况来看，当 translog 的数量达到 512M 或 30 分钟时，会触发一次 flush，磁盘长久化比拟耗资源，咱们能够通过参考设置正当的值
6. 缩小正本数。ES 正本数能够保障集群可用性，也能够减少搜寻的并发数，但却会重大升高写索引的效率，因为在写索引时须要把整个文档的内容都发给正本节点，而所有的正本节点都须要把索引过程反复进行一遍。所以正本数不可过多。

二，读优化

1. 防止大后果集和深翻页。如果有 N 个分片，协同节点须要收集每个分片的前 from+size 条数据，而后将收集到的 Nx(from+size)条数据合并后再进行一次排序，最初从 from+ 1 开始返回 size 条数据。只有 N,from,size 其中有个值很大，这样的查问会耗费很多 CPU，效率低下。为解决这类问题，ES 提供了 scroll 和 scroll-scan 这两种形式。
   1) scroll 形式。与 search 申请每次返回一页数据不同，scroll 是为检索大量的后果（甚至所有的后果）而设计的，比方，咱们有一个批量查问的需要，要查问 1～100 页的数据，每页有 100 条数据，如果用 search 查问，则每次都要在每个分片上查问得分最高的 from+size 条数据，而后协同节点把收集到的 n×（from+size）条数据合并起来再进行一次排序。接着从 from+ 1 开始返回 size 条数据，并且要反复 100 次，随着 from 的增大，查问的速度越来越慢。
   但 scroll 的思路是：在各个分片上一次查问 10000 条数据，协同节点收集 n×10000 条数据，而后合并、排序，将排名前 10000 的后果以快照模式存储，最初应用相似数据库游标的模式逐次取得局部数据。这种做法的益处是缩小了查问和排序的次数。scroll 在第一次查问时除了返回查问到的后果外，还会返回一个 scroll_id，它是下次申请的参数。scroll 也分 query,fetch 两个阶段，第一阶段 query 先将所有符合条件的 doc_id 查问并暂存；第二阶段 fetch 依据 doc_id 与 scroll_id 以游标的形式获取文档。须要留神的是 scroll 会应用快照的模式暂存数据，后续一段时间内数据如果有批改是感知不到的，所以它不适宜实时性要求高的场景
   2) scroll-scan 形式。scroll 在首次查问时须要进行文本类似度计算和排序，这个过程也比拟耗时，scroll-scan 则敞开了这一过程。scroll-scan 的特点是不做文本类似度计算；不反对聚合
2. 抉择适合路由
   在多分片的 ES 集群下，查问大抵分如下两种。
   1) 查问条件中蕴含了 routing 信息。查问时能够依据 routing 间接定位到其中的一个分片，而不须要查问所有分片，再通过协调节点二次排序。
   2) 如果查问条件不蕴含 routing，整个查问过程就分 scatter 与 gather 两个过程。
   scatter（散发）：在申请达到协调节点后，协调节点将查问申请散发到每个分片上
   gather（聚合）：协调节点收集在每个分片上实现的搜寻后果，再将收集的后果集进行从新排序，返回给用户。

三，堆大小的设置

ES 默认的堆内存大小是 1GB，因为 ES 是比拟耗内存的利用，咱们能够将这个值调大一点。-Xms 与 -Xmx 设置一样。内存调配还有两个准则：

1. 最好不要超过物理内存的 50%。ES 底层是 lucene 实现的，因为 lucene 段的不变性，所以咱们不必思考数据的变动，这对缓存十分敌对，操作系统能够将这些文件缓存在操作系统的文件缓存零碎 (filesystem cache) 中而非堆内存中，如果超过物理内存过多，则留给文件缓存零碎就不多了
2. 堆内存最好不要超过 32G。这是因为在 64 位操作系统中，指针自身会变大，会有更大的空间节约在指针自身上。

性能调优就写到这里，上面看下 ES 里的一些个性，比方主节点选举，如何防止脑裂。

1. 角色隔离
   因为节点默认的是 node.master 和 node.data 都为 true，所以咱们往往会让 Master 节点也担当了 Data 节点的角色。Elasticsearch 集群中的 Data 节点负责对数据进行增、删、改、查和聚合等操作，所以对 CPU、内存和 I / O 的耗费很大，有可能会对 Master 节点造成影响，从而影响整个集群的状态。

在搭建集群时，特地是比拟大的集群时，咱们应该对 Elasticsearch 集群中的节点做角色上的划分和隔离。咱们通常应用几个配置比拟低的虚拟机来搭建一个专门的 Master 集群。在集群中做角色隔离是一件非常简单的事件，只需在节点的配置文件中增加如下配置信息即可。

候选主节点：

node.master =true

node.data=false

数据节点：

node.master =false

node.data=true

2. master 选举
   前提条件：
   1) 只有是候选主节点 (master:true) 的节点能力成为主节点
   2) 最小主节点数(min_master_nodes) 的目标是避免脑裂
   ES 的选举是 ZenDiscovery 模块负责的，次要蕴含 Ping（节点之间通过这个 RPC 来发现彼此）和 Unicast（单播模块蕴含一个主机列表以管制哪些节点须要 ping 通）这两局部。选举流程大抵如下：
   第一步：确认候选主节点数是否达标
   第二步：对所有候选主节点依据 nodeId 字典排序，每次选举每个节点都将本人所晓得节点排一秩序，而后选出第一个 (第 0 位) 节点，暂且认为它是 master 节点
   第三步：如果对某个节点的投票数达到肯定的值（候选主节点数 /2+1）并且节点本人也选举本人，那这个节点就是 master。否则从新进行直到满足下面条件。
3. 防止脑裂
   脑裂是因为网络起因导致在集群中选举出了多个 master，最初导致一个集群被决裂为多个集群。了为避免脑裂，咱们须要在在 Master 集群节点的配置文件中增加参数 discovery.zen.minimum_master_nodes，该参数示意在选举主节点时须要参加选举的候选主节点的节点数（默认值是 1）。咱们通常应该把这个值设置成（master_ eligible_nodes/2）+1，其中 master_eligible_nodes 为 Master 集群中的节点数。这样做既能避免脑裂的景象呈现，也能最大限度地晋升集群的高可用性，因为只有不少于 discovery.zen.minimum_ master_nodes 个候选节点存活，选举工作就能够顺利进行。

参考文章：elasticsearch scroll 查问的原理没太懂
Elasticsearch 之 SearchScroll 原理分析和性能及稳定性优化