关于Elasticsearch的一些学习（一）

定义:
1.Lucene 是一个全文检索引擎的工具包，能够实现倒排索引的查询结构。
2.Elasticsearch (以下简称 ES) 是一个开源的分布式搜索引擎，底层使用Lucene做索引与搜索，隐藏了Lucene的复杂性，取而代之的提供一套简单一致的RESTful API

优势:
1.支持PB级别数据存储
2.精确匹配、模糊搜索、聚合查询
3.近实时索引
4.部署简单
5.平滑的横向扩容
6.服务节点支持高可用
7.支持多种开发接口

劣势:
1.不支持准实时 refresh_interval决定，近实时而非准实时
2.不支持事务
3.多表关联有限
4.高阶功能收费

概念:
1.集群 Elasticsearch可以运行在多台相互合作的服务器上，这些ES实例集合称为集群。每个ES实例都会配置一个相同的cluster.name，这就是集群的名字。
2.节点 组成集群的每个ES实例称为节点，本质上就是一个JAVA进程。
  master节点：负责集群范围的设置和更改，例如创建或删除索引，添加或删除节点，将分片分配给节点等。
  数据节点：用于存储和搜索数据，分为热节点、温节点、冷节点。
  协调节点：客户端请求的负载均衡器（访问入口）。
3.本地部署&水平扩展
  单节点部署：一个节点承担多种角色。
  多角色分离部署：管理节点、协调节点、数据节点分开部署。
  数据分层部署：管理节点、协调节点、热数据节点、温数据节点、冷数据节点分开部署。
4.Index：索引
  1）在Elasticsearch的不同语义中，index有不同的含义。
  名词：集群中可以创建多个不同的index（索引），相当于一张张的表。
  动词：保存一个文档到Elasticsearch的过程也叫做索引，相当于插入/更新表。
  名词：倒排索引，ES底层数据结构，用于实现快速检索。
  2）最常说的索引，是指Elasticsearch集群中的表，一个索引里面包含非常多的文档。
5.Shard：分片
  1）数据的最小单元块，实际上是一个运行的Lucene实例
  2）分为主分片和副本分片。
  Primary shard（主分片）：为满足客户端读写请求的快速响应，ES将同一个index的数据切分成多个较小的分片，每个分片放到不同的节点上。
  Replica shard（副本分片）：是某一主分片的精确复制，可以提高查询吞吐量并实现高可用，每个主分片可以有0个或多个副本
  3）主分片数在索引创建时指定，后续不允许修改；副本数可以动态调整。
6.Document：文档
  1）Elasticsearch是面向文档的，文档是所有可搜索数据的最小单位（相当于一张表的每一行）。
  2）每个文档都有一个Uniqe ID（默认记录为字段_id），可以自定义或者由Elasticsearch自动生成。
  3）文档的元数据：_index：文档所属的索引名，_type：文档所属的类型名，_id：文档唯一ID，_source：文档的原始JSON数据，_version：文档的版本信息。
7.Elasticsearch中的1个索引由一个或多个分片组成。每个分片包括多个Segment（段）。每一个段都是一个倒排索引。
8.Elasticsearch中的每个索引都被划分为Shard，每个Shard可以有多个副本。这些副本成为副本组，在添加或删除文档时必须保持同步。保持分片副本同步并从它们读取数据的过程就是数据复制模型。
9.Refresh Translog（Transaction log）默认写入磁盘。index buffer 清空，translog 不清空。
10.Flush 段合并，缓存中合并后的段写入磁盘。清空 translog。

部署:
1.熟悉Elasticsearch的文件目录结构
2.安装Java
3.系统环境配置
4.配置Elasticsearch
5.JVM与日志配置
6.Elasticsearch进程操作

ES对比Mysql:
Elasticsearch        Mysql
Index（索引）        Table
Type                Table（_doc）
Document（文档）    Row
Field（字段）        Column
Mapping（表结构）    Schema
Query DSL            SQL
PUT http://...      增
DELETE http://...    删
POST http://...      改
GET http://...      查
Aggregations        group by、avg、sum
reindex              复制表
snapshot            mysqldump

常见问题:
1、集群规模很大，数据量很多，但没有对数据节点进行分层，实时、历史数据共存，对实时业务的稳定性造成隐患。
2、数据节点的存储容量存在极大差异（1TB和6TB），低容量的节点很快被写满。
3、索引容量大小不一，大容量的达2T以上，小容量的绝大部分是空索引，但是这些索引的主分片数都设置为5，导致大索引的单个分片容量达几百gb，小索引则产生大量的空分片。
4、因数据节点存储异构，且无“冷温热”分层架构，再加上大索引的分片容量巨大、空索引的分片数量极多，导致集群的自动平衡机制（严格保持各节点在线分片数一致）无法适应实际分片容量的差异，从而导致各节点的分片分布非常不均，数据无法完全均衡，造成IO的浪费。

优化：
1、解决节点存储异构问题，将现有节点按“冷温热”分层架构进行调整。其中：容量为1tb的设置为热节点，容量为4.8tb的设置为温节点，容量为5.9tb的设置为冷节点。
2、程序优化，索引分片数设置能够与实际容量适应，推荐大容量索引按照每个分片20~30gb设置分片数，kb/mb级别的小索引分片数设为1。
3、增加索引生命周期管理策略，索引的周期设置严格按照“冷温热”分层架构进行设计，如：最近1个月的索引存储在热节点，第2~3个月的索引存储在温节点，其他历史索引存储在冷节点。（具体设置按业务的实际需要调整，但必须保证热节点资源充裕）
4、严格控制在线空索引的数量，建议程序增加开关，对于未被写入的空索引，建议默认关闭处理，在需要被写入时再触发打开。