[ElasticSearch从入门到场景实战]-为什么使用ElasticSearch

人生起起伏伏，有风光无限日，也有落魄失魂时，人在低谷时，唯有“熬过去，才会赢”

前言

ElasticSearch在互联网行业的应用越来越广泛，尤其在大数据和搜索领域，随着版本的迭代，功能也日益强大，ElasticSearch的前身是Compass，创造于2004年，在Compass的第三个版本中，创造者Shay Banon对其大部分进行了重写，并于2010年2月发布了Elasticsearch的第一个版本。目前市面上对于ElasticSearch的资料还是比较少，尤其是在一些场景下的结局方案，更是凤毛麟角。本系列内容重点在于了解ElasticSearch的使用场景，并从入门开始讲解，了解ElasticSearch的使用方式，和在一些场景下的解决方案。希望能帮助更多的人了解ElasticSearch，学习ElasticSearch，能更好的利用ElasticSearch去解决实际场景的问题。这是作者第一次写文章，如果有不满意或者有错误，还希望各位看官提出，作者会日渐努力去改善的。

ElasticSearch是一个基于Lucene库的搜索引擎，它提供了一个分布式多租户能力的全文搜索引擎，同时提供了HTTP Web接口和无模式JSON文档。ElasticSearch是使用JAVA语言开发的，客户端在主流的Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby等其他许多语言中都是可以使用的。

ES 的搜索引擎严重依赖于底层的 Filesystem Cache。如果Filesystem Cache可以分配到更多的内存，让内存足够去存放IDX Segment File 索引数据文件，那么数据基本就都是在内存中存放，所有的搜索都是直接在内存中查询，速度是非常快的。如果Filesystem Cache没有分配到足够的内存，数据不足以全部存放在内存中，剩下的数据就会去硬盘中读取，受限于硬盘的读写速度，那么性能便会大打折扣。

ElasticSearch是一个近实时搜索引擎，为什么说是近实时？首先，我们需要知道一个索引(index)，是由多个段(segment)组成的，新增的document会优先写入到indexing buffer区中，然后被重写成一个segment，之后再被写入到Filesystem Cache，数据被写入到Filesystem Cache中后，其实就已经可以被打开了，但实际上，Filesystem Cache中要打开一个新的segment需要一个refresh操作，这个操作在es中默认是1秒钟，这也是我们为什么说es是个近实时搜索引擎的原因。另外，数据写入到了Filesystem Cache中并不是已经结束了，数据还要进行持久化操作，在数据被写入到Filesystem Cache中后，经过一段时间或者外部触发，数据会执行fsync操作，对数据进行full commit写入到硬盘中。

类似于Google搜索，百度搜索和维基百科等，对全文关键字进行检索。es中提供了full-text search的查询方式，可以在在全文字段中搜索到最相关的文档。例如博客，就是对全文检索，检索到文章相应的关键字，展现给用户该文章的链接。

通过收集用户的行为日志，分析并建立用户模型，保存在es中，并利用es强大的深入搜索和聚合的能力，可以更好的分析和展示用户的行为数据。例如推荐系统，就是利用用户模型的用户数据，对用户数据交叉查询，分析出用户细粒度的喜好。

利用es高性能查询的特性，收集系统的监控数据，近实时展现监控数据，同时也方便用户对监控数据进行关键字排查。

常用的方案是ELK(elasticsearch+logstash+kibana)，利用logstash去收集logback的日志信息，再通过es做存储，最后可以再kibana去利用es api查看和分析日志的相关信息。

PART

01

可以搭建大型集群，去处理PB级数据，服务于大型企业，同时也可以单机部署，服务于小型企业

PART

02

集合了lucene的全文检索的特点，但又具有支持分布式技术，同时具有分析的能力，加上自身提供存储功能，部署简单，达到了真正开箱即用的便捷。

PART

03

拥有传统数据库的存储能力，又在其基础上增强了查询能力，并提供各种分析，检索的能力，可以处理海量数据，提供了很多数据库所无法提供的功能

这期目前就先写到这了，这是我第一次写技术文章，文笔也可能不是很好，中间如果有问题或者出错的地方，大家可以提出来，如果有幸你看到这篇文章，希望能点个赞，在此，感谢各位支持和点赞，谢谢！