1、什么是Elasticsearch

Elasticsearch（简写ES）是一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎，可以说 Lucene 是当今最先进，最高效的全功能开源搜索引擎框架。

Elasticsearch是基于Apache Lucene的搜索服务器。它由Shay Banon开发并于2010年发布。现在是由Elasticsearch BV负责维护。其最新版本是：5.2.0。

Elasticsearch是一个实时分布式和开源的全文搜索和分析引擎。它可以从RESTful Web服务接口访问，并使用模式少JSON(JavaScript对象符号)文档来存储数据。它是基于Java编程语言，这使Elasticsearch能够在不同的平台上运行。使用户能够以非常快的速度来搜索非常大的数据量。

2、Elasticsearch的特性

Elasticsearch的一般特性如下 -
（1）Elasticsearch可扩展高达PB级的结构化和非结构化数据。
（2）Elasticsearch可以用来替代MongoDB和RavenDB等做文档存储。
（3）Elasticsearch使用非标准化来提高搜索性能。
（4）Elasticsearch是受欢迎的企业搜索引擎之一，目前被许多大型组织使用，如Wikipedia，The Guardian，StackOverflow，GitHub等。
（5）Elasticsearch是开放源代码，可在Apache许可证版本2.0下提供。

3、Elasticsearch的主要概念

Elasticsearch的主要概念如下 -
（1）节点 - 它指的是Elasticsearch的单个正在运行的实例。单个物理和虚拟服务器容纳多个节点，这取决于其物理资源的能力，如RAM，存储和处理能力。
（2）集群 - 它是一个或多个节点的集合。集群为整个数据提供跨所有节点的集合索引和搜索功能。
（3）索引 - 它是不同类型的文档和文档属性的集合。索引还使用分片的概念来提高性能。例如，一组文档包含社交网络应用的数据。
（4）类型/映射 - 它是共享同一索引中存在的一组公共字段的文档的集合。例如，索引包含社交网络应用的数据，然后它可以存在用于用户简档数据的特定类型，另一类型可用于消息的数据，以及另一类型可用于评论的数据。
（5）文档 - 它是以JSON格式定义的特定方式的字段集合。每个文档都属于一个类型并驻留在索引中。每个文档都与唯一标识符(称为UID)相关联。
（6）碎片 - 索引被水平细分为碎片。这意味着每个碎片包含文档的所有属性，但包含的数量比索引少。水平分隔使碎片成为一个独立的节点，可以存储在任何节点中。主碎片是索引的原始水平部分，然后这些主碎片被复制到副本碎片中。
（7）副本 - Elasticsearch允许用户创建其索引和分片的副本。复制不仅有助于在故障情况下增加数据的可用性，而且还通过在这些副本中执行并行搜索操作来提高搜索的性能.

4、Lucene与ES的关系

（1）Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。
（2）Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

5、ES主要解决的问题

1）检索相关数据；
2）返回统计结果；
3）速度要快。

6、ES的工作原理

当ElasticSearch的节点启动后，它会利用多播(multicast)(或者单播，如果用户更改了配置)寻找集群中的其它节点，并与之建立连接。这个过程如下图所示：
在这里插入图片描述

7、Elasticsearch的优点

（1）Elasticsearch是基于Java开发的，这使得它在几乎每个平台上都兼容。
（2）Elasticsearch是实时的，换句话说，一秒钟后，添加的文档可以在这个引擎中搜索得到。
（3）Elasticsearch是分布式的，这使得它易于在任何大型组织中扩展和集成。
（4）通过使用Elasticsearch中的网关概念，创建完整备份很容易。
（5）与Apache Solr相比，在Elasticsearch中处理多租户非常容易。
（6）Elasticsearch使用JSON对象作为响应，这使得可以使用不同的编程语言调用Elasticsearch服务器。
（7）Elasticsearch支持几乎大部分文档类型，但不支持文本呈现的文档类型。

8、Elasticsearch的缺点

（1）Elasticsearch在处理请求和响应数据方面没有多语言和数据格式支持(仅在JSON中可用)，与Apache Solr不同，Elasticsearch不可以使用CSV，XML等格式。
（2）Elasticsearch也有一些伤脑的问题发生，虽然在极少数情况下才会发生。

9、Elasticsearch和RDBMS之间的比较

在Elasticsearch中，索引是类型的集合，因为数据库是RDBMS(关系数据库管理系统)中表的集合。每个表都是行的集合，就像每个映射都是JSON对象的Elasticsearch集合一样。
在这里插入图片描述
（1）关系型数据库中的数据库（DataBase），等价于ES中的索引（Index）
（2）一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type），
（3）一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成。
（4）在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等。
（5）在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改_update、查GET.

10、为什么要用ES

ES国内外使用优秀案例
（1） 2013年初，GitHub抛弃了Solr，采取ElasticSearch 来做PB级的搜索。 “GitHub使用ElasticSearch搜索20TB的数据，包括13亿文件和1300亿行代码”。
（2）维基百科：启动以elasticsearch为基础的核心搜索架构。
（3）SoundCloud：“SoundCloud使用ElasticSearch为1.8亿用户提供即时而精准的音乐搜索服务”。
（4）百度：百度目前广泛使用ElasticSearch作为文本数据分析，采集百度所有服器上
的各类指标数据及用户自定义数据，通过对各种数据进行多维分析展示，辅助定位分析实例异常或业务层面异常。目前覆盖百度内部20多个业务线（包括casio、云分析、网盟、预测、文库、直达号、钱包、风控等），单集群最大100台机器，200个ES节点，每天导入30TB+数据。

11、我们也需要

实际项目开发实战中，几乎每个系统都会有一个搜索的功能，当搜索做到一定程度时，维护和扩展起来难度就会慢慢变大，所以很多公司都会把搜索单独独立出一个模块，用ElasticSearch等来实现。

近年ElasticSearch发展迅猛，已经超越了其最初的纯搜索引擎的角色，现在已经增加了数据聚合分析（aggregation）和可视化的特性，如果你有数百万的文档需要通过关键词进行定位时，ElasticSearch肯定是最佳选择。当然，如果你的文档是JSON的，你也可以把ElasticSearch当作一种“NoSQL数据库”，应用ElasticSearch数据聚合分析（aggregation）的特性，针对数据进行多维度的分析。

ES在某些场景下替代传统DB

个人以为Elasticsearch作为内部存储来说还是不错的，效率也基本能够满足，在某些方
面替代传统DB也是可以的，前提是你的业务不对操作的事性务有特殊要求；而权限管理也不用那么细，因为ES的权限这块还不完善。

由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作，没有大量的单文档请求（比如通过userid来找到一个用户的文档，类似于NoSQL的应用场景），所以能否替代 NoSQL还需要各位自己的测试。

如果让我选择的话，我会尝试使用ES来替代传统的NoSQL，因为它的横向扩展机制太方便了。

Elasticsearch剖析