Elasticsearch学习笔记

前言

• 为何es查询和聚合都这么快？底层是如何实现的？
• 数据在es集群中如何存储的？如何作到自动分布式的？
• 为何es的主分片数设置了以后就不能调整，而副本分片数能够调整？
• 如何优化索引方式和查询方式，有效利用缓存，提升查询效率？
• 若是保证不停服的状况下，平滑升级或扩容？
• 如何优化查询效率？

相信看完Elasticsearch权威指南这本书，全部疑问都将获得解答

一. 基本概念

1. 分片

• 最小级别的工做单元，保存索引中一部分数据。是一个Lucene实例，自己就是一个完整的搜索引擎。可是应用程序不会直接与分片通信。
• 能够想象成容器，节点间数据迁移以分片为单位
• 分为主分片和副分片（主分片的副本）
• 索引建立的时候，主分片的数量就固定了，可是副本分片数量可调整
• 默认一个索引分配5个主分片
• 主分片所在节点挂掉后，从新选举主节点，并将副分片升级为主分片
• 故障节点从新启动后，会同步故障期间未同步到到数据

2. 文档

• 根对象序列化成json对象
• 每次对文档的操做（包括修改，删除），_version都会加一
• 文档是不可修改的。update是先删除，再新建一个新的
• 删除的文档并不会被当即移除，只是标记为删除。以后后台再清理
• 本身设置文档的版本：添加version_type=external参数

3. 冲突解决

• 经过版本号实现乐观锁解决冲突问题

4. 文档元数据

• _index 文档存储的地方
• _type 文档表明的对象的类（7.x的版本将去掉_type)
• _id 文档的惟一标识。可手动设置也可自动生成（22位长）

5. 集群架构图

两个节点，三个主分片，一个副分片的效果图

扩展到三个节点到效果图

6. 集群状态

集群状态是一个数据结构，集群状态存在每一个客户端中。保存如下信息

• 级别设置
• 集群节点
• 索引以及相关的映射，别名等信息
• 索引的分片，以及分配的节点

集群状态-status

• green：全部主分片和副分片都已经分配
• yellow：全部主分片都已分配，至少有一个副本分片没有分配
• red：至少一个主分片（或所有副分片）缺失

二. 集群工做原理

1. 数据是如何在分布式系统存储的

• 文档经过路由存放到分片
• 经过如下算法得出该文档存储时的分片编号

  shard = hash(routing) % number_of_primary_shards
  复制代码

• routing是任意字符串，默认是_id
• 主分片的数量不可改变，不然以前的路由失效，文档就找不到了
• 自定义路由能够保证有关联性的文档被保存在同一个分片

2. 主分片和复制分片如何交互？

• 请求可以被发送给任意节点
• 每一个节点都有能力处理任意请求
• 每一个节点都知道任意文档所在节点（保存的集群状态），并转发请求
• 发送请求时最好循环每一个节点以负载均衡

2.1 write操做（新建、删除、索引）

顺序步骤

• 客户端发送请求（新建，删除，索引）到node1节点
• 节点使用hash算法得出分片编号0，由于分片0在节点3，将请求转发到节点3
• node3成功保存数据到主分片，若是成功，转发请求到node1和node2到副节点
• 全部复制节点成功，发送成功回复到请求节点1，节点1再返回给客户端

可调的参数

• replication：默认为sync，主分片获得复制分片成功响应才返回。async表示请求在主分片执行成功就返回，依旧转发请求到副分片，不过不知道成功与否
• consistency：主分片尝试写入时，须要规定数量（quorum）或过半的分片可用。可为one，all，quorum（默认）。quorum只有在number_of_replicas大于1时才生效

  int((primary[老是1] + number_of_replicas) /2 + 1)
  复制代码

• timeout：分片不足时，等待时间。默认1min

2.2 read操做

• 客户端发送get请求到node1
• 节点使用hash算法，获得文档所属到主分片为0分片
• 找到分片0的副分片所在节点为node1，node2，node3
• 经过某种策略选定某个副分片节点，好比node2
• node2返回文档给node1
• 而后node1返回给客户端

