1、Elasticsearch 简介

1.1 Elasticsearch 是什么

1. 海量数据的分布式存储以及集群管理，达到了服务与数据的高可用以及水平扩展。

2. 近实时搜索，性能卓越。对结构化、全文、地理位置等类型数据的处理。

3. 海量数据的近实时分析（聚合功能）。

1. 网站搜索、垂直搜索、代码搜索。

2. 日志管理与分析、安全指标监控、应用性能监控、Web抓取舆情分析。

1.2 Elastic Stack生态

• Beats：轻量级收集平台，用于收集数据，可以直接对接 elasticsearch，但是只能做一些简单的处理，不一定能完全适配 elasticsearch 的数据类型，一般是对接到 Logstash 进行数据处理。

• Logstash：具备数据收集、分析、转换、提取等丰富的功能，如果只是单纯的收集日志没必要直接使用 Logstash，比较耗费性能Logstash。一般使用 Beats 进行日志收集，Logstash 只专注于数据处理的工作。

• Kibana：数据可视化，能够以图表的形式呈现数据，并且具有可扩展的用户界面，可以全方位的配置和管理ElasticSearch。

1.3 搜索引擎的基本原理

• 数据采集模块：负责采集需要搜索的数据源。对于Elasticsearch而言，数据采集模块既可以是官方指定的Beats工具，也可以是第三方提供的ETL工具，还可以是使用Java客户端写入的数据。总之，这个模块的目的就是把用户需要搜索的数据采集起来以备写入搜索引擎。为了提高采集数据的效率，可以使用多线程和分布式等手段，再配合一些比较好的采集策略（例如时间戳增量采集）来满足实际项目的需要。

• 文本分析模块：把结构化数据中的长文本切分成有实际意义的词，这样当用户把这些切分出来的词用作查询条件时就可搜索到该文本。如果不做文本分析，就要把原始文本全部写入索引才能搜索到需要的文本，这在某些时候可能是必要的，但是对于长篇幅的文本，直接写入原始的文本数据可能没有太大的意义。在创建索引时，你可以根据实际业务的情况来决定是否在文本数据写入索引以前进行分词。

• 索引存储模块：负责将数据采集模块写入的数据按照定义好的结构写入索引。搜索引擎的索引数据是按照倒排索引的结构进行组织的。倒排索引是一种特殊的数据结构，它保存着每个词在索引中的文档编号以及它们出现在文档的位置。Elasticsearch的索引存储模块除了能把写入的数据组织成倒排索引的结构，还管理着数据的存储方式、路由方式、事务日志、索引状态等。

• 搜索模块：根据用户输入的查询文本找到索引中匹配的文档，相关度越高的文档排名越靠前。在返回最终的搜索结果时，搜索引擎会使用一套相关度计算公式来计算每个搜索结果与搜索文本的相关度分值，然后把搜索结果列表按照相关度分值由高到低进行返回。

2、Elasticsearch 安装启动

3、Elasticsearch 架构

• 数据存储层：Gateway 是 Elasticsearch 索引的持久化存储方式，ES 默认是先把索引存放到内存中，当内存满了之后，再持久化到硬盘里。当这个 Elasticsearch 集群关闭或者再次重新启动时就会从 Gateway 中读取索引数据。 Gateway支持多种类型：本地文件系统（默认）、分布式文件系统 Hadoop 以及 AMZ 的 S3 云存储服务。ES目前主要使用 Local FileSystem，主要利用本机节点、本地文件系统存储索引和文档，其他三个都废弃掉了。

• 核心架构层：Elasticsearch 是基于 Lucene 架构实现的，所以其核心层为 Lucene。Lucene 是一个开源的全文检索引擎工具包和编程库，提供了原始接口调用，直接使用 Lucene，你需要覆盖大量的集成框架工作，复杂性较高，而且只能支持单体架构的搜索。Elasticsearch 底层是基于这些包，对其进行了扩展和集成，隐藏了 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API，实现了 Lucene 的分布式架构，提供了比 Lucene 更为丰富的查询语言，可以非常方便的通过 Elasticsearch 的 HTTP 接口与底层 Lucene 交互。

• 数据处理层：包含四个模块：
• Index Module：索引模块，就是对数据建立索引也就是通常所说的建立一些倒排索引等。
• Search Module：搜索模块，就是对数据进行查询搜索。
• Mapping Module：数据映射与解析模块，就是你的数据的每个字段可以根据你建立的表结构通过 mapping 进行映射解析，如果你没有建立表结构，es 就会根据你的数据类型推测你的数据结构之后自己生成一个 mapping，然后都是根据这个 mapping 进行解析你的数据。
• River Module：在 es2.0 之后应该是被取消了，它的意思表示是第三方插件，例如可以通过一些自定义的脚本将传统的数据库（mysql）等数据源通过格式化转换后直接同步到es集群里，这个 River 大部分是自己写的，写出来的东西质量参差不齐，将这些东西集成到 es 中会引发很多内部 bug，严重影响了 es 的正常应用，所以在 es2.0 之后考虑将其去掉。

