引子
很多搜索引擎都是基于倒排索引,比如luncene,solr以及elasticsearch
正排索引
聊倒排搜索之前先来看看正排索引,正排其实就是数据库表,他通过id和数据进行关联,如下:
数据id | 数据内容 |
---|---|
1001 | 苹果公司发布iPhone |
1002 | 地球引力起源于苹果 |
1003 | iPhone屏幕碎了 |
1004 | 我在苹果商店维修屏幕 |
1005 | 我刚刚吃了苹果 |
我们可以通过搜索id,来获得相应的数据,也能删除数据。你买了一本书,书的目录其实也是正排搜索。
假设现在我要搜苹果
俩字,那么他会对这张表格中每一行的数据做匹配,去查找一下,是否包含苹果
这两个字,从第一条匹配到最后一条,如果一张表中数据量不多,几万,十几万,那么问题不大,但是一旦数据量有上百万,上千万,那么全表扫描这种的搜索性能就会有影响。
其次,这个时候我想搜索苹果iPhone
,那么我们无法把这词汇拆开再到数据库去搜索。
- 优点:使用起来方便,原理也简单,比较入门
- 缺点:检索效率低下,适合简单场景使用,比如传统项目,数据量较小的项目。不支持分词搜索。
倒排索引
与正排是反着来的,他会把文档内容进行分词,比如苹果公司发布iPhone
是一个文档数据,当我们把他存入到搜索引擎中去的时候,会有一个文档id,这个文档id就类似于数据库主键。但是这文档存储的时候和数据库不一样,他会进行一个分词,参照上面的表格,分词后的结果如下:
文档数据 | 分词结果 |
---|---|
苹果公司发布iPhone | 苹果,公司,发布,iPhone |
地球引力起源于苹果 | 地球,引力,起源,于,苹果 |
iPhone屏幕碎了 | iPhone,屏幕,碎了 |
我在苹果商店维修屏幕 | 我,在,苹果,商店,维修,屏幕 |
我刚刚吃了苹果 | 我,刚刚,吃了,苹果 |
每一个词汇都会和文档id关联起来,可以根据词汇来找到所有出现的id列表,如下:
词汇 | 文档ids |
---|---|
苹果 | 1001,1002,1004,1005 |
iPhone | 1001,1003 |
公司 | 1001 |
发布 | 1001 |
地球 | 1001 |
引力 | 1001 |
起源 | 1001 |
于 | 1001 |
屏幕 | 1003,1004 |
碎了 | 1003 |
我 | 1004,1005 |
在 | 1004 |
商店 | 1004 |
维修 | 1004 |
刚刚 | 1005 |
吃了 | 1005 |
假设现在我要搜索iPhone
,如果是数据库搜索,假设有1亿条数据,那么会匹配1亿次,全表扫描。最后再把数据返回出来。
如果是搜索引擎,那么有可能第一次就把所有文档数据给查出来,当然也有可能是第N次,当然他肯定要比数据库的搜索效率更高。如图中位置,他会直接把1001,1003
两个文档返回。
可能会有同学会问,数据库和搜索引擎都是1000万数据,搜索的词汇在搜索引擎中正好是第1000万条,那么会不会慢,其实这个肯定会比数据库更快,数据库要匹配是一个文本中的内容和关键词匹配,而搜索引擎是直接把关键字做匹配,效率肯定后者更快。
- 有点:搜索更快,耗时短,用户体验高,精装度也高
- 缺点:维护成本高,索引新建后要修改,必须先删除,前期需要很好地规划