2.3 update操做

顺序步骤

• 客户端给node1发送更新请求
• 经过哈希算法获得主分片位置，转发请求到node3
• node3检索出文档，修改_source字段到json文档，而后重建索引。若是有其余进程修改了文档，它以retry_on_conflict设置的次数重复这一步，都未成功则放弃
• node3更新成功则发送整个新文档（并非修改请求）到node1和node2的复制节点重建索引，都成功则返回给node1，再返回给客户端

2.4 多文档模式

mget 多文档read

• 客户端发送mget请求给node1
• node1为每一个分片构建一个请求，并转发到对应分片所在节点
• 当全部回复被接收，node1组合这些响应，返回给客户端

bulk 多文档write

• 客户端向node1发送请求
• node1为每一个分片构建批量请求，而后转发到这些主分片上
• 主分片按序执行，每个完成时，发送到副分片上
• 全部操做都完成后节点整理响应返回给客户端

3. 索引是如何创建的

3.1 基本概念

• 映射（mapping）：用于字段确认，每一个字段匹配为确认的数据类型
• 分析（analysis）：全文文本分词，以创建倒排索引
• 倒排索引：由文档中单词的惟一列表和单词在文档中的位置组成，用于快速检索结果而设计

3.2 分析（analysis）

分析的过程

• 分析由分析器（analyzer）完成
• 分析过程先标记一段文本为单独的词（item）
• 而后标准化（好比所有转为小写）item，以提升搜索性
• 分析的详情可经过_analyze API查看

分析器包括的组件

es提供不少可用直接使用的组件，可自定义组合使用

• 字符过滤器（character filter）：字符串先通过这作一些过滤操做
• 分词器（tokenizer）：将文本切分为单词，好比空格，逗号等。中文可用专门的分词器
• 标记过滤器（token filter）：修改词语，好比转小写，去掉语气词，增长同义词

内置的分析器

• 标准分析器：默认使用这个。标准切分，去掉大部分符号，最后转为小写
• 空格分析器：按空格切分，不转换为小写
• 语言分析器：根据特定语言的特性作分析

查询方式

• 字段查询：精确匹配，查询前不会将被查询的字符串分析
• 全文查询：查询前会先用分析器分析要查询的字符串

手动指定分析器

• 当往es中加入字符串时，es会自动用标准分析器作分词，可是可能某些字符就是普通的id，标签等字段，不须要作分析，可手动指定映射

建立索引时查找分析器的顺序

• mapping文件中指定字段的analyzer
• 文档自己的_analyzer字段
• mapping文件中指定类型的默认analyzer
• mapping文件中全局默认的analyzer
• 节点级别默认的analyzer
• 标准analyzer

查找索引时查找分析器的顺序

• 查询参数中的analyzer
• mapping文件中指定字段的analyzer
• mapping文件中指定类型的analyzer
• mapping文件中全局默认的analyzer
• 节点级别默认的analyzer
• standard analyzer

3.3 映射

做用

定义字段类型，字段的数据类型以及被es处理的方式。

支持的字段类型

类型	表示的数据类型
String	string
Whole Number	byte short integer long
Floating point	float double
Boolean	boolean
Date	date

新的字段若是没有配置映射，es会自动猜想字段类型

自定义字段映射可实现的功能

• 区分全文字符串（须要分词）和精确字符串（不须要分词）
• 使用特定语言的分析器
• 优化部分匹配字段
• 指定自定义日期格式

映射包含的参数

• properties：列出了可能包含的每一个字段的映射
• 元数据字段：_type, _id, _source
• dynamic：肯定字段添加时的策略（_source会一直保存）
  • ture 自动添加
  • false 忽略字段
  • strict 抛出异常
• 设置项：如analyzer
• 其余设置

自定义字段映射注意点

• 要映射的字段参数为type, 除了string外，不多须要映射其余type
• string字段的index字段，控制字符串以什么方式被索引。

  值	含义
  analyzed	分词索引
  not_analyzed	不分词索引
  no	不索引

