一、开篇几个问题
1.大规模数据如何检索?
当系统数据量上了10亿、100亿条的时候,我们在做系统架构的时候通常会从以下角度去考虑:
1)用什么数据库好?(MySQL、sybase、Oracle、达梦、神通、MongoDB、Hbase…)
MySQL:通过分库分表可以存海量数据,但是做数据检索效率是达不到毫秒级别,并且数据检索只能支持模糊查询,不支持全文检索、分词检索
以上数据库都可以做海量数据存储,但都不适合做检索的工作。
2)如何解决单点故障;(lvs、F5、A10、Zookeeper、MQ)
集群,要考虑故障转移的问题,就需要借助lvs、F5、A10、Zookeeper来维护配置
MQ,可以做大量数据的缓存队列,例如滴滴,后台存储了大量的数据,数据实时不停的产生,每天产生400T的数据,这么大量的数据必须要有一个缓存队列进行缓存,然后再写入到库里
3)如何保证数据安全性;(热备、冷备、异地多活)
保证数据不会丢失,做备份
4)如何解决检索难题;(数据库代理中间件:mysql-proxy、Cobar、MaxScale等;)
分库分表后的检索问题
5)如何解决统计分析问题;(离线、近实时)
以上数据库做数据统计分析都要自己实现
思考如果自己设计可以从哪些方面考虑:
2.传统数据库的应对解决方案?
对于关系型数据,我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈:
解决要点:
1)通过主从备份解决数据安全性问题;
2)通过数据库代理中间件心跳监测,解决单点故障问题;
3)通过代理中间件将查询语句分发到各个slave节点进行查询,并汇总结果
4)通过分表分库解决读写效率问题
1.数据库并不适合做海量数据的检索,通常项目实践中不会让并发请求最终落在数据库上,数据库中每个sql本身都代表了锁,因此性能并不是太高,尤其面对海量数据,并发量高的情况
2.同时数据库只能做模糊查询的检索,并不能做全文分词检索
3.非关系型数据库的解决方案?
对于Nosql数据库,以redis为例,其它原理类似, 解决要点:
1)通过副本备份保证数据安全性;
2)通过节点竞选机制解决单点问题;
3)先从配置库检索分片信息,然后将请求分发到各个节点,最后由路由节点合并汇总结果
Redis做全文检索是不可能的,本身就是key-value数据结构
并且服务器内存是有限制的,不能无限制存储数据
4.完全把数据放入内存怎么样?
完全把数据放在内存中是不可靠的,实际上也不太现实,当我们的数据达到PB级别时,按照每个节点96G内存计算,在内存完全装满的数据情况下,我们需要的机器是:
1PB=1024T=1048576G
节点数=1048576/96=10922个
实际上,考虑到数据备份,节点数往往在2.5万台左右。成本巨大决定了其不现实!
从前面我们了解到,把数据放在内存也好,不放在内存也好,都不能完完全全解决问题。
全部放在内存速度问题是解决了,但成本问题上来了。
为解决以上问题,从源头着手分析,通常会从以下方式来寻找方法:
1、磁盘存储顺序存储;
2、将数据和索引分离;
3、压缩数据;
4、热点数据放内存
5、多线程
以上5个特点就是ElasticSearch的特点(ElasticSearch对堆内存的要求比较高,一个节点最高占用30G)
二、全文检索技术
1.什么是全文检索?
什么叫做全文检索呢?这要从我们生活中的数据说起。
我们生活中的数据总体分为两种:结构化数据和非结构化数据。
- 结构化数据:指具有固定格式或有限长度的数据,如数据库,元数据等。
- 非结构化数据:指不定长或无固定格式的数据,如 互联网数据、邮件,word文档等。
对非结构化数据顺序扫描很慢,对结构化数据的搜索却相对较快,那么把我们的非结构化数据想办法弄得有一定结构不就行了吗?这就是全文检索的基本思路,也就是将非结构化数据中的一部分信息提取出来,重新组织,使其变得有一定结构,然后对此有一定结构的数据进行搜索,从而达到搜索相对较快的目的。这部分从非结构化数据中提取出的然后重新组织的信息,我们称之索引 。
非结构化数据又一种叫法叫全文数据。
按照数据的分类,搜索也分为两种:
- 对结构化数据的搜索: 如对数据库的搜索,用SQL语句。再如对元数据的搜索,如利用windows搜索对文件名,类型,修改时间进行搜索等。
- 对非结构化数据的搜索: 如用Google和百度可以搜索大量内容数据。
对非结构化数据也即全文数据的搜索主要有两种方法:顺序扫描法和反向索引法。
- 顺序扫描法:所谓顺序扫描法,就是顺序扫描每个文档内容,看看是否有要搜索的关键字,实现查找文档的功能,也就是根据文档找词。
- 反向索引法:所谓反向索引,就是提前将搜索的关键字建成索引,然后再根据索引查找文档,也就是根据词找文档。
这种先建立索引
,再对索引进行搜索
文档的过程就叫全文检索(Full-text Search)
。
数据库只能做精确匹配,不能分词搜索,并且效率低。
2.全文检索场景
- 搜索引擎(对算法、数据结构要求较高)
- 站内搜索(直接使用ElasticSearch基本可以满足)
- 系统文件搜索
3.全文检索相关技术
- Lucene:如果使用该技术实现,需要对Lucene的API和底层原理非常了解,而且需要编写大量的Java代码。
- Solr:使用java实现的一个web应用,可以使用rest方式的http请求,进行远程API的调用。
- ElasticSearch(ES):可以使用rest方式的http请求,进行远程API的调用。
Solr和ElasticSearch底层都是基于Lucene
4.Solr和ES的比较
ElasticSearch vs Solr 检索速度
-
当单纯的对已有数据(静态数据,不会发生变化的数据)进行搜索时,Solr更快。
-
当实时建立索引时, Solr会产生io阻塞,查询性能较差, Elasticsearch具有明显的优势。
-
随着数据量的增加,Solr的搜索效率会变得更低,而Elasticsearch却没有明显的变化。
-
大型互联网公司,实际生产环境测试,将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。
总结:
- 二者安装都很简单;
- Solr 利用 Zookeeper 进行分布式管理,而 Elasticsearch 自身带有分布式协调管理功能;
- Solr 支持更多格式的数据,而 Elasticsearch 仅支持json文件格式;
- Solr 官方提供的功能更多,而 Elasticsearch 本身更注重于核心功能,高级功能都由第三方插件提供;
- Solr 在传统的搜索应用中表现好于 Elasticsearch,但在处理实时搜索应用时效率明显低于Elasticsearch。
最终的结论:
Solr 是传统搜索应用的有力解决方案,但 Elasticsearch 更适用于新兴的实时搜索应用。
三、全文检索的流程分析
1.什么是索引
有人可能会说,对非结构化数据顺序扫描很慢,对结构化数据的搜索却相对较快(由于结构化数据有一定的结构可以采取一定的搜索算法加快速度),那么把我们的非结构化数据想办法弄得有一定结构不就行了吗?
这种想法很天然,却构成了全文检索的基本思路,也即将非结构化数据中的一部分信息提取出来,重新组织,使其变得有一定结构,然后对此有一定结构的数据进行搜索,从而达到搜索相对较快的目的。
这部分从非结构化数据中提取出的然后重新组织的信息,我们称之索引
这种说法比较抽象,举几个例子就很容易明白,比如字典,字典的拼音表和部首检字表就相当于字典的索引,对每一个字的解释都是非结构化的,如果字典没有拼音表和部首检字表,在茫茫辞海中找一个字只能顺序扫描。然而字的某些信息可以提取出来进行结构化处理,比如读音,就比较结构化,分声母和韵母,分别只有几种可以 一一列举,于是将读音拿出来按一定的顺序排列,每一项读音都指向此字的详细解释的页数。我们搜索时按结构化的拼音搜到读音,然后按其指向的页数,便可找到 我们的非结构化数据——也即对字的解释
2.流程总览
索引库创建过程
索引库搜索过程
全文检索的流程分为两大流程:索引创建、搜索索引
- 索引创建:将现实世界中所有的结构化和非结构化数据提取信息,创建索引的过程。
- 搜索索引:就是得到用户的查询请求,搜索创建的索引,然后返回结果的过程。
要想搞清楚全文检索,必须要搞清楚下面三个问题:
- 1.索引库里面究竟存些什么?(Index)
- 2.如何创建索引?(Indexing)
- 3.如何对索引进行搜索?(Search)
3.创建索引流程
3.1原始内容
原始内容是指要索引和搜索的内容。
原始内容包括互联网上的网页、数据库中的数据、磁盘上的文件等。
3.2获得文档
也就是采集数据,从互联网上、数据库、文件系统中等获取需要搜索的原始信息,这个过程就是信息采集。
采集数据的目的是为了将原始内容存储到Document对象中。
如何采集数据?
- 对于互联网上网页,可以使用工具将网页抓取到本地生成html文件。
- 数据库中的数据,可以直接连接数据库读取表中的数据。
- 文件系统中的某个文件,可以通过I/O操作读取文件的内容。
在Internet上采集信息的软件通常称为爬虫或蜘蛛,也称为网络机器人,爬虫访问互联网上的每一个网页,将获取到的网页内容存储起来。
3.3创建文档对象
创建文档的目的是统一数据格式(Document),方便文档分析。
说明:
1.一个Document文档中包括多个域(Field),域(Field)中存储内容。
2.这里我们可以将数据库中一条记录当成一个Document,一列当成一个Field
3.4分析文档(重点)
分析文档主要是对Field域进行分析,分析文档的目的是为了索引。
说明:分析文档主要通过分词组件(Tokenizer)和语言处理组件(Linguistic Processor)完成
3.4.1分词组件
分词组件工作流程(此过程称之为Tokenize)
- 将Field域中的内容进行分词(不同语言有不同的分词规则)
- 去除标点符号。
- 去除停用词(stop word)。
经过分词(Tokenize)之后得到的结果成为词元(Token)
。
所谓停用词(Stop word)就是一种语言中最普通的一些单词,由于没有特别的意义,因而大多数情况下不能成为搜索的关键词,因而创建索引时,这种词会被去掉而减少索引的大小。
英语中停词(Stop word)如:“the”,“a”,“this”等。
对于每一种语言的分词组件(Tokenizer),都有一个停词(stop word)集合。
示例(Document1的Field域和Document2的Field域是同名的):
- Document1的Field域:
Students should be allowed to go out with their friends, but not allowed to drink beer.
- Document2的Field域:
My friend Jerry went to school to see his students but found them drunk which is not allowed.
- 在我们的例子中,便得到以下词元(Token):
“Students”,“allowed”,“go”,“their”,“friends”,“allowed”,“drink”,“beer”,“My”,“friend”,“Jerry”,“went”,“school”,“see”,“his”,“students”,“found”,“them”,“drunk”,“allowed”。
将得到的词元(Token)传给语言处理组件(Linguistic Processor)
3.4.2语言处理组件
语言处理组件(linguistic processor)主要是对得到的词元(Token)做一些同语言相关的处理。
对于英语,语言处理组件(Linguistic Processor)一般做以下几点:
- 1.变为小写(Lowercase)。
- 2.将单词缩减为词根形式,如“cars”到“car”等。这种操作称为:stemming。
- 3.将单词转变为词根形式,如“drove”到“drive”等。这种操作称为:lemmatization。
语言处理组件(linguistic processor)的结果称为词(Term)。Term是索引库的最小单位。
-
在我们的例子中,经过语言处理,得到的词(Term)如下:
“student”,“allow”,“go”,“their”,“friend”,“allow”,“drink”,“beer”,“my”,“friend”,“jerry”,“go”,“school”,“see”,“his”,“student”,“find”,“them”,“drink”,“allow”。
也正是因为有语言处理的步骤,才能使搜索drove,而drive也能被搜索出来。
3.5索引创建
索引的目的是为了搜索。
说明:将得到的词(Term)传给索引组件(Indexer),索引组件(Indexer)主要做以下几件事情:
3.5.1创建Term字典
在我们的例子中字典如下:
3.5.2排序Term字典
对字典按字母顺序进行排序
3.5.3合并Term字典
合并相同的词(Term)成为文档倒排(Posting List)链表
在此表中,有几个定义:
- Document Frequency 即文档频次,表示总共有多少文件包含此词(Term)。
- Frequency 即词频率,表示此文件中包含了几个此词(Term)。
到此为止,索引已经创建好了。
最终的索引结构是一种倒排索引结构也叫反向索引结构,包括索引和文档两部分,索引即词汇表,它的规模较小,而文档集合较大。
倒排索引结构是根据内容(词汇)找文档,如下图:
3.6创建索引流程总结
分词及检索的详细的流程:
上图详细演示了一下: 创建索引的过程 (此过程为英文环境
下的索引库构建过程,中文有一定差异)
4.搜索索引流程
4.1查询语句
4.2执行搜索
4.2.1第一步:对查询语句进行词法分析、语法分析及语言处理。
1、词法分析
如上述例子中,经过词法分析,得到单词有lucene,learned,hadoop, 关键字有AND, NOT。
注意:关键字必须大写,否则就作为普通单词处理。
2、语法分析
如果发现查询语句不满足语法规则,则会报错。如lucene NOT AND learned,则会出错。
如上述例子,lucene AND learned NOT hadoop形成的语法树如下:
3、语言处理
如learned变成learn等。
经过第二步,我们得到一棵经过语言处理的语法树。
4.2.2第二步:搜索索引,得到符号语法树的文档。
1、 首先,在反向索引表中,分别找出包含lucene,learn,hadoop的文档链表。
2、 其次,对包含lucene,learn的链表进行合并操作,得到既包含lucene又包含learn的文档链表。
3、 然后,将此链表与hadoop的文档链表进行差操作,去除包含hadoop的文档,从而得到既包含lucene又包含learn而且不包含hadoop的文档链表。
4、 此文档链表就是我们要找的文档。
4.2.3第三步:根据得到的文档和查询语句的相关性,对结果进行排序。
相关度自然打分(权重越高分越高):
- tf越高、权重越高(tf代表该词在文档中出现的频率)
- df越高、权重越低(df代表包含该词的文档的数量)
人为影响分数:
- 设置Boost值(加权值)
5.Lucene相关度排序
5.1什么是相关度排序
相关度排序是查询结果按照与查询关键字的相关性进行排序,越相关的越靠前。比如搜索“Lucene”关键字,与该关键字最相关的文章应该排在前边。
5.2相关度打分
Lucene对查询关键字和索引文档的相关度进行打分,得分高的就排在前边。
如何打分呢?Lucene是在用户进行检索时实时根据搜索的关键字计算出来的,分两步:
- 计算出词(Term)的权重
- 根据词的权重值,计算文档相关度得分。
什么是词的权重?
通过索引部分的学习,明确索引的最小单位是一个Term(索引词典中的一个词)。搜索也是从索引域中查询Term,再根据Term找到文档。Term对文档的重要性称为权重,影响Term权重有两个因素:
- Term Frequency (tf):
指此Term在此文档中出现了多少次。tf 越大说明越重要。
词(Term)在文档中出现的次数越多,说明此词(Term)对该文档越重要,如“Lucene”这个词,在文档中出现的次数很多,说明该文档主要就是讲Lucene技术的。 - Document Frequency (df):
指有多少文档包含此Term。df 越大说明越不重要。
比如,在一篇英语文档中,this出现的次数更多,就说明越重要吗?不是的,有越多的文档包含此词(Term), 说明此词(Term)太普通,不足以区分这些文档,因而重要性越低。
5.3.设置boost值影响相关度排序
boost是一个加权值(默认加权值为1.0f),它可以影响权重的计算。在索引时对某个文档中的field设置加权值,设置越高,在搜索时匹配到这个文档就可能排在前边。
6.Lucene的Field域
6.1Field属性
Field是文档中的域,包括Field名和Field值两部分,一个文档可以包括多个Field,Document只是Field的一个承载体,Field值即为要索引的内容,也是要搜索的内容。
属性 | 可选值 |
---|---|
是否分词(tokenized) | * 是:作分词处理,即将Field值进行分词,分词的目的是为了索引。 比如:商品名称、商品描述等,这些内容用户要输入关键字搜索,由于搜索的内容格式大、内容多需要分词后将语汇单元建立索引 * 否:不作分词处理 比如:商品id、订单号、身份证号等 |
是否索引(indexed) | * 是:进行索引。将Field分词后的词或整个Field值进行索引,存储到索引域,索引的目的是为了搜索。 比如:商品名称、商品描述分析后进行索引,订单号、身份证号不用分词但也要索引,这些将来都要作为查询条件。 * 否:不索引。 比如:图片路径、文件路径等,不用作为查询条件的不用索引 |
是否存储(stored) | * 是:将Field值存储在文档域中,存储在文档域中的Field才可以从Document中获取。 比如:商品名称、订单号,凡是将来要从Document中获取的Field都要存储。 * 否:不存储Field值 比如:商品描述,内容较大不用存储。如果要向用户展示商品描述可以从系统的关系数据库中获取。 |
6.2Field常用类型
下边列出了开发中常用 的Filed类型,注意Field的属性,根据需求选择:
Field类 | 数据类型 | Analyzed 是否分词 | Indexed 是否索引 | Stored 是否存储 | 说明 |
---|---|---|---|---|---|
StringField(FieldName, FieldValue,Store.YES)) | 字符串 | N | Y | Y或N | 这个Field用来构建一个字符串Field,但是不会进行分词,会将整个串存储在索引中,比如(订单号,身份证号等) 是否存储在文档中用Store.YES或Store.NO决定 |
LongField(FieldName, FieldValue,Store.YES) | Long型 | Y | Y | Y或N | 这个Field用来构建一个Long数字型Field,进行分词和索引,比如(价格) 是否存储在文档中用Store.YES或Store.NO决定 |
StoredField(FieldName, FieldValue) | 重载方法,支持多种类型 | N | N | Y | 这个Field用来构建不同类型Field 不分析,不索引,但要Field存储在文档中 |
TextField(FieldName, FieldValue, Store.NO) 或 TextField(FieldName, reader) | 字符串 或 流 | Y | Y | Y或N | 如果是一个Reader, lucene猜测内容比较多,会采用Unstored的策略. |
6.3Field设计
Field域如何设计,取决于需求,比如搜索条件有哪些?显示结果有哪些?
字段 | 设计 |
---|---|
商品id | 是否分词:不用分词,因为不会根据商品id来搜索商品 是否索引:不索引,因为不需要根据商品ID进行搜索 是否存储:要存储,因为查询结果页面需要使用id这个值。 |
商品名称 | 是否分词:要分词,因为要根据商品名称的关键词搜索。 是否索引:要索引。 是否存储:要存储。 |
商品价格 | 是否分词:要分词,lucene对数字型的值只要有搜索需求的都要分词和索引,因为lucene对数字型的内容要特殊分词处理,需要分词和索引。 是否索引:要索引 是否存储:要存储 |
商品图片地址 | 是否分词:不分词 是否索引:不索引 是否存储:要存储 |
商品描述 | 是否分词:要分词 是否索引:要索引 是否存储:因为商品描述内容量大,不在查询结果页面直接显示,不存储。 |
常见问题:
不存储是指不在lucene的索引域中记录,目的是为了节省lucene的索引文件空间。
如果要在详情页面显示描述,解决方案:
从lucene中取出商品的id,根据商品的id查询关系数据库(MySQL)中item表得到描述信息。