Elasticsearch查询速度为什么这么快？( 三 ) 这段时间在维护产品的搜索功

相对于 MySQL 中的 B+树来说也会减少了几次磁盘 IO 。
文章插图
这个 Term Index 我们可以使用这样的 Trie 树，也就是我们常说的字典树来存放。
文章插图
如果我们是以 j 开头的 Term 进行搜索，首先第一步就是通过在内存中的 Term Index 查询出以 j 打头的 Term 在 Term Dictionary 字典文件中的哪个位置(这个位置可以是一个文件指针，可能是一个区间范围) 。
紧接着在将这个位置区间中的所有 Term 取出，由于已经排好序，便可通过二分查找快速定位到具体位置;这样便可查询出 Posting List 。
最终通过 Posting List 中的位置信息便可在原始文件中将目标数据检索出来。
更多优化当然 Elasticsearch 还做了许多针对性的优化，当我们对两个字段进行检索时，就可以利用 Bitmap 进行优化。
比如现在需要查询 name=li and age=18 的数据，这时我们需要通过这两个字段将各自的结果 Posting List 取出。
文章插图
最简单的方法是分别遍历两个集合，取出重复的数据，但这个明显效率低下。
这时我们便可使用 Bitmap 的方式进行存储(还节省存储空间) ，同时利用先天的位与计算便可得出结果。
[1, 3, 5] ? 10101[1, 2, 4, 5] ? 11011 这样两个二进制数组求与便可得出结果：
10001 ? [1, 5] 最终反解出 Posting List 为 [1, 5] ，这样的效率自然是要高上许多。同样的查询需求在 MySQL 中并没有特殊优化，只是先将数据量小的数据筛选出来之后再筛选第二个字段，效率自然也就没有 ES 高。
当然在最新版的 ES 中也会对 Posting List 进行压缩，具体压缩规则可以查看官方文档，这里就不具体介绍了。
总结最后我们来总结一下：
文章插图
通过以上内容可以看出再复杂的产品最终都是基础数据结构组成，只是会对不同应用场景针对性的优化，所以打好数据结构与算法的基础后再看某个新的技术或中间件时才能快速上手，甚至自己就能知道优化方向。
最后画个饼，后续我会尝试按照 ES 倒排索引的思路做一个单机版的搜索引擎，只有自己写一遍才能加深理解。
来源：