• string字段选择anlyzed为index时，analyzer指定分析器。如：simple, english, whitespace
• 更新映射只能添加字段，不能修改已经被添加的字段。不然会致使出错索引不到

文档字段的属性

• type
• index
• analyzer
• ip
• geo_point
• geo_shape

元数据_source字段

• 做用： 用于保存原始json字段
• 为何须要
  • 搜索结果能获得完整文档
  • 缺乏它，部分更新请求不起做用
  • 更新映射文件时，可直接取内容
  • 更易排查错误
• 怎么禁用：enabled：false
• 使用：搜索时能够经过_source指定只返回哪些列

元数据_all字段

• 查询不知道指定哪一个字段时，使用_all。也可禁用。使用_all时，会将其余全部字段的值做为一个大的字符串进行索引

动态模版

dynamic_templates 设置经过字段名或类型动态匹配不一样的映射

• match_mapping_type 模版使用的数据类型
• match 模版使用的字段名
• path 模版使用的字段全路径（嵌套json）

三. 结构化查询语言

1. 过滤

概述

文档的字段是否包含特定值，比查询更快，结果可缓存

原则上全文索引或者须要其余相关性评分的使用查询语句，其余状况都用过滤。

重要的过滤语句

• term：精确匹配
• terms：多个条件的精确匹配
• range：范围过滤
• exists：是否包含指定字段
• missing：没有某个字段
• bool：合并多个过滤查询结果
  • must：and
  • must_not：not
  • shoud：or

过滤顺序

• 过滤顺序对性能有很大影响
• 更详细的过滤条件应该放在最前，以便排除更多的文档
• 被缓存的过滤应该放到不会缓存的过滤前面（缓存参考后面章节）

2. 查询

简述

每一个文档的字段与特定字段的匹配程度如何，比过滤慢，结果不可缓存

重要的查询语句

• math_all：查询全部文档
• match：标准查询，全文和精确都支持

  match指定多个值时，内部分词后会执行多个match并放入bool查询。默认为or。可经过operator参数改成“and”

• multi_match：同时搜索多个字段,支持通配符
• bool：同bool过滤，多的是要计算_score

3. 相关性排序

排序方式

• _score：默认排序方式，默认倒序

• 字段排序：_score不须要计算，默认正序

• 多级排序：可指定多个字段。先用第一个字段排序，第一个相同时排第二个

• 字符串参数排序：

  被分析的字段进行强制排序会消耗大量内存

相关性简介

类似度算法：TF/IDF（检索词词频/反向文档频率）

• TF： 词频，出如今当前文档次数越多，相关性越大
• IDF：反转文档频率，全部文档数与出现这个词的文件数百分比，词出现频率越大，IDF越小
• 因为性能问题，每一个分片只会计算该分片内的IDF，而不是全部文档
• boost参数能够设置权重

4. 分布式搜索的执行方式

概述

搜索包括查询多个分片，并将多个分片元信息合并，而后再根据元数据获取真正数据两个步骤。

查询多个索引和查询一个索引彻底一致，无非是多查了几个分片。扩展的时候，能够不用将旧数据迁移到新索引，直接新建索引，而后查询两个索引，或者别名索引便可

查询（query）

• 客户端发送search给node3，建立一个from+size的空优先级队列

• 广播请求到每一个分片，每一个分片在本地执行查询，并放到一个大小为from+size的本地优先级队列里

• 每一个节点返回查询结果（id和_score）给node3，node3将结果全局排序

  • 多个请求会轮询全部的分片副本以负载均衡，提升系统吞吐率
  • 多索引的工做机制和单索引相似，只不过多了些分片
  • 深度分页会致使排序过程很是繁重，占用巨大cpu和宽带

取回（fetch）

• 协调节点辨别出哪些文档须要取回，并向相应分片发送请求
• 每一个分片加载文档，并作相关处理（好比高亮），而后返回给协调节点
• 协调节点将数据返回给客户端

