ElasticSearch 介绍及使用方法
简介数据库
ElasticSearch是一款基于 Apache Lucene的开源搜索引擎产品，以后成了独立的商业公司，继而发布了ELK等一系列产品，特色是开源、分布式、准实时，标准的RESTFul接口等。安全
ElasticSearch能够单机部署，也能够集群部署。ES的分布式属性，能够轻松的处理超过单机负载能力的数据量，集群也是无间断服务的一种解决方案。架构
总体架构并发
基本概念app
Node：单个的ElasticSearch服务实例。分布式
Master：负责监督、控制其它节点的工做。性能
Data：持有数据，并提供数据的索引功能，主要用途是索引和查询数据。fetch
协调节点：每个节点都是一个潜在的协调节点，协调节点会处理请求，将各分片里的数据聚集起来一并返回给客户端，ES的节点须要有足够的CPU和内存去处理协调节点的gather 阶段。优化
索引：EasticSearch将数据存储在一个或多个索引中， 用SQL领域的术语来类比，索引就像数据库，能够向索引中写入文档或者从索引中读取文档，内部使用Lucene。搜索引擎
分片：ES将数据分散到多个物理的Lucene索引，这些Lucene索引就称为分片。分散分片的过程，称之为sharding。
主分片：主分片的数量在索引建立时就被配置好了，以后没法改变，除非建立一个新索引并从新索引所有数据。
副本分片：副本主要有如下做用，1 分担访问压力；2 给ES集群提供安全机制；3会增长写入的时长。
类型（type）
5.x 版本中index和 type为一对多关系，不一样type定义对应的mapping。
6.x 版本中index和 type为一对一关系。
7.x 版本中移除了type，一个索引只定义一个数据类型。
未来会在8.x中完全移除。
文档（doc）
doc是ES中的主要实体：
对于全部使用ES的案例来讲，最终都会被归结到文档的搜索之上。
文档由字段构成，每一个字段包含字段名以及一个或多个字段值。
从用户端的角度看，文档是一个Json对象。
集群健康状态
Green：表示全部主分片和副本分片均可用。
Yellow：表示全部主分片可用，但不是全部副本分片均可用。
Red：表示部分主分片处于不可用状态
ES操做
索引设计
索引设计主要包括 mapping和setting两部分
Settings用于设置分片和副本数
查看setting：
Mapping（映射）
mappings用于设置字段和类型。
动态mapping：根据索引的数据动态的生成 mapping
不建议使用动态mapping，主要缘由：
会引起性能降低。
影响磁盘空间的使用。
致使与预期查询不符的结果。
查看mapping语法：
模板
Logstash 使用事件中的时间戳来生成索引名，@timestamp 为 2019-10-01 00:00:01 事件将被发送至索引 logstash-2019.10.01 中，一般咱们想要控制新建索引的设置（settings）和映射（mappings）
上面的API作了以下操做：
建立一个名为 my_logs 的模板；
将这个模板应用于全部以 logstash- 为起始的索引；
设置模版的顺序级别；
限制主分片数量为 10；
为全部类型禁用 _all 域。
经常使用API：
写入操做：
实际过程当中，提交操做会进行一次完整的 HTTP POST 请求和 ES indexing，单条数据是一种极大的性能浪费，ES 设计了批量提交方式， bulk接口：
Bulk像一个集合，把一系列操做批量提交，这在很大程度上提升了ES的写入效率。
bulk的使用和大小设置
整个bulk请求须要被加载到接收请求节点的内存里，因此请求越大，给其它请求可用的内存就越小。所以，有一个最佳的bulk请求大小，超过这个大小，性能再也不提高并且可能下降。
最佳大小，并非一个固定的数字, 取决于硬件、文档的大小和复杂度以及索引和搜索的负载状况。
开始的数量能够在1000~5000个文档之间，若是文档很是大，可使用较小的批次。一般着眼于你请求批次的物理大小是很是有用的，一千个1kB的文档和一千个1MB的文档大不相同。
一个好的批次最好保持在5-15MB大小间。
数据检索过程
数据检索主要分为两个阶段，query阶段和fetch阶段：
query阶段：
客户端发送一个search请求到Node 3上，而后Node 3会建立一个优先级队列（大小=from+size）。
Node 3转发这个search请求到索引里面每个主shard或者副本shard上，每一个shard会在本地查询而后添加结果到本地的排序好的优先级队列里面。
每一个shard返回docId和全部参与排序字段的值到优先级队列里面，而后再返回给coordinating节点也就是Node 3，而后Node 3负责将全部shard里面的数据合并到一个全局的排序列表。
Fetch阶段：
coordinating节点标识了那些document须要被拉取出来，并发送一个批量的mutil get请求到相关的shard上。
每一个shard加载相关document，若是须要它们将会被返回到coordinating 节点上。
一旦全部的document被拉取回来，coordinating节点将会返回结果集到客户端上。
scroll 读取（游标查询）
优势：
Scroll 有效地执行大批量的文档查询，而又不用付出深度分页的代价，相似于传统数据库中的cursor。
scroll使用方法：
游标查询每次返回一个新字段 _scroll_id。每次作下一次游标查询时， 须要把前一次查询返回的字段 _scroll_id 传递进去
在一些语言如 Python、perl的ElasticSearch包中，提供了这个功能易用的封装。
别名 Index aliases
别名很简单，可是能解决重建索引必须更新应用中索引名的问题，实现索引切换的无缝过渡。
别名像一个快捷方式或软链接，能够指向一个或多个索引，须要注意，别名不能与索引同名。
相关API：
重命名别名：
针对DSL查询，浅显的优化建议：
正确使用 match、match_phrase、term， 区分 must 、must_not 、should等Bool查询
尽可能多使用filter
若是没必要须涉及相关性和评分的话，尽可能避免相应的操做
合适的数据类型（如Mapping中合理使用keyword类型）
结束语
本篇文章主要介绍了ElasticSearch的基本概念和实践中经常使用的一些方法，并无涉及深层原理和优化的知识，在DSL、读写优化、7.x新版本等方面，还有很多知识点能够深刻研究。
关注咱们
界世的你当不
只作你的肩膀
无
360官方技术公众号
技术干货|一手资讯|精彩活动
空·