ElasticSearch的应用环境

ElasticSearch的应用场景和优势，包括：

• 日志实时分析
• 搜索服务
• 数据分析
• 数据监控
• 查询服务
• 后端存储

日志分析

这个应用场景应该非常常见，日志分析，对于线上业务比较频繁的情况。

使用elk对数据进行分析采集和处理。

 这个是 ES 应用最广泛的领域，支持全栈的日志分析，包括各种应用日志、数据库日志、用户行为日志、网络数据、安全数据等等。ES 拥有一套完整的日志解决方案，可以秒级实现从采集到展示。

典型日志如下：

• 运营日志，比如慢日志、异常日志，用来定位业务问题；
• 业务日志，比如用户的点击、访问日志，可以用来分析用户行为；
• 审计日志，可以用于安全分析。ES 很完美的解决了日志实时分析的需求，它具有如下特点：

搜索服务

 

在搜索引擎中每个文件都对应一个文件ID，文件内容被表示为一系列关键词的集合（实际上在搜索引擎索引库中，关键词也已经转换为关键词ID）。例如“文档1”经过分词，提取了20个关键词，每个关键词都会记录它在文档中的出现次数和出现位置。

 

     得到正向索引的结构如下：

       “文档1”的ID > 单词1：出现次数，出现位置列表；单词2：出现次数，出现位置列表；…………。

       “文档2”的ID > 此文档出现的关键词列表。

 

　　一般是通过key，去找value。

 

      当用户在主页上搜索关键词“华为手机”时，假设只存在正向索引（forward index），那么就需要扫描索引库中的所有文档，找出所有包含关键词“华为手机”的文档，再根据打分模型进行打分，排出名次后呈现给用户。因为互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回排名结果的要求。

       所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词。

       得到倒排索引的结构如下：

       “关键词1”：“文档1”的ID，“文档2”的ID，…………。

       “关键词2”：带有此关键词的文档ID列表。

 

　　从词的关键字，去找文档。

 

 

什么时候应该用ElasticSearch?

1、典型搜索场景：闭着眼用它！

2、典型日志分析场景：闭着眼用它！

3、关系型数据库查询有瓶颈：考虑下用它！为啥是考虑？ES的优点在于查询，然而实践证明，在被作为数据库来使用，即写完马上查询会有延迟。

4、数据分析场景：考虑下用它！为啥是考虑？简单通用的场景需求可以大规模使用，但在特定业务场景领域，还是要选择更加专业的数据产品，如复杂聚合，ClickHouse相比 Elasticserach 做亿级别数据深度聚合需求会更加合适。

ElasticSearch有什么优势呢？

1、很简便的横向扩容，分布式的架构，可以轻松地对资源进行横向纵向扩缩容，可以满足不同数据量级及查询场景对硬件资源的需求。能由数百台到万台机器搭建满足PB级的快速搜索，也能搭建单机版服务小公司。

2、查询速度快：ES底层采用Lucene作为搜索引擎，并在此之上做了多重优化，保证了用户对数据查询数据的需求。可"代替"传统关系型数据库，也可用于复杂数据分析，海量数据的近实时处理等。

3、相关性高：ES内部提供了完善的评分机制，会根据分词出现的频次等信息对文档进行相关性排序，保证相关性越高的文档排序越靠前。另外还提供了包括模糊查询，前缀查询，通配符查询等在内的多种查询手段，帮助用户快速高效地进行检索。

4、功能点多但使用比较简便，开箱即用，性能优化比较简单

5、生态圈丰富，社区活跃，适配多种工具。如下图，处理日志和输出到Elasticsearch，您可以使用日志记录工具，如Logstash（www.elastic.co/products/logstash），搜索和可视化界面分析这些日志，你可以使用Kibana（www.elastic.co/产品/ kibana），即传说中的ELK技术栈。另外当前主流的大数据框架也几乎都支持ES，比如Flink和ES就是个完美搭档。