搜索选项（可选参数）

• preference：控制使用哪一个分片或节点处理请求
• timeout：协调节点等待多久就放弃其余节点的结果
• routing：限制只搜索哪些分片，对于大规模系统颇有用
• search_type：query_then_fetch为默认的搜索类型
  • count：当不须要结果，只须要数量时
  • query_and_fetch：查询而且取回
  • dfs_query_and_fetch，dfs_query_then_fetch
  • scan：扫描，和scroll一块儿使用。可高效取回大量数据。禁用排序实现

扫描和滚屏

scroll

相似传统数据库的游标，搜索的是查询时的索引快照，查询结束以前的修改不会感知到

scan

不排序，只要有结果就返回

四. 分片内部原理

1. 索引动态更新原理

1.1 倒排索引-保证文档可被搜索

1.2 倒排索引的内容是不可变的

1.3 不可变的同时动态添加段

查询的时候，全部段依次查询，而后聚合结果，经过这种方式，新文档以最小代价加入文档

• 新的文档首先写入内存区的索引缓存
• buffer中包括新的段包含的倒排索引，段名等
• buffer被提交
• 新段被打开，文档可被索引
• 内存缓存被清除，等待新文档

1.4 删除和更新

由于段不可变，更新和删除操做并非真的删除，是经过新增.del文件和新建段文件，查询返回前将标记为del的文件从结果中删除

1.5 近实时搜索

由于从buffer刷入磁盘代价很大。es容许一旦一个文件被缓存，就能够设置段打开，文件能够被搜索到

1.6 刷新

每一个分片默认每秒打开一个新段，因此新的改动须要1s后才能看到。能够设置refresh_interval减小刷新的频率

1.7 持久化变动

添加缓冲buffer的同时，经过添加事务日志（默认512M），保证数据被完整持久化。每次flush（每30分钟，或事务日志过大）到磁盘时，段被所有提交，清空事务日志

1.8 合并段

经过每秒自动刷新段，不用多久段数据就剧增。每一个段消耗计算机资源，且每次查询都要依次检查每一个段，段越多查询越慢。es后台合并段解决该问题。 合并大的段会消耗io和cpu资源。

1.9 Optimize API

强制合并段。对于数据再也不变更的索引颇有效，对数据还在动态增加的索引不要使用。

2. 缓存

概述

• 缓存针对过滤查询
• 核心是一个字节集保存哪些文档符合过滤条件
• 缓存的字节集是增量更新的
• 每一个过滤器都是独立缓存的，且可复用
• 大部分枝叶过滤器（如term）会被缓存，而组合过滤器（如bool）不会被缓存

不可被缓存的状况

• 脚本过滤器，脚本对es是不透明的
• Geo（地址）过滤器，不太会被重用
• 日期范围精确到毫秒不会被缓存，整数会被缓存

过滤时间范围的使用建议

• 对于时间精确到毫秒的查询，可拆分为日期+日期时间两个过滤条件，前者会被缓存，且顺序不要改变

五. 全文检索

1. 全文检索包括两个方面

• 相关度（Relevance）：TF/IDF，地理位置相近度，模糊类似度或其余算法
• 分析（Analysis）：分词，建立倒排索引

2. 全文查询分类

• 低级查询：term查询。没有分析阶段，会精确匹配特定短语
• 全文检索：match，query_string等查询。有分析阶段。
  • date，integer类型：精确查询
  • not_analyzed的string类型：分析查询词语（好比转小写），执行单个短语查询
  • analyzed的string类型：先解析查询语句，生成短语列表。查询后再合并查询结果

六. 聚合

1. 基本概念

桶（buckets）

知足特定条件的文档的集合。相似于sql里面的group by

指标（metrics）

对桶内的文档进行统计计算。相似sql里面的count，sum，max等统计方法

2. 近似聚合

2.1 概述

