wordpress视频网站用什么播放器,网站排序,中国网站排名查询,外贸网站建站i目录 全文检索 ------ 反向索引库 与 LuceneSQL模糊查询的问题反向索引库反向索引库的查询 Lucene#xff08;全文检索技术#xff09;Lucene能做什么Lucene存在的问题Solr 和 Elasticsearch 与 Lucene 的关系 全文检索 ------ 反向索引库 与 Lucene MySQL一些索引词汇解释 … 目录 全文检索 ------ 反向索引库 与 LuceneSQL模糊查询的问题反向索引库反向索引库的查询 Lucene全文检索技术Lucene能做什么Lucene存在的问题Solr 和 Elasticsearch 与 Lucene 的关系 全文检索 ------ 反向索引库 与 Lucene MySQL一些索引词汇解释
SQL模糊查询的问题 如这条 like 模糊查询的 sql
select * from 表 where description like %疯狂%这种 like 的模糊查询也没办法通过索引查询。
SQL模糊查询like只能逐个、逐个地搜索。比如要查询 description 列是否包含了 “ 疯狂 ” 关键字。当字符串内容较多时本身就需要花费较多的时间来逐个匹配。
如图 用like 模糊查询 “疯狂” 两字需要对每一行的数据都进行两个字符两个字符逐个匹配如下图表示对这一行数据的逐个匹配的过程。
当处理100条记录时模糊查询的时间开销就是单条记录的处理时间 再乘以100
当处理千万条记录时模糊查询的时间开销就是单条记录的处理时间 再乘以千万。 关于使用模糊查询 like 是否会导致索引失效的问题
用like做查询时通配符% 放在字段值后面样子为—xxx%进行前缀查询索引就能使用
前缀查询的样子abc%就可以拿a、b、c先去索引树进行匹配所以索引就可以使用。
如果把通配符%放在字段值最前面来进行后缀查询样子为—%xxx那么索引就会失效。
比如后缀查询的样子是 【%abc】我们根本不知道%是什么值也就没办法在索引树进行比对所以索引就会失效 反向索引库 为了解决 like 模糊查询性能不好的问题Lucene 做出了一个革命性的创新先建立反向索引库再通过反向索引库进行检索。
反向索引库 需要先对目标内容进行分词然后以【分好的关键词】为 key 建立索引库value 保存了该key出现在哪些文档中、出现在文档中哪些位置等信息。 解释如图
原先有这么一张表这个表里面有一些数据然后通过分关键词来建立一个索引库。
如图 “spring” 这个关键词存在旧表中 id1 的那一行数据里面那么在新建立的索引库里面对该关键字给标识上 1; “强大” 这个关键词在旧表 id 1 和 id2 那两行数据里面都存在那么在新建立的索引库里面也标识了该id标识了 1,2 如果我们要全文检索 “强大” 这个词那么就会直接去旧表查id1 和 id2 这两行数据。 而不用对整张表的每一行数据都查一次。
相当于把 like 的查询策略给去掉了。 对反向索引库的查询立即就变成了原来的 查询相当于如下条件 “where 关键词列 要查询的关键词 ” 查询而且这关键词列在反向索引库肯定是有索引的比如btree索引 这意味着在反向索引库中对该关键词列就是上图中的key的检索完全不需要整个表扫描。 反向索引库的查询 对 “关键词”列 执行查询有两个特征
不需要使用LIKE模糊查询性能很好。关键词列本身带有聚簇索引性能很好。
通过“关键字”列中可以很迅速地找到“疯狂”关键字一旦找到“疯狂”关键字之后接下来就可通过它对应的value发现该关键字出现了1、2两个文档中还可以发现该关键字在1、2两个文档中的位置……等更多详细信息。 不管哪一种语言它能支持的“词”是有限的以英语为例大部分母语为英语的大学生词汇量大约在3万左右
类似的中文的汉字、单词也是有限的。
不管目标文档是百万条也好是百亿条也好反向索引库的关键字并不会显著增加
因此对“关键词”列的检索性能总是有保证的。 Lucene全文检索技术
Lucene 利用了反向索引库的特征从而为全文检索提供了性能保证。
Lucene 是目前世界上最流行的全文检索框架。
Lucene 解决了传统SQL查询搞不定的情况或者用SQL语句能够搞定查询但要用到很多LIKE……OR时查询就会很慢。此时就要用到 Lucene 全文检索技术。 Lucene能做什么 Lucene能开发搜索引擎吗
实际上这并非不可能当然单独的Lucene可能做不到一个互联网搜索引擎至少需要解决以下三个核心问题
全文检索。海量信息的自动搜索需要用到网络爬虫从互联网上爬取信息。海量信息的分布式存储、管理例如 Cassandra、MongoDB 等
单独的 Lucene 通常用于实现单个的站内搜索功能只检索本应用内的信息。 Lucene存在的问题
Lucene本身的API比较难用Lucene框架的开发者应该不是Java开发者因此他设计的Lucene API比较晦涩难用。
最大的问题Luence 只是一个 Java 框架因此只有 Java 程序员才能使用 Lucene 为项目添加全文检索功能。此时就需要一个跨平台、跨语言的接口。 Solr 和 Elasticsearch 与 Lucene 的关系
Solr、Elasticsearch 等技术对 Lucene 进行了包装包装之后的 Solr、Elasticsearch 不再是简单的框架更像一个搜索引擎的服务器。
虽然 Solr、Elasticsearch 底层都是基于 Lucene但它们自己提供了对 Lucene 索引库的操作、管理开发者不再需要直接面向 Lucene API 编程而是面向 Solr、Elasticsearch 所提供 RESTful 接口跨平台、跨语言来编程
这意味着开发者不管使用哪种语言甚至不管他会不会编程只要他会用工具发送请求比如 Postman、curl 等那就能调用 Solr、Elasticsearch 的 RESTful 接口来操作索引库包括创建索引库、添加、删除文档、执行全文检索……等一切功能。
优势降低开发者的要求使用起来更方便、没有开发语言的限制。
