05 | 倒排索引：如何从海量数据中查询同时带有“极”和“客”的唐诗？

作者回复: 非常棒！用不同的key进行区分的确是一个方案。另一个方案是可以在posting list中加域，标明是作者还是内容。 还有，倒排索引的检索效率优化是一个很重要的问题。你说的压缩位图是roaring bitmap，这的确是最近几年很火的一个应用。剧透一下，加餐会讲到。

作者回复: 就像你说的，邮件只需要检测一次，因此对邮件做倒排索引并不适用。而且倒排索引也解决不了近义词问题。 邮件敏感词检测一般是这样的思路: 1.准备一个敏感词字典。 2.遍历邮件，提取关键词，去敏感词字典中查找，找到了就说明邮件有敏感词。 这里的核心问题是如何提取关键词和如何在敏感词字典中查询。 一种方式是用哈希表存敏感词字典，然后用分词工具从邮件中提取关键字，然后去字典中查。 另一种方式是trie树来实现敏感词字典，然后逐字扫描邮件，用当前字符在trie树中查找。 不过，这两种方式都无法解决近义词，或者各种刻意替换字符的场景。要想解决这种问题，要么提供近义词字典，要么得使用大量数据进行训练和学习，用机器学习进行打分，将可疑的高分词找出来。 其实这种近义词处理方案，和搜索引擎解决近义词和查询纠错的过程很像。我在搜索引擎那篇里面会介绍。

作者回复: 工业社会的一个特点就是追求效率，如何能更快地完成事情是我们一直在追求的一个目标。检索技术可以说是我们在信息时代的加速器，它能帮助我们更快地获取信息，以及让系统更高速地运作。我相信它会持续地演化和影响我们的未来。

作者回复: posting list分域，就是一个元素里加上域标识。举个例子，一篇文章有标题，作者，内容三个域，而“李白”这两个字，可能出现在这三个位置。因此，key和posting list可以这么写: key =“李白” －> [id1，标题域:0，作者域:1，内容域:0]，[id2，标题域:1，作者域:0，内容域:1]

作者回复: 这样下定论会有一点过于绝对。 实际上，倒排索引是一种“根据属性/关键词来查询文章”的技术，只要有这个需要的场景都可以使用倒排索引。搜索引擎只是正好可以大规模使用这个技术的一个应用场景，但这并不意味着MySQL或者nosql不能使用倒排索引技术。实际上在MySQL中就是支持倒排索引的。并且，即使在搜索引擎中，微软的bing也开源了他们的向量检索技术，是基于树的检索技术，而不是倒排索引。 另一方面，列存储更多是一种减少磁盘io和节省存储空间的存储技术(而不是检索技术)。它也没有被明确限定只能在nosql中使用，实际上，关系型数据库也可以使用列存储。至于搜索引擎，它其实是更高层的一个业务应用，它会依赖一定的底层存储，比如说网页存取，索引存取等。这里面其实是可以用到nosql的存储技术的，也就是可以使用列存储的。

作者回复: 将“极客”作为一个单独的key进行索引是比较高效的。因为它只在检索时只需要直接将posting list取出即可。 当然，在分词不work的情况下，我们也可以单独对“极”和“客”进行检索，然后在对两个posting list归并时，判断这两个字的位置是否紧邻(在posting list中的每个元素，可以用pos数组记录key出现的所有位置)，这样就能判断是否存在“极客”的组合了。这就是搜索引擎会使用的短语查询的方案。你会发现，这种方法会相对耗时一些。

作者回复: 说得很好，这是更高效的检索方法，在后面加餐篇里我们就会提到这种哈希表法。 在这篇文章中，我想表述的意思是不借助其他的数据结构，单凭原始的链表本身，有序链表会比无序链表更便于查找。

作者回复: 你的思考很好！的确是这样的。你可以回到开头背唐诗的场景。如果只要求给题目背内容，那么是只需要正排索引就好。不需要倒排索引。 倒排索引是用在需要根据部分信息或者属性去反查出数据主体的场景中。搜索引擎就是典型的应用场景，因为我们只知道我们想找什么关键字，而不知道哪些网页有这些关键字，因此需要倒排索引。数据库也一样，很多时候，我们去数据库中查找，也不是直接找id，而是用where去限定一些属性和字段。因此，你会发现，根据我们关心的属性去寻找主体，这种需求其实很常见，这些场景就可以用倒排索引了。

作者回复: 你的问题我理解有两点: 1.检索效率问题。 2.存储空间问题。 关于检索效率问题，马上会出来两篇热腾腾的加餐，和你聊聊怎么进行倒排索引的检索加速。 关于存储空间问题，我接下来在进阶篇会开始介绍解决方案。

作者回复: 讨论区其实是一个思维碰撞的地方。毕竟文章篇幅有限，不可能事无巨细都说一遍。 因此，如果有什么不清楚的，或者想延展讨论的，都可以在这里交流，相信通过这样的交流，能让更多的人更深入地理解这些知识点。