• 分布式算法三个因子模型同时只能选择知足两项：精确，实时，大数据
• ea选择大数据和实时。会提供准确但不是100%精确的结果，以牺牲一点小的估算错误做为代价，换来告诉的执行效率和极小的内存消耗
• 两个近似算法：cardinality, percentiles

2.2 cardinality 基数度量

• 相似sql的distinct
• 是一个近似算法。基于HyperLogLot++（HLL）算法的。HLL先对输入作哈希运算，根据hash运算的记过中的bits作几率估算获得基数。HLL 论文
• 算法特性
  • 可配置精度：参数为precision_threshold （精度更高=跟多内存）
  • precision_threshold范围为0-4000，数据结构使用内存为：precision_threshold * 8
  • 设置为100时，可保证百万级别的数据量偏差维持5%之内
  • 小的数据集精度很是高
  • 可配置使用的固定内存量
• 优化：预先计算hash值，不过性能的瓶颈由聚合时转移到索引时（必须从新建索引，添加hash字段），须要根据业务场景来肯定。

2.3 percentiles 百分位数度量

• 展示了以某个具体百分比执行观察到的数值，一般用于找出异常。
• 也是一个近似算法。使用TDigest算法
• 算法特性
  • 极端百分比的状况下，数据更准确。好比1%或99%。这由数据结构决定。
  • 小数据集精度很是准确

3. significant_terms

• sigterms和其余聚合不一样，用于发现数据集中医学异常指标
• 经过统计数据并对比正常数据找到可能有异常频次的指标

4. 聚合的数据结构

4.1 Doc Values

• 聚合，排序使用Doc Values的数据结构

• 将文档映射到他们包含的词项

  

• 在索引时和倒排索引同时生成。基于segment且不可变。

• Doc values数据存放到磁盘中，不是由jvm管理。

• 采用列式存储，数据整齐排布，便于压缩

• 不支持analyzed字段

• 除了analyzed的字符串，默认全部字段都开启doc values。若是你永远不会对某些字段进行聚合，排序操做，能够禁用doc values。能够节省磁盘空间和索引速度

4.2 Fielddata

• anaylzed的字符串，使用Fielddata这种数据结构支持聚合，fielddata存储在内存堆中，旧版本没有doc values时是用的fielddata
• anaylzed的过程会消耗极大内存，且生成大量token，对聚合很不友好
• fieldata会一直存在内存中，直到被驱逐或节点崩溃。注意观察它的大小。
• dielddata不会在建索引时存在，是查询时创建的
• indices.fielddata.cache.size：百分比或实际大小。 控制为 fielddata 分配的堆空间大小。每次聚合查询时，分析字段会加载到Fielddata中，若是查询结果中 fielddata 大小超过了指定的大小 ，其余的值将会被回收从而得到空间。
• 若是没有足够空间能够将 fielddata 保留在内存中，Elasticsearch 就会时刻从磁盘重载数据，并回收其余数据以得到更多空间。内存的回收机制会致使重度磁盘I/O，而且在内存中生成不少垃圾，这些垃圾必须在晚些时候被回收掉。
• 监控filddata： GET /_stats/fielddata?fields=*

5. 聚合优化

• 针对大量数据的嵌套聚合查询，效率极低。默认的查询方式为深度优先。
• 可使用广度优先处理聚合数量远远小于总组数的状况。参数为collect_mode: breadth_first

七. 地理位置

1. 设置字段类型为地理位置

地理坐标点不能被动态映射字段检测，须要显式申明对应字段类型（type参数）为geo_point

2. geo_point格式

• 字符串： "40.715, -74.011", 维度在前，精度在后
• 数组: [40.715, -74.011], 维度在前，精度在后
• 对象: {"lat": 40.715, "lon": -74.011}

3. 过滤方式

• geo_bounding_box :: 落在指定矩形框中的坐标点
• geo_distance :: 给定距离内的点
• geo_distance_range :: 距离范围内的点
• geo_polygon :: 落在多边形中的点

4. 使用注意

