Elasticsearch是什么？
1.1官方定义
Elasticsearch （简称ES）是一个天然支持分布式的搜索，聚合分析和存储引擎。
1.2 民间定义
- 搜索引擎
- 全文检索引擎
- 分布式文档系统
- 分布式数据库
- OLAP系统
- 分布式搜索中间件
1.3 ELK Stack
我们在使用Elasticsearch时，通常会听到 ELK Stack 那么ELk Stack具体是什么？
正如他的缩写ELk ELk由 Elasticsearch Logstash Kibana 这哥三组成的
Elasticsearch | Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 | |
|---|---|---|
Logstash | Logstash 是免费且开放的服务器端数据处理管道，能够从多个来源采集数据，转换数据，然后将数据发送到您最喜欢的“存储库”中。 | |
Kibana | Kibana 是一个免费且开放的用户界面，能够让您对 Elasticsearch 数据进行可视化，并让您在 Elastic Stack 中进行导航。 |
实际上ELK生态并非Elastic特意而为，它的产生可以算是“意外”，它的产生社区使用者推动而成，不过话虽这么说，但是现在的日志服务往往常与ELk进行对标，可见ELk的影响之深远。
1.4 Elastic Stack和ELK Stack区别
了解了ELK Stack 我们再来说说 Elastic Stack 是什么
Elastic Stack 是 原 ELK Stack 在 5.0 版本加入 Beats 套件后的新称呼。
Beats是轻量型数据采集器：集合了多种单一用途数据采集器。它们从成百上千或成千上万台机器和系统向 Logstash 或 Elasticsearch 发送数据。
Elasticsearch、Logstash、Kibana、Beats ，这几个放在一起，就叫作 Elastic Stack。
1.5 Elasticsearch，MongoDB与MySQL对比
Elasticsearch | MongoDB | MySQL | |
|---|---|---|---|
DB类型 | 搜索引擎 | 文档型数据库 | 关系型数据库 |
基于何种语言开发 | Java | C | C，C |
数据格式 | Json | Json | Row |
是否支持分布式 | 原生支持 | 原生支持 | 不支持 |
业务系统类型 | OLAP | OLTP | OLTP |
事务支持 | 不支持 | 多文档ACID事务 | 支持 |
数据分区方案 | 分片 | 分片 | 分库分表 |
数据量级 | PB级 | PB级 | 单库3000万 |
事务支持 | 不支持事务 | 弱事务支持 | 支持事务 |
注： OLAP是联机分析处理，OLTP是联机事务处理。正如其名OLAP支持复杂的分析操作，侧重决策支持，而OLTP主要重点是记录当前事务的更新、插入和删除(也就是我们常说的增，删，改，查）。
1.6 Elasticsearch和MongoDB的一些问题
在我们学Elasticsearch时候可能会遇到这么个问题
Elasticsearch和MongoDB这么像，为什么不能用MongoDB替代Elasticsearch呢？
这本身就是一个伪命题，它俩本就是不同的产品，一个是搜索引擎，一个是文档型数据库，也就是说MongoDB他本身擅长的领域是对于数据的管理（增删改查），Elasticsearch他擅长的领域数据检索（不是查询），也就是说ES是基于已经存在的数据进行检索。
当然还有别的区别，像是底层数据结构不同，业务系统类型不同。
有共性，也有特性
Elasticsearch的前世今生
想要理解Elasticsearch，我们首先要了解一个库，它的名字叫Lucene（Lucene是一套用于全文检索和搜寻的开源程式库，由Apache软件基金会支持和提供。Lucene提供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。）
在互联网初期各大互联网公司基本都是基于Lucene包装，业务代码跟核心库一起构建发布，这样不仅维护麻烦，而且每次修改都存在一定风险。
而且Lucene也很考验工程师个人素质，需要考虑的因素很多，如果个人素质不达标，稍有差错，后期程序可能会出大问题
于是在2004 年，有一个来自以色列的程序员，他的名字叫谢伊·班农（ Shay Banon），他结婚之后来到伦敦，他的夫人在伦敦学厨师。于是班农就打算写一个程序来管理和搜索菜谱。班农在编写程序的过程中，使用了 Lucene，感受到了Lucene 开发程序的各种痛苦。于是他在 Lucene 之上，封装了一个叫作 Compass 的程序框架，与 Hibernate和 JPA 等 ORM 框架进行集成，通过操作对象的方式来自动地调用 Lucene 以构建索引。 Compass的出现大大简化了给 Java 程序搜索功能的开发。Compass 开源出来，变得很流行。 在 Compass 编写到 2.x 版本的时候，在社区里面出现了更多的新需求。但是班农发现只有重写 Compass ，才能更好地实现这些需求，于是 Compass 3.0 就被砍了，取而代之的是一个全新的项目，也就是 Elasticsearch。
Solr和Elasticsearch的选择
可能各位在学习Elasticsearch的时候 或多或少的听说过Solr。
Solr是一个也是一个开源搜索引擎。它也建立在Lucen之上。 但是Solr的诞生时间是远早于Elasticsearch。它是企业级的，快速的和高度可扩展的。
- 基于什么框架开发：Lucene
- 基于何种语言开发：Java
- 数据结构：Json/XML/CSV
- 一致性策略：最终一致性
那么可能就会有读者问了“这么一看，好像都差不多，那为什么不选择Solr，要选择elasticsearch呢”
因为相比Elasticsearch，Solr在一些方面还是处于劣势
- 上手难度：总体来说Elasticsearch上手门槛是远低于Solr的
- 功能特点：ES 比 Solr 产品功能特点更加丰富，分片机制，数据分析能力。
- 海量数据处理能力：在Solr中一般情况下数据处理能力为TB级-PB级，Elasticsearch的处理能力是PB级起步，理论无上限
- 稳定性：随着数据量不断增大，Solr的稳定性是低于Elasticsearch的
- 生态方面：Elastic-stack 整个技术栈相当全，与各种数据系统都很容易集成。且ES 社区发展更加活跃，Solr 几乎没有专门的技术分析大会
这么一看Elasticsearch好像很完美啊，什么缺点也没有。其实不然，他也是优缺点的比如不支持事务，写入实时性低等。
结论
现在市面上几乎大大小小公司都在使用 Elasticsearch，除了老旧系统有的基于 Solr的，新系统项目应该全部是 Elasticsearch，所以我个人在Solr与Elasticsearch之间，推荐Elasticsearch
