ElasticSearch和Mysql查询原理分析与对比

ES现在已经越来越火，很多公司会把mysql里面的数据导入到ES，用ES来做海量数据的实时查询。许多不了解ES底层查询原理的人，会奇怪为什么ES能用来做海量数据的实时查询，为什么Mysql做不了？ 我进行了一些分析和对比，结论如下： 1.es天生的分布式架构，天然支持海量数据的分片和查询，而mysql不是分布式架构； 2.mysql和es底层索引结构导致即便是单片数据查询，es也更适合做查询引擎； 具体分析过程如下： 为什么mysql做不了海量数据的实时查询？ mysql的架构就不是分布式的架构，就算基于一些开源组件或者自研组件做了分库分表，也只能解决数据的存储问题，解决不了问题的查询问题。目前所有的分库分表中间件都会要求必须带上分库分表id去查询，也就是分库分表之后，你的查询，最终还是要落到某个库某张表去做单库单表的实时查询。 而ES为啥能够做海量数据的实时查询？ ES天生就是分布式架构，假如有一个学生表超过10亿条数据，导入es。首先第一件事情就是你要给这些数据做分片，假如分了10片后，用户想基于name去查询，es是怎么做的？这里我们假设是最简单的部署架构，es的节点A接收到查询请求后，会把请求转发到其他datanode，然后每个datanode接收到数据后，会在本机进行数据查询，然后将查询结果id，score返回节点A，然后由节点A对所有返回结果再进行排序和分页，然后节点A再去各个datanode，依据id拿到原始数据合并后返回给用户。 为什么mysql不这样做呢？为什么mysql的分开分表中间件不像es这样用一个节点去合并和处理数据呢？ 个人理解，不是mysql或者分库分表中间件不想做，而是根本做不了。原因是单库单表mysql也支持不了复杂查询条件下的实时查询，比如任意列的相互组合查询。（目前一些新的分布式数据库如TIDB，Oceanbase是否能够实现海量数据的多维度实时查询呢？他们对比es的优缺点又在哪里呢？需要后面进一步去梳理和分析） 想要快速查询，避免全表扫描，就需要索引。mysql可以对单列增加索引，也可以对多列增加索引，或者按照一定顺序建立多个字段的组合索引。但mysql的索引存在很多问题： mysql单列索引的问题是通常用户查询条件不会仅仅只有一个。 mysql多列索引问题是mysql引擎执行是只会选择最严格那一个索引执行，然后在其“中间结果集”上进行其他条件的过滤（后面可以看到es不是这样做的）。这意味着建多列索引实际上可能是无用的。 mysql组合索引的问题是建立组合索引，是要按照顺序的，而且执行的时候是从左到右匹配执行的，一旦查询条件不符合索引组合次序，或者查询条件多变，组合索引就会毫无用处。 大家都知道mysql的默认索引数据结构是B+tree，每增加一个索引，都是增加一个B+tree，就是因为这种数据结构导致了上面种种问题。更多mysql B+tree索引相关知识，请参考：深入理解MYSQL索引之B+TREE 那es的底层索引又是什么结构呢？为什么es可以做到多个字段任意组合查询呢？ es的底层是lucene，lucene的索引叫倒排索引（Inverted Index)。 下面是一个倒排索引的示例图： 倒排索引(Inverted Index)：倒排索引是实现“单词-文档矩阵”的一种具体存储形式，通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。比如上图中，lucene这个单词对应的documentId list就是2,3,10,35,92; 倒排索引主要由两个部分组成：“单词词典”和“倒排列表”。 单词词典(Lexicon)：搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。 倒排列表(PostingList)：倒排列表记载了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词。 倒排文件(Inverted File)：所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件即被称之为倒排文件。 关于这些概念之间的关系，通过下图可以比较清晰的看出来。

想了解更多倒排索引知识，请参考：什么是倒排索引

怎么从词典里面快速找到单词呢。这里可以使用的数据结构有很多，lucene使用了一种叫FST的数据结构：

想了解，FST是怎么实现的请参考：lucene字典实现原理

上面讲的单个字段的搜索，假如是多个字段的搜索，lucene是如何对多个字段的搜索结果进行合并的呢？

假如我们有下面三个倒排列表需要进行合并。 在lucene中会采用下列顺序进行合并： 1.在termA开始遍历，得到第一个元素docId=1 2.在termB的倒排列表中，查找docId= 1 是否存在。由于倒排表在lucene是用skiplist数据结构存储的，所以定位某个docid是否存在，速度会非常快，不需要一个一个遍历。 3.如果在termB的倒排列表不存在，执行步骤5； 4.如果在termB的倒排表中存在，继续在termC中查找是否存在，如果termC中存在，则该文档放入结果集；如果termC中不存在，执行步骤5； 5.从termA中获取下一个元素，然后重复过程2-4；

整个合并步骤我可以发现，如果某个链很短，拿它作为第一遍历list，会大幅减少比对次数，可以很快的返回最终的结果。 综上所述从倒排索引的定位，查询，合并整个流程和Mysql的B+tree索引相比，lucene的倒排索引明显更适合做数据的查询，此外倒排索引的合并灵活性也解决了mysql B+tree索引难以支持多条件查询的问题。 更多lucene查询过程，请参考：Lucene 查询原理