背景
我们开发一般的企业级Web应用，其实从本质上来说，都是对数据的增删查改进行各个维度的包装。所以说，不管你的程序如何开发，基本上，都离不开数据本身。那么，在开发企业级应用的过程中，很多同学一定遇到过这样的困惑，当完成了应用程序的基本增删查改功能之后，用户会经常吐槽当下的查询功能并不能满足自己的查询需求。这是因为，通常情况下，我们基于传统的数据库进行开发，都是需要预先去进行各种方面的考虑，然后再开发相应的查询语句。与其说是查询语句，不如说是数据过滤语句。这种时候，一个全能的搜索引擎就非常有必要了，通常我们期望它可以检索各类允许被用户查询的数据类型，充分的去已有的数据中检索用户想要的数据，并且还能进行智能排序，给用户最想要的。那么，问题来了，传统的MySQL想要实现这么一个搜索引擎，谈何容易，我该怎么办?
ElasticSearch or MySQL?
What is ElasticSearch
ElasticSearch是一个基于Lucene的分布式搜索引擎，业内简称ES。它提供了基于RESTful 风格的全文搜索API。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前最流行的企业级搜索引擎。另外，它的分布式设计让它天生就适合用于云计算中，并能够达到准实时搜索，而且安装使用方便，还拥有稳定，可靠，快速等特性。大家可以查阅更多的相关资料对ElasticSearch有更深入的了解。
Why Not MySQL
MySQL作为传统的关系型数据库，是当下Web应用开发中最流行的关系型数据库，没有之一。那么，很多同学会说，我对MySQL非常的了解，各种技巧，样样精通，直接用MySQL实现搜索引擎不就得了?这里我们来举个比较实际的例子，看一下到底MySQL适不适合做搜索引擎。
假设我要求职，这里我们有一张职位数据表jobs，我想从中检索一些我想要的工作，一般我会先想好关键词，比如舒适办公环境、有良好晋升空间等，如果用MySQL实现，你可能会这样写SQL：SELECT * FROM jobs WHERE job_desc LIKE %关键词%。这样做，理论上是可以搜到一些数据的，比如和用户输入的关键词完全匹配的就可以，但是假设jobs表中很多对工作职位的描述换了个说法，比如办公环境舒适、晋升空间良好等，颠倒了词的顺序，LIKE关键词肯定是匹配不到了。另外，LIKE是全表扫描的一个操作，如果你的数据量较小，还好说，但如果你数据量在百万、千万甚至更多的时候，耗时将是不可想象的，更别说还有恼人的分词问题，单单使用MySQL是无法解决的。
Why Not Sphinx MySQL
当然，有很多同学会说，MySQL确实不适合直接做检索，但是我可以利用Sphinx中间件结合MySQL来做搜索引擎。确实，Sphinx也是一款比较优秀的搜索引擎。在某些方面，它很适合和MySQL做结合来使用。但是，Sphinx和ElasticSearch比起来，却逊色不少。一方面，在复杂查询逻辑下，Sphinx使用非常麻烦，在特定情况下，还需要修改Sphinx的源码才能实现需求，而我们ES天生就拥有非常丰富的Query DSL，可以满足几乎任何的检索情况;另一方面，在横向扩展和高可用方面，Sphinx实现分布式可谓是没事找抽型，它并不是做不到，而是实在是太难用了，而ES从一出生就是为分布式、集群化而生的，不仅方便横向扩展、动态增加节点，还可以轻松的和Nginx等各类中间件实现负载均衡。
ElasticSearch and MySQL
通常，我们可以使用ES来实现自己的站内搜索引擎，但是，瓦力这里还是推荐大家使用MySQL来做原始数据的存储，然后基于MySQL在上层部署我们的ES中间件来实现我们的搜索引擎。主要原因是，MySQL虽然在数据全文检索方面显得有些力不从心，但是因为它的事务功能特性，可以保证不会出现脏数据。而ES对事务方面并无建树，所以不是很适合存储原始数据。当然，你可以运用双写的策略，一方面利用MySQL保证原始数据的安全性，另一方面，利用ES的搜索力量。不过，瓦力这边更推荐的是将两个中间件直接结合起来，同时使用ES查询数据，并结合MySQL做数据的增删查改，具体实现细节，因人而异，大家还是要根据实际的需求来制定最优的解决方案。
总结
ElasticSearch作为当下越来越火爆的分布式搜索引擎以及大数据分析中间件，在互联网技术中，已经占据了半壁江山，在BAT等各大互联网公司都有不同程度的应用，成为了程序猿小朋友不可忽视的一门刚需技术。