• 发现/脚本层：包含三个模块：
• Discovery：Discovery 是集群中节点之间发现的组件。es是一个集群包含很多节点，很多节点需要互相发现对方，然后组成一个集群包括选主的，这些节点互相发现依赖 discovery 模块，默认使用的是 Zen。Zen 包含多播和单播两种方式。多播指一个节点可以向多台机器发送请求。生产环境中ES不建议使用这种方式，对于一个大规模的集群，组播会产生大量不必要的通信。单播指当一个节点加入一个现有集群，或者组建一个新的集群时，请求发送到一台机器。当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系Master节点并加入集群。单播也是ES 默认配置方式。
• Scripting：Scripting 是支持一些脚本语言的组件，包括 mvel、js、python 等等。但由于存在性能和使用场景少的问题，目前实际生产中使用比较少。
• 3rd Plugins：支持第三方插件的整合，留了入口，例如 ik 分词器。

• 协议层：包含两个模块：
• Transport：Transport 是 es 内部节点或集群与客户端的交互方式组件。默认是使用tcp协议进行交互，同时它支持http协议（json格式）、thrift、servlet、memcached、zeroMQ等的传输协议（通过插件方式集成）。
• JMX：使用 Java 提供的 JMX 框架，日常 ES 中使用比较少，作为了解部分即可。

• 应用层：包含两个模块
• RestFul API：官方推荐使用的提供给客户端的访问方式，直接发送http请求，可以方便做负载均衡和权限管理。
• Java API：如果是使用 Java 客户端，可以选择 Java API 的访问方式，利用 Netty，通过 JMX 协议，但是不好做负载均衡和权限管理。

4、Elasticsearch 基础概念

4.1 Cluster

4.2 Node

4.3 Index

4.4 Type

• 不同 Type 里的字段需要保持一致。例如，一个 Index 下的不同 Type 里有两个名字相同的字段，他们的类型（string, date 等）和配置也必须相同。

• 只在某个 Type 里存在的字段，在其他没有该字段的 Type 中也会消耗资源。得分是由 Index 内的统计数据来决定的。也就是说，一个 Type 中的文档会影响另一个 Type 中的文档的得分。这意味着，只有同一个 Index 的中的 Type 都有类似的映射 (mapping) 时，才应该使用 Type。否则，使用多个 Type 可能比使用多个 Index 消耗的资源更多。

• 6.x 版本，一个 Index 可以拥有多个 Type。

• 7.x 版本，一个索引只能拥有一个 Type，默认的 Type 是 _doc，已经建议不要用 Type。

• 8.x 版本，彻底删除。

4.5 Mapping

4.6 Field

4.7 Document

4.8 Shard

4.9 Replica

4.10 Elasticsearch的组件关系

• 一个 Cluster 集群由多个 Node 组成，每个节点都是一个 Elasticsearch 的实例。图中包含 Node1、Node2、Node3 三个 Node 实例。

• 一个 Index 分为多个 Shard，这些 Shard 分布到多个 Node 上，图中分为 P0 和 P1 两个 Shard，分别落在 Node1 和 Node3 上。

• 每个 Shard 分为主 Shard 和 Replica，分别落在不同的 Node 上。主 Shard P0 两个 Replica R0 分别落在 Node1 和 Node2 上。

• 每个 Shard 在底层对应着就是一个 Lucene Index。一个 Lucene Index 包含的内容：
• 由多个 Segment（段文件，就是倒排索引）组成，每个段文件存储着的就是 Doc 文档。
• commit point 记录了所有的 segments 的信息

4.11 Elasticsearch和Mysql的概念对比

5、Elasticsearch 版本变化

• 关系型数据库中两个数据表示是独立的，即使他们里面有相同名称的列也不影响使用，但ES中不是这样的。elasticsearch是基于Lucene开发的搜索引擎，而ES中不同type下名称相同的filed最终在Lucene中的处理方式是一样的。

• 两个不同type下的两个user_name，在ES同一个索引下其实被认为是同一个filed，你必须在两个不同的type中定义相同的filed映射。否则，不同type中的相同字段名称就会在处理中出现冲突的情况，导致Lucene处理效率下降。