• 地理坐标过滤器使用代价很高，它会将全部文档的地理位置信息载入内存，而后计算。使用时谨慎，或放到过滤的最后
• bool过滤器默认会将地理信息过滤排到最后
• 默认是不被缓存的
• 每一个经纬度组合须要16本身的内存，可设置压缩格式，减小精度，减小内存
• 合理设置精度：geohash_prefix和geohash_precision两个参数。再结合geohash过滤器可高效查询

5. geohash

• 把世界分为4*8=32个单元的各自，每个格子用一个字母或数字标识。这些单元有被继续分解成32个更小的单元，不断重复
• 长度越长，精度越高
• 有同一前缀的geohash，位置靠的近，共同前缀越长，距离越近
• 恰好相邻的位置也有可能geohash彻底不一样

6. 地理位置聚合

• geo_distance 距离聚合：将文档以指定中心店为圆心的圆环分组
• geohash_grid网格聚合：将文档按geohash单元分组，以便在地图上呈现
• geo_bounds: 边界聚合：包含坐标点的矩形框

7. 地理形状（geo_shape）

• 地理形状是经过一个个geohash单元画出来的

八. 数据建模

1. 关联关系

关联关系的处理，使用扁平化的存储，将数据冗余到同一个索引，提升查询效率

2. 嵌套对象

设计

内部存储

普通对json含有数组时，内部存储会被扁平化，致使逻辑关系丢失。需改成nested关系，而不是默认的object。嵌套对象内部会被索引为分离的隐藏文档

查询

使用特殊的nested查询或nested过滤

排序

3. 父子关系

原理

• 和nested差很少，区别是nested是存储在同一个文档中，而父子关系是彻底不一样的文档
• 父子文档需存储在同一个分片中
• 父子关系映射存储在doc-values的数据结构中，彻底存在内存
• 适合父文档少，子文档多的状况

优点

• 更新父文档时，不用更新子文档索引
• 建立删除修改子文档时，不影响父文档和其余文档

劣势

• 查询速度比嵌套类型慢5-10倍
• 不适合父文档多的状况

设计父子关系

• 指定某一文档type为另外一文档type的parent
• 建立父文档时，和普通文档没区别
• 建立子文档时，必须经过parent指定父文档id。做用是建立关联关系并保证分配到同一个分片（使用父文档id作hash计算）
• 尽可能少使用父子关系，仅父文档比较少的时候

4. 扩容设计

扩容思路

• 首先查看是否有低效率的查询能够优化
• 是否缺乏足够的内存
• 是否开启了swap
• 已经创建好的索引，不可修改分片数，可经过从新索引，将旧数据迁移到新索引中
• 搜索性能取决于最慢节点的响应时间，合理设置分片使之负载均衡
• 由于单索引和多索引没有区别，可经过设置多索引以扩容

分片数量设置

• 基于现有的数据量和按期的增加量，预估数据总量
• 基于现有的硬件信息，设置单个分片，0个副本，找到单个分片在当前硬件条件下能支持的最大文档数
• 用总数量/单个分片的最大数，大体可估算出分片数

基于时间的数据流场景优化

• 按时间切分索引
• 旧数据不会被改变，使用optimize api进行段合并。

• 大多数索引会有大概 50–150 个段，哪怕它们存有 TB 级别的数十亿条文档。段数量过大代表合并出现了问题（好比，合并速度跟不上段的建立）
• 不过段合并消耗掉你节点上所有的I/O资源,从而有可能使集群失去响应。 若是你想要对索引执行optimize，你须要先把索引移到一个安全的节点，再执行。
• 为了避免影响正常索引，段合并后台限制磁盘读写速率为20MB/s，可根据实际状况调整，好比SSD盘，参数为indices.store.throttle.max_bytes_per_sec。甚至在没有查询时，设置为none，即没有限制，合并完再改回去。
• 而且，对还在写数据的索引进行优化（Optimize）操做将会是一个糟糕的想法， 由于优化操做将消耗节点上大量 I/O 并对现有索引形成冲击
• 咱们能够临时移除副本分片，进行优化，而后再恢复副本分片
• 去除副本以前，可经过snapshot restore api备份数据

