【编程二三事】ES究竟是个啥？

在最近的项目中，总是或多或少接触到了搜索的能力。而在这些项目之中，或多或少都离不开一个中间件 - ElasticSearch。
今天忙里偷闲，就来好好了解下这个中间件是用来干什么的。

ES是什么?

ES全称ElasticSearch，是个基于Lucene的搜索服务器。其作为一个高度可拓展的开源全文搜索和分析引擎，可用于快速对大数据进行存储，搜索和分析。

ElasticSearch和Logstash（数据收集、日志解析引擎）、Kibana（分析和可视化平台）一起开发的。这三个产品被设计成一个集成解决方案，称为“Elastic Stack”(以前被称为ELK技术栈)。

为什么要用ES？

传统关系数据库的缺陷

为了了解ES的优势在哪，我们首先需要回顾传统的mysql数据库作为搜索的时候都有哪些缺陷。

在我们日常搜索的时候，我们都需要通过输入关键词，去检索出来相关的数据。

以搜索“搜索引擎”为例子，你在百度、搜狗等搜索引擎中输入这个关键字，就会得到一系列的搜索结果：

如果这些结果都存储在Mysql数据库中，它大致会呈现如下的存储样式：

每一行会存储唯一标识id、数据内容。

因此，如果需要按照关系型数据库的方式，需要逐行进行搜索匹配相关词，甚至需要用上模糊搜索，如：‘LIKE %xx%’ 等。

且在mysql中，像这类模糊搜索语句，mysql是无法对其建立索引的。因此如果在大数据量下搜索将变得十分缓慢、困难。

而且另外一个点在于，对于搜索引擎来说，还需要将用户输入的词做拆分，依旧是以”搜索引擎“为例子，那么搜索结果其实需要同时包含“搜索”、“引擎”、“搜索引擎”的结果，而这无疑又一次加大了采用关系型数据库实现的复杂性。

总结下来，使用关系型数据库处理搜索问题，主要有两个较大的问题：模糊搜索困难、分词查询支持困难。

那么为什么关系型数据库会有这样的问题呢？本质上是关系型数据库的正排索引限制了其搜索性能。你可能这里会好奇了。什么是正排索引呀？

以上面的数据为例子，正排索引就是先找到对应的文章，而后才能够知道每个文章中对应的词是什么。绘制成图片大概就是下面的样子：

因此，如果用这样正排索引的方式搜索，相当于每次都要进行全表的扫描、匹配，那么自然很难支持搜索的能力。

ElasticSearch优势

倒排索引

上面我们总结了传统数据库实现搜索的主要难度在于：模糊搜索困难、分词查询困难。

而其归根结底是由于数据库的组织方式是通过正排索引实现的。导致了每次搜索需要匹配的难度大。

那么，这里可能就有聪明的同学想到了，如果根据文章搜索词的难度大，那么是否转变一下存储方式，先存词，再存文章，不就可以一下子搜索到了嘛！

如果你想到了这个，那么恭喜你，你已经具备从零开始研发ES的潜力的。没错，ES为了支持快捷的搜索，底层的实现也是这么做的，而这种实现方法就是大名鼎鼎的----“倒排索引”。

数据存储结构

要更深入的了解ES的倒排索引的设计逻辑，我们可以先参照Mysql的数据存储设计介绍几个ES中的常见名词：

Mysql等关系数据库	ElasticSearch数据库
数据库（dataBase）	索引（index）
表（table）	类型（type）
行（row）	文档（document）
列（column）	字段（field）

结合同Mysql的定义对比，我们就不难理解如下的ES数据代表什么含义了：

{
    "took": 1,
    "timed_out": false,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": {
            "value": 1,
            "relation": "eq"
        },
        "max_score": 1.0,
        "hits": [
            {
                "_index": "china",
                "_type": "_doc",
                "_id": "beijing",
                "_score": 1.0,
                "_source": {
                    "name": "beijing"
                }
            }
        ]
    }
}