在当今这样的就业大背景下，卷是肯定的，强大自己也是必须的。所以，学习不能停，必须一直卷下去。所以，从今天开始，让我们一起卷下一个知识体系的学习之旅：搜索引擎 ElasticSearch 。希望大家能够从中收获多多！
边学边实战系列之搜索引擎 ElasticSearch ！
为什么需要学习 ElasticSearch
根据 DB Engine 的排名显示，ElasticSearch 是最受欢迎的企业级搜索引擎。下图红色勾选的是我们前面的系列详解的，除此之外你可以看到搜索库ElasticSearch在前十名内：
所以为什么要学习 ElasticSearch 呢？
1、在当前软件行业中，搜索是一个软件系统或平台的基本功能， 学习ElasticSearch就可以为相应的软件打造出良好的搜索体验。
2、其次，ElasticSearch具备非常强的大数据分析能力。虽然Hadoop也可以做大数据分析，但是ElasticSearch的分析能力非常高，具备Hadoop不具备的能力。比如有时候用Hadoop分析一个结果，可能等待的时间比较长。
3、ElasticSearch可以很方便的进行使用，可以将其安装在个人的笔记本电脑，也可以在生产环境中，将其进行水平扩展。
4、国内比较大的互联网公司都在使用，比如小米、滴滴、携程等公司。另外，在腾讯云、阿里云的云平台上，也都有相应的ElasticSearch云产品可以使用。
5、在当今大数据时代，掌握近实时的搜索和分析能力，才能掌握核心竞争力，洞见未来。
更多关于 ElasticSearch 数据库的学习文章，请参阅：NoSQL 数据库之 ElasticSearch ，本系列持续更新中。
什么是ElasticSearch
ElasticSearch是一款非常强大的、基于Lucene的开源搜索及分析引擎；它是一个实时的分布式搜索分析引擎，它能让你以前所未有的速度和规模，去探索你的数据。
它被用作全文检索、结构化搜索、分析以及这三个功能的组合：
Wikipedia_使用 Elasticsearch 提供带有高亮片段的全文搜索，还有 search-as-you-type 和 did-you-mean 的建议。 卫报使用 Elasticsearch 将网络社交数据结合到访客日志中，为它的编辑们提供公众对于新文章的实时反馈。 Stack Overflow_将地理位置查询融入全文检索中去，并且使用 more-like-this 接口去查找相关的问题和回答。 GitHub_使用 Elasticsearch 对1300亿行代码进行查询。 ...
除了搜索，结合Kibana、Logstash、Beats开源产品，Elastic Stack（简称ELK）还被广泛运用在大数据近实时分析领域，包括：日志分析、指标监控、信息安全等。它可以帮助你探索海量结构化、非结构化数据，按需创建可视化报表，对监控数据设置报警阈值，通过使用机器学习，自动识别异常状况。
ElasticSearch是基于Restful WebApi，使用Java语言开发的搜索引擎库类，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。其客户端在Java、C#、PHP、Python等许多语言中都是可用的。
所以，ElasticSearch具备两个优势：
天生支持分布式，可水平扩展； 提供了Restful接口，降低全文检索的学习曲线，因为Restful接口，所以可以被任何编程语言调用；
ElasticSearch的由来
ElasticSearch背后的小故事。
许多年前，一个刚结婚的名叫 Shay Banon 的失业开发者，跟着他的妻子去了伦敦，他的妻子在那里学习厨师。在寻找一个赚钱的工作的时候，为了给他的妻子做一个食谱搜索引擎，他开始使用 Lucene 的一个早期版本。
直接使用 Lucene 是很难的，因此 Shay 开始做一个抽象层，Java 开发者使用它可以很简单的给他们的程序添加搜索功能。他发布了他的第一个开源项目 Compass。
后来 Shay 获得了一份工作，主要是高性能，分布式环境下的内存数据网格。这个对于高性能，实时，分布式搜索引擎的需求尤为突出， 他决定重写 Compass，把它变为一个独立的服务并取名 Elasticsearch。
第一个公开版本在2010年2月发布，从此以后，Elasticsearch 已经成为了 Github 上最活跃的项目之一，他拥有超过300名 contributors(目前736名 contributors )。一家公司已经开始围绕 Elasticsearch 提供商业服务，并开发新的特性，但是，Elasticsearch 将永远开源并对所有人可用。
据说，Shay 的妻子还在等着她的食谱搜索引擎…。
为什么不是直接使用Lucene
ElasticSearch是基于Lucene的，那么为什么不是直接使用Lucene呢？
Lucene 可以说是当下最先进、高性能、全功能的搜索引擎库。
但是 Lucene 仅仅只是一个库。为了充分发挥其功能，你需要使用 Java 并将 Lucene 直接集成到应用程序中。更糟糕的是，您可能需要获得信息检索学位才能了解其工作原理。Lucene 非常 复杂。
Elasticsearch 也是使用 Java 编写的，它的内部使用 Lucene 做索引与搜索，但是它的目的是使全文检索变得简单，通过隐藏 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API。
然而，Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎。它可以被下面这样准确的形容：
一个分布式的实时文档存储，每个字段 可以被索引与搜索 一个分布式实时分析搜索引擎 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据 更多关于 ElasticSearch 数据库的学习文章，请参阅：NoSQL 数据库之 ElasticSearch ，本系列持续更新中。
ElasticSearch的主要功能及应用场景
我们在哪些场景下可以使用ES呢？
主要功能
1）海量数据的分布式存储以及集群管理，达到了服务与数据的高可用以及水平扩展； 2）近实时搜索，性能卓越。对结构化、全文、地理位置等类型数据的处理； 3）海量数据的近实时分析（聚合功能）
应用场景
1）网站搜索、垂直搜索、代码搜索； 2）日志管理与分析、安全指标监控、应用性能监控、Web抓取舆情分析；
ElasticSearch的基础概念
我们还需对比结构化数据库，看看ES的基础概念，为我们后面学习作铺垫。
Near Realtime（NRT） 近实时。数据提交索引后，立马就可以搜索到。 Cluster 集群，一个集群由一个唯一的名字标识，默认为“elasticsearch”。集群名称非常重要，具有相同集群名的节点才会组成一个集群。集群名称可以在配置文件中指定。 Node 节点：存储集群的数据，参与集群的索引和搜索功能。像集群有名字，节点也有自己的名称，默认在启动时会以一个随机的UUID的前七个字符作为节点的名字，你可以为其指定任意的名字。通过集群名在网络中发现同伴组成集群。一个节点也可是集群。 Index 索引: 一个索引是一个文档的集合（等同于solr中的集合）。每个索引有唯一的名字，通过这个名字来操作它。一个集群中可以有任意多个索引。 Type 类型：指在一个索引中，可以索引不同类型的文档，如用户数据、博客数据。从6.0.0 版本起已废弃，一个索引中只存放一类数据。 document 文档：被索引的一条数据，索引的基本信息单元，以JSON格式来表示。 Shard 分片：在创建一个索引时可以指定分成多少个分片来存储。每个分片本身也是一个功能完善且独立的“索引”，可以被放置在集群的任意节点上。 Replication 备份: 一个分片可以有多个备份（副本）
为了方便理解，作一个ES和数据库的对比
下面对一些基础概念进行一个详细的说明，帮助大家更好的去理解。
文档
ElasticSearch是面向文档的，文档是所有可搜索数据的最小单位。例如：
日志文件中的日志项； 一张唱片的详细信息； 一篇文章中的具体内容；
在ElasticSearch中，文档会被序列化成Json格式：
Json对象是由字段组成的； 每个字段都有对应的字段类型（如：字符串、数值、日期类型等）；
每个文档都有一个唯一的ID（Unique ID）
可以自己指定此ID； 也可以通过ElasticSearch自动生成；
我们可以将文档理解成关系型数据库中的一条数据记录，一条记录包含了一系列的字段。
Json文档的格式不需要预先定义
字段的类型可以指定或者由ElasticSearch自动推算； Json支持数组、支持嵌套;
每一个文档中都包含有一份元数据，元数据的作用主要是用来标注文档的相关信息，如：
_index：文档所属的索引名； _type：文档所属的类型名（从7.0开始，每一个索引只能创建一个Type:_doc，在此之前一个索引是可以设置多个Type的）； _id：文档的Unqie Id； _source：文档的原始Json数据； _version：文档的版本信息； _score：文档的相关性算分；
索引（Index）
索引指的就是一类文档的集合，相当于文档的容器。
索引体现了逻辑空间的概念，每个索引都有自己的Mapping定义，用来定义所包含的文档的字段名和字段类型； 索引中的数据（文档）分散在Shard（分片）上，Shard体现了物理空间的概念；
索引的Mapping与Setting
Mapping定义文档字段的类型；
Setting定义不同的数据分布；
索引的含义
一般说“索引文档到ElasticSearch的索引中”，前面的索引指的是一个动词的含义，也就是保存一个文档到ElasticSearch中。后面的索引是指在ElasticSearch集群中，可以创建很多个不同的索引；
索引分为：B树索引和倒排索引，而倒排索引在ElasticSearch中是非常重要的；
ElasticSearch与RDBMS的代入理解与类比如下
两者相对比，若对数据进行全文检索，以及进行算分时，ElasticSearch更加合适；当涉及的数据事务比较高时，那RDBMS更加合适。在实际生产中，一般是两者进行结合使用。
集群
ElasticSearch集群实际上是一个分布式系统，而分布式系统需要具备两个特性：
高可用性 服务可用性：允许有节点停止服务； 数据可用性：部分节点丢失，不会丢失数据； 可扩展性 随着请求量的不断提升，数据量的不断增长，系统可以将数据分布到其他节点，实现水平扩展；
ElasticSearch的集群通过不同的名字来进行区分，默认名字“elasticsearch”；可以通过配置文件修改或者命令行修改：-E cluster.name=test一个集群中可以有一个或者多个节点。
节点
节点是什么？
节点是一个ElasticSearch的实例，其本质就是一个Java进程； 一台机器上可以运行多个ElasticSearch实例，但是建议在生产环境中一台机器上只运行一个ElasticSearch实例；
每个节点都有名字，可以通过配置文件进行配置，也可以通过命令行进行指定，如：**-E node.name=node1**
每个节点在启动之后，会被分配一个UID，保存在data目录下；
Master-Eligible【有资格、胜任者】 Node与Master Node的说明：
每个节点启动之后，默认就是一个Master Eligible节点，当然可以在配置文件中将其禁止，node.master:false Master-Eligible Node可以参加选主流程，成为Master Node； 当第一个节点启动时，它会将其选举为Master Node； 每个节点都保存了集群状态，但只有Master Node才能修改集群的状态，包括如下： 所有的节点信息； 所有的索引和其相关的Mapping与Setting信息； 分片的路由信息；
Data Node与Coordinating【协调、整合】 Node的说明：
Data Node：可以保存数据的节点，负责保存分片数据，在数据扩展上起到至关重要的作用； Coordinating Node：它通过接受Rest Client的请求，会将请求分发到合适的节点，最终将结果汇集到一起，再返回给Client； 每个节点都默认起到Coordinating Node的职责；
Hot Node（热节点）与Warm Node（冷节点）的说明：
Hot Node：有更好配置的节点，其有更好的资源配置，如磁盘吞吐、CPU速度； Warm Node：资源配置较低的节点；
Machine Learning Node：负责机器学习的节点，常用来做异常检测；
配置节点类型
每个节点在启动时，会读取elasticsearch.yml配置文件，来确定当前节点扮演什么角色。在生产环境中，应该将节点设置为单一的角色节点，这样可以有更好的性能，更清晰的职责，可以针对节点的不同给予不能的机器配置。 
更多关于 ElasticSearch 数据库的学习文章，请参阅：NoSQL 数据库之 ElasticSearch ，本系列持续更新中。
分片
Primary Shard（主分片）
可以解决数据水平扩展的问题，通过主分片，可以将数据分布到集群内的所有节点之上。
一个主分片是一个运行的Lucene的实例；
注意：
一个节点对应一个ES实例； 一个节点可以有多个index（索引）； 一个index可以有多个shard（分片）； 一个分片是一个lucene index（此处的index是lucene自己的概念，与ES的index不是一回事）；
主分片数是在索引创建时指定，后续不允许修改，除非Reindex；
Replica Shard（副本）
可以解决数据高可用的问题，它是主分片的拷贝。
副本分片数可以动态调整； 增加副本数，在一定程度上可以提高服务的可用性；
分片的设定
对于生产环境中分片的设定，需要提前做好容量规划，因为主分片数是在索引创建时预先设定的，后续无法修改。
分片数设置过小 导致后续无法增加节点进行水平扩展。 导致分片的数据量太大，数据在重新分配时耗时； 分片数设置过大 影响搜索结果的相关性打分，影响统计结果的准确性； 单个节点上过多的分片，会导致资源浪费，同时也会影响性能；
学习ElasticSearch的入手层面
开发层面
了解ElasticSearch有基本功能； 底层分布式工作原理； 针对数据进行数据建模；
运维层面
进行集群的容量规划； 对集群进行滚动升级； 对性能的优化； 出现问题后，对问题的诊断与解决；
方案层面
学习ElasticSearch后，可以针对实际情况，解决搜索的相关问题； 可以将ELK运用到大数据分析场景中；
Elastic Stack生态
Beats + Logstash + ElasticSearch + Kibana如下是我从官方博客中找到图，这张图展示了ELK生态以及基于ELK的场景（最上方）。
由于Elastic X-Pack是面向收费的，所以我们不妨也把X-Pack放进去，看看哪些是由X-Pack带来的，在阅读官网文档时将方便你甄别重点：
更多关于 ElasticSearch 数据库的学习文章，请参阅：NoSQL 数据库之 ElasticSearch ，本系列持续更新中。
Beats
Beats是一个面向轻量型采集器的平台，这些采集器可以从边缘机器向Logstash、ElasticSearch发送数据，它是由Go语言进行开发的，运行效率方面比较快。从下图中可以看出，不同Beats的套件是针对不同的数据源。
Logstash
Logstash是动态数据收集管道，拥有可扩展的插件生态系统，支持从不同来源采集数据，转换数据，并将数据发送到不同的存储库中。其能够与ElasticSearch产生强大的协同作用，后被Elastic公司在2013年收购。
它具有如下特性：
1）实时解析和转换数据； 2）可扩展，具有200多个插件； 3）可靠性、安全性。Logstash会通过持久化队列来保证至少将运行中的事件送达一次，同时将数据进行传输加密； 4）监控；
ElasticSearch
ElasticSearch对数据进行搜索、分析和存储，其是基于JSON的分布式搜索和分析引擎，专门为实现水平可扩展性、高可靠性和管理便捷性而设计的。
它的实现原理主要分为以下几个步骤：
1）首先用户将数据提交到ElasticSearch数据库中； 2）再通过分词控制器将对应的语句分词； 3）将分词结果及其权重一并存入，以备用户在搜索数据时，根据权重将结果排名和打分，将返回结果呈现给用户；
ElasticSearch与DB的集成
针对上图，可以分为两种情况：
将ElasticSearch当成数据库来存储数据，好处是架构比较简单； 若数据更新比较频繁，同时需要考虑数据事务性时，应该先将数据存入数据库，然后建立一个合适的同步机制，将数据同步到ElasticSearch中；
Kibana
Kibana实现数据可视化，其作用就是在ElasticSearch中进行民航。Kibana能够以图表的形式呈现数据，并且具有可扩展的用户界面，可以全方位的配置和管理ElasticSearch。
Kibana最早的时候是基于Logstash创建的工具，后被Elastic公司在2013年收购。
1）Kibana可以提供各种可视化的图表； 2）可以通过机器学习的技术，对异常情况进行检测，用于提前发现可疑问题； 更多关于 ElasticSearch 数据库的学习文章，请参阅：NoSQL 数据库之 ElasticSearch ，本系列持续更新中。
从日志收集系统看 ES Stack的发展
我们看下ELK技术栈的演化，通常体现在日志收集系统中。
一个典型的日志系统包括：
收集：能够采集多种来源的日志数据 传输：能够稳定的把日志数据解析过滤并传输到存储系统 存储：存储日志数据 分析：支持 UI 分析 警告：能够提供错误报告，监控机制
beats+elasticsearch+kibana
Beats采集数据后，存储在ES中，有Kibana可视化的展示。
beats+logstath+elasticsearch+kibana
该框架是在上面的框架的基础上引入了logstash，引入logstash带来的好处如下：
（1）Logstash具有基于磁盘的自适应缓冲系统，该系统将吸收传入的吞吐量，从而减轻背压。 （2）从其他数据源（例如数据库，S3或消息传递队列）中提取。 （3）将数据发送到多个目的地，例如S3，HDFS或写入文件。 （4）使用条件数据流逻辑组成更复杂的处理管道。
beats结合logstash带来的优势：
（1）水平可扩展性，高可用性和可变负载处理：beats和logstash可以实现节点之间的负载均衡，多个logstash可以实现logstash的高可用 （2）消息持久性与至少一次交付保证：使用beats或Winlogbeat进行日志收集时，可以保证至少一次交付。从Filebeat或Winlogbeat到Logstash以及从Logstash到Elasticsearch的两种通信协议都是同步的，并且支持确认。Logstash持久队列提供跨节点故障的保护。对于Logstash中的磁盘级弹性，确保磁盘冗余非常重要。 （3）具有身份验证和有线加密的端到端安全传输：从Beats到Logstash以及从 Logstash到Elasticsearch的传输都可以使用加密方式传递 。与Elasticsearch进行通讯时，有很多安全选项，包括基本身份验证，TLS，PKI，LDAP，AD和其他自定义领域
增加更多的数据源 比如：TCP，UDP和HTTP协议是将数据输入Logstash的常用方法。
beats+MQ+logstash+elasticsearch+kibana
在如上的基础上我们可以在beats和logstash中间添加一些组件redis、kafka、RabbitMQ等，添加中间件将会有如下好处：
（1）降低对日志所在机器的影响，这些机器上一般都部署着反向代理或应用服务，本身负载就很重了，所以尽可能的在这些机器上少做事； （2）如果有很多台机器需要做日志收集，那么让每台机器都向Elasticsearch持续写入数据，必然会对Elasticsearch造成压力，因此需要对数据进行缓冲，同时，这样的缓冲也可以一定程度的保护数据不丢失； （3）将日志数据的格式化与处理放到Indexer中统一做，可以在一处修改代码、部署，避免需要到多台机器上去修改配置； 更多关于 ElasticSearch 数据库的学习文章，请参阅：NoSQL 数据库之 ElasticSearch ，本系列持续更新中。
Elastic Stack最佳实践
我们再看下官方开发成员分享的最佳实践。
日志收集系统
基本的日志系统
增加数据源，和使用MQ
Metric收集和APM性能监控
多数据中心方案
通过冗余实现数据高可用
两个数据采集中心（比如采集两个工厂的数据），采集数据后的汇聚
数据分散，跨集群的搜索
