为什么需要 Elasticsearch

本文公众号来源：柳树的絮叨叨作者：靠发型吃饭的柳树本文已收录至我的GitHubElasticsearch是什么？ 

Elasticsearch is the distributed search and analytics engine at the heart of the Elastic Stack.

简单说，就是一个分布式的搜索与分析引擎。 

用数据库，也可以实现搜索的功能，为什么还需要搜索引擎呢？ 

就像 Stackoverflow 的网友说的： 

A relational database can store data and also index it.  A search engine can index data but also store it.  

数据库（理论上来讲，ES 也是数据库，这里的数据库，指的是关系型数据库），首先是存储，搜索只是顺便提供的功能，  

而搜索引擎，首先是搜索，但是不把数据存下来就搜不了，所以只好存一存。 

术业有专攻，专攻搜索的搜索引擎，自然会提供更强大的搜索能力。 

1、精确匹配和相关性匹配    

在使用数据库搜索时，我们更多的是基于「精确匹配」的搜索。 

什么是「精确匹配」？ 

比如搜订单，根据订单状态，准确搜索。搜「已完成」，就要「精确匹配」「已完成」的订单，搜「待支付」，就要「精确匹配」「待支付」的订单。 

这种「精确匹配」的搜索能力，传统关系型数据库是非常胜任的。 

和「精确匹配」相比，「相关性匹配」更贴近人的思维方式。  

比如我要搜一门讲过「莎士比亚」的课程，我需要在课程的文稿里进行「相关性匹配」，找到对应的文稿，

你可能觉得一条 sql 语句就可以解决这个问题： 

select * from course where content like "%莎士比亚%"

然而，这只能算是「模糊查询」，用你要搜索的字符串，去「精确」的「模糊查询」，其实还是「精确匹配」，机械思维。

那么到底什么是「相关性匹配」，什么才是「人的思维」呢？ 

比如我搜「莎士比亚」，我要的肯定不只是精精确确包含「莎士比亚」的文稿，我可能还要搜「莎翁」、「Shakespeare」、「哈姆雷特」、「罗密欧和朱丽叶」、「威尼斯的商人」…  

又比如我输错了，输成「莎士笔亚」，「相关性匹配」可以智能的帮我优化为「莎士比亚」，返回对应的搜索结果。

这就是搜索引擎的强大之处，它似乎可以理解你的真实意图。 

2、搜索和分析，不只是搜索，还有分析  

"search and analytics engine"，ES 不仅是搜索，还有分析。 

原始数据如果只是躺在磁盘里面根本就毫无用处。—— 《Elasticsearch 权威指南》

躺在磁盘里的数据是没有价值的，而ES则让你存放在里面的数据，拥有了无限的探索力。  

Elasticsearch 真正强大之处在于可以从无规律的数据中找出有意义的信息 —— 从“大数据”到“大信息”。—— 《Elasticsearch 权威指南》

和 mysql 一样，ES 提供了一些简单的聚合操作，avg、sum、min、max等等。   

当然，实际的业务场景，很多是无法通过这些聚合操作就能分析出想要的数据的，复杂的处理逻辑，还是要通过写业务代码来实现。 

实时计算的一种常见方案，是数据产生后，通过消息队列（比如kafka）推给实时计算平台 storm，计算后，再把数据存到 ES。 

貌似es在这里没有提供什么分析能力，然而只要数据存在于es，这些数据的被探索力就比放在数据库里的强，你随时可以在里面挖掘出商机。 

令我最为震惊的是，他们竟然不看表面数据，而是从无限数据的机会中寻找核心数据。  这正体现了大数据与传统数据之间最大的不同。以前，我们是“有问题找数据”，而在大数据时代，其最核心的特质则是“用数据找机会”  —— 《决战大数据》车品觉

这一切的分析数据的能力，都是建立在快速的查询上的，如果没有快速的查询，分析能力无从谈起。  

最后简单聊聊 ES 的内部原理。 

正如上文讲到的，术业有专攻，既然 ES 是专门做搜索的，内部实现细节自然和主要做存储的数据库不同。 

关系型数据库，把原本非常形象的对象，拍平了，拍成各个字段，存在数据库，查询时，再重新构造出对象；ES则是文档存储，把对象原原本本地放进去，取出时直接取出。  

Mysql基于B+树索引，来实现快速检索，ES则基于倒排索引，对于文档搜索来说，倒排索引在性能和空间上都有更加明显的优势。 

倒排索引很复杂，下次再讲。