• 更旧的不会被使用的数据，关闭索引。关闭后除了磁盘，不会占用其余资源。flush（清空事务日志）->close(关闭索引)
• 数据归档：snapshot restore api将数据存储到hdfs或其余地方

基于用户的数据流场景

• 指定路由：保证同类数据会分发到同一分片。查询时也传入路由参数，确保只查询特定的分片，多分片查询带来的性能损耗
• 使用别名，指定特定的名字对应特定的路由值和过滤器。以达到多个名称共享一个索引的效果。看起来像多个索引同样。
• 当某个分片数据量剧增到须要单独建索引时，使用_alias操做：指定action的remove和add参数，实现平滑迁移。

九. 管理，监控

1. 重要的参数配置

• cluster.name
• node.name
• path.data
• path.logs
• path.plugins
• discovery.zen.minum_master_nodes: 最小主节点数，防止脑裂（多个主节点）
• discover.zen.ping.unicast.hosts: 集群单播列表
• gateway.recover_after_nodes 至少多少个节点，集群才可用
• gateway.expected_node 集群期待有多少个节点
• gateway.recover_fater_time 等待多久才进行数据恢复
• logger.discovery 日志级别
• index.search.slowlog.threshold.query.warn : "10s" 查询慢与10s的输出warn日志
• index.search.slowlog.threshold.fetch.debug: "500ms" 查询慢与500ms的输出debug日志
• index.indexing.slowlog.threshold.index.info: "5s 查询慢与5s的输出info日志
• index.unassigned.node_left.delayed_timeout 修改延时分片时间
• cluster.routing.allocation.enable" : "none" 禁止分片分配

2. 不要修改的配置

• 不要更改垃圾回收器，默认使用CMS。不要更换为新一代的G1
• 线程数量，默认为cpu核数。IO操做是由Lucene线程完成，不是es。

3. 堆内存的配置

• 默认为1G，实际生产环境必须修改
• 保证Xms和Xmx同样，防止运行时改变堆内存大小，这很是消耗资源
• 内存分片不要超过本机内存的一半。由于Lucene自己也会须要内存和缓存。
• 若是不须要对分词作聚合运算，可下降堆内存。堆内存越小，Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）的性能越好。
• 内存不要超过32G。每一个对象的指针都变长了，就会使用更多的 CPU 内存带宽，也就是说你实际上失去了更多的内存。果你想保证其安全可靠，设置堆内存为 31 GB 是一个安全的选择
• 若是内存很大，能够考虑给一个机器分配多个es实例，但总的堆内存仍是不要超过一半。同时配置cluster.routing.allocation.same_shard.host: true。防止同一个分片（主副）在一个机器上
• 设置bootstrap.mlockall: true，锁住内存，不让发生内存swapping

4. 运维及优化

• 日志文件默认存放在安装目录下的logs文件里，"logger.discovery" : "DEBUG"可设置日志级别
• 能够设置输出慢查询日志
• 若是不须要实时准确，把index.refresh_interval改到30s，作大批量倒入时，把这个值设为-1，倒入完毕后从新设置回来
• 大批量倒入时，index.number_of_replicas设为0，关闭副本，提升效率
• 尽可能使用es自动生成的id，避免版本查找影响效率。若是使用本身的id，使用压缩性能良好的，避免使用太过随机的id
• 延迟分片：防止节点掉线而后又重启致使的大量数据迁移问题。由于掉线的节点上的数据可能会由于失效而所有被删除，而后从新复制。参数为index.unassigned.node_left.delayed_timeout

5. 滚动重启

• 保证不停集群功能的状况下逐一对每一个节点进行升级或维护
• 先中止索引新的数据
• 禁止分片分配。cluster.routing.allocation.enable" : "none"
• 关闭单个节点，并执行升级维护
• 启动节点，并等待加入集群
• 重启分片分配。cluster.routing.allocation.enable" : "all"
• 对其余节点重复以上步骤
• 恢复索引更新数据