ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于Restful API。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
为什么要选择Elasticsearch
ES的概念
ES是一个基于Lucene并采用Restful API 标准的高可扩展性和高可用性的实时数据分析的全文检索工具
倒排索引
倒排索引：搜索引擎的基础数据结构
- 我们在平时，会经常使用各种各样的索引，如我们根据链接，可以找到链接里的具体文本，这就是索引。
- 反过来，如果我们能根据具体文本，找到文本存在的具体链接，这就是倒排索引，可简单理解为从文本到链接的映射。
- 平时在使用Google、百度时，就是根据具体文本去找链接，这就是以倒排索引为基础的。
Elasticsearch与Solr的对比
Elasticsearch（简称ES）
优点
- 纯分布式的，有着完善的分片和副本机制。
- 接近实时的查询性能。
- 底层基于Apache Lucene，但是封装了更加易用的API。
- 处理多租户（multienancy）不需要特殊的配置，而slor则需要更多高级的配置。
缺点
- 起初只有一名开发者，但当前Elasticsearch Github社区非常活跃，日趋完善
- 还不够自动化，但是还在能够接受的范围（不适合当前新的index warmup API(热索引)）
- 一般只支持json格式的索引。
Solr
优点
- slor有一个更强大、更成熟的用户开发、贡献者社区。
- 支持添加多种格式的索引，如HTML、PDF、微软offfice系列软件格式以及json、xml、csv等纯文本格式。
- slor比较成熟、稳定。
- 不用考虑建索引的同时进行搜索，速度更快。
缺点
1.建立索引时，效率下降，实时搜索效率不高。
选择比较
- 当单纯地对已有数据进行搜索时，slor速度更快，大概是ES的1/4。
-
当实时建立索引时（边搜边添加索引），slor会产生IO阻塞，查询性能较差，ES则具有明显的优势。
2.png
-
随着数据量的增加，slor的数据量会变得更低，而ES却没有明显的变化。
3.png
小结：
- slor适合更加适用于稳定数据的搜索；ES更加适用于更新速度比较快、比较频繁的数据的搜索。
- slor适用于数据量小的搜索；ES适用于数据量大的搜索。
ES和slor对比总结
- 二者安装都很简单；
- slor利用zookeeper记性分布式管理，而ES自带分布式管理协调功能；
- slor支持更多格式的数据，而ES仅支持json文件格式；
- slor官方提供的功能更多，而ES本身更注重于核心功能，高级功能多有第三方插件提供，这样做有利有弊；
- slor在传统的搜索应用中表现好于ES，但在实施搜索应用时效率明显低于ES；
- slor是传统搜索应用的有力解决方案，但ES更适用于新兴的实时搜索应用。
ES的使用场景
场景—：使用Elasticsearch作为主要的存储后端
传统项目中，搜索引擎是部署在成熟的数据存储的顶部，以提供快速且相关的搜索能力。这是因为早期的搜索引擎不能提供耐用的存储或其他经常需要的功能，如统计。
Elasticsearch是提供持久存储、统计等多项功能的现代搜索引擎。如果你开始一个新项目，我们建议您考虑使用Elasticsearch作为唯一的数据存储，以帮助保持你的设计尽可能简单。此种场景不支持包含频繁更新、事务（transaction）的操作。举例如下：新建一个博客系统使用es作为存储。
- 我们可以向ES提交新的博文；
- 使用ES检索、搜索、统计数据。
ES作为存储的优势：如果一台服务器出现故障时会发生什么？你可以通过复制数据到不同的服务器以达到容错的目的。
注意：整体架构设计时，需要我们权衡是否有必要增加额外的存储。
场景二：在现有系统中增加elasticsearch
由于ES不能提供存储的所有功能，一些场景下需要在现有系统数据存储的基础上新增ES支持。
举例1：
ES不支持事务、复杂的关系（至少1.X版本不支持，2.X有改善，但支持的仍然不好），如果你的系统中需要上述特征的支持，需要考虑在原有架构、原有存储的基础上的新增ES的支持。
举例2：
如果你已经有一个在运行的复杂的系统，你的需求之一是在现有系统中添加检索服务。一种非常冒险的方式是重构系统以支持ES。而相对安全的方式是：将ES作为新的组件添加到现有系统中。如果你使用了如下图所示的SQL数据库和ES存储，你需要找到一种方式使得两存储之间实时同步。需要根据数据的组成、数据库选择对应的同步插件。可供选择的插件包括：
- mysql、oracle选择 logstash-input-jdbc 插件。
- mongo选择 mongo-connector工具。
假设你的在线零售商店的产品信息存储在SQL数据库中。 为了快速且相关的搜索，你安装Elasticsearch。为了索引数据，您需要部署一个同步机制，该同步机制可以是Elasticsearch插件或你建立一个自定义的服务。此同步机制可以将对应于每个产品的所有数据和索引都存储在Elasticsearch，每个产品作为一个document存储（这里的document相当于关系型数据库中的一行/row数据）。当在该网页上的搜索条件中输入“用户的类型”，店面网络应用程序通过Elasticsearch查询该信息。 Elasticsearch返回符合标准的产品documents，并根据你喜欢的方式来分类文档。 排序可以根据每个产品的被搜索次数所得到的相关分数，或任何存储在产品document信息，例如：最新最近加入的产品、平均得分，或者是那些插入或更新信息。 所以你可以只使用Elasticsearch处理搜索。这取决于同步机制来保持Elasticsearch获取最新变化。
场景三：使用elasticsearch和现有的工具
在一些使用情况下，您不必写一行代码就能通过elasticssearch完成一项工作。很多工具都可以与Elasticsearch一起工作，所以你不必到你从头开始编写。
例如，假设要部署一个大规模的日志框架存储，搜索，并分析了大量的事件。如图下图，处理日志和输出到Elasticsearch，您可以使用日志记录工具，如rsyslog（www.rsyslog.com），Logstash（www.elastic.co/products/logstash），或Apache Flume（http://flume.apache.org）。搜索和可视化界面分析这些日志，你可以使用Kibana。
基本概念
Node 与 Cluster
Elastic 本质上是一个分布式数据库，允许多台服务器协同工作，每台服务器可以运行多个 Elastic 实例。
单个 Elastic 实例称为一个节点（node）。一组节点构成一个集群（cluster）。
Index
Elastic 会索引所有字段，经过处理后写入一个反向索引（Inverted Index）。查找数据的时候，直接查找该索引。
所以，Elastic 数据管理的顶层单位就叫做 Index（索引）。它是单个数据库的同义词。每个 Index （即数据库）的名字必须是小写。
下面的命令可以查看当前节点的所有 Index。
$ curl -X GET 'http://localhost:9200/_cat/indices?v'
Document
Index 里面单条的记录称为 Document（文档）。许多条 Document 构成了一个 Index。
Document 使用 JSON 格式表示，下面是一个例子。
{
"user": "张三",
"title": "工程师",
"desc": "数据库管理"
}
同一个 Index 里面的 Document，不要求有相同的结构（scheme），但是最好保持相同，这样有利于提高搜索效率。
Type
Document 可以分组，比如weather这个 Index 里面，可以按城市分组（北京和上海），也可以按气候分组（晴天和雨天）。这种分组就叫做 Type，它是虚拟的逻辑分组，用来过滤 Document。
不同的 Type 应该有相似的结构（schema），举例来说，id字段不能在这个组是字符串，在另一个组是数值。这是与关系型数据库的表的一个区别。性质完全不同的数据（比如products和logs）应该存成两个 Index，而不是一个 Index 里面的两个 Type（虽然可以做到）。
下面的命令可以列出每个 Index 所包含的 Type。
$ curl 'localhost:9200/_mapping?pretty=true'
根据规划，Elastic 6.x 版只允许每个 Index 包含一个 Type，7.x 版将会彻底移除 Type。
