当系统数据量上了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）如何解决统计分析问题；(离线、近实时)

以上数据库做数据统计分析都要自己实现

思考如果自己设计可以从哪些方面考虑：

对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈： 解决要点： 1）通过主从备份解决数据安全性问题； 2）通过数据库代理中间件心跳监测，解决单点故障问题； 3）通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果 4）通过分表分库解决读写效率问题

1.数据库并不适合做海量数据的检索，通常项目实践中不会让并发请求最终落在数据库上，数据库中每个sql本身都代表了锁，因此性能并不是太高，尤其面对海量数据，并发量高的情况 2.同时数据库只能做模糊查询的检索，并不能做全文分词检索

对于Nosql数据库，以redis为例，其它原理类似， 解决要点： 1）通过副本备份保证数据安全性； 2）通过节点竞选机制解决单点问题； 3）先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果

Redis做全文检索是不可能的，本身就是key-value数据结构 并且服务器内存是有限制的，不能无限制存储数据

完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：

1PB=1024T=1048576G节点数=1048576/96=10922个

实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

从前面我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。 全部放在内存速度问题是解决了，但成本问题上来了。

为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法：

以上5个特点就是ElasticSearch的特点（ElasticSearch对堆内存的要求比较高，一个节点最高占用30G）

什么叫做全文检索呢？这要从我们生活中的数据说起。

我们生活中的数据总体分为两种：结构化数据和非结构化数据。

• 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。
• 非结构化数据：指不定长或无固定格式的数据，如 互联网数据、邮件，word文档等。

对非结构化数据顺序扫描很慢，对结构化数据的搜索却相对较快，那么把我们的非结构化数据想办法弄得有一定结构不就行了吗？这就是全文检索的基本思路，也就是将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引 。

非结构化数据又一种叫法叫全文数据。

按照数据的分类，搜索也分为两种：

• 对结构化数据的搜索： 如对数据库的搜索，用SQL语句。再如对元数据的搜索，如利用windows搜索对文件名，类型，修改时间进行搜索等。
• 对非结构化数据的搜索： 如用Google和百度可以搜索大量内容数据。

对非结构化数据也即全文数据的搜索主要有两种方法：顺序扫描法和反向索引法。

• 顺序扫描法：所谓顺序扫描法，就是顺序扫描每个文档内容，看看是否有要搜索的关键字，实现查找文档的功能，也就是根据文档找词。
• 反向索引法：所谓反向索引，就是提前将搜索的关键字建成索引，然后再根据索引查找文档，也就是根据词找文档。

这种先建立，再对索引进行文档的过程就叫 。

数据库只能做精确匹配，不能分词搜索，并且效率低。

• 搜索引擎（对算法、数据结构要求较高）
• 站内搜索（直接使用ElasticSearch基本可以满足）
• 系统文件搜索

1. Lucene：如果使用该技术实现，需要对Lucene的API和底层原理非常了解，而且需要编写大量的Java代码。
2. Solr：使用java实现的一个web应用，可以使用rest方式的http请求，进行远程API的调用。
3. ElasticSearch(ES)：可以使用rest方式的http请求，进行远程API的调用。

Solr和ElasticSearch底层都是基于Lucene

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.索引库里面究竟存些什么？(Index)
• 2.如何创建索引？(Indexing)
• 3.如何对索引进行搜索？(Search)

原始内容是指要索引和搜索的内容。

原始内容包括互联网上的网页、数据库中的数据、磁盘上的文件等。

也就是采集数据，从互联网上、数据库、文件系统中等获取需要搜索的原始信息，这个过程就是信息采集。

采集数据的目的是为了将原始内容存储到document对象中。

如何采集数据？

1. 对于互联网上网页，可以使用工具将网页抓取到本地生成html文件。
2. 数据库中的数据，可以直接连接数据库读取表中的数据。
3. 文件系统中的某个文件，可以通过I/O操作读取文件的内容。

在Internet上采集信息的软件通常称为爬虫或蜘蛛，也称为网络机器人，爬虫访问互联网上的每一个网页，将获取到的网页内容存储起来。

创建文档的目的是统一数据格式（document），方便文档分析。

说明： 1.一个document文档中包括多个域(Field)，域(Field)中存储内容。 2.这里我们可以将数据库中一条记录当成一个document，一列当成一个Field

分析文档主要是对Field域进行分析，分析文档的目的是为了索引。

说明：分析文档主要通过分词组件(Tokenizer)和语言处理组件(Linguistic Processor)完成

3.4.1分词组件

分词组件工作流程（此过程称之为Tokenize）

1. 将Field域中的内容进行分词（不同语言有不同的分词规则）
2. 去除标点符号。
3. 去除停用词（stop word）。

经过分词（Tokenize）之后得到的结果成为。

所谓停用词(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)如下：

“student”，“allow”，“go”，“their”，“friend”，“allow”，“drink”，“beer”，“my”，“friend”，“jerry”，“go”，“school”，“see”，“his”，“student”，“find”，“them”，“drink”，“allow”。

• 也正是因为有语言处理的步骤，才能使搜索drove，而drive也能被搜索出来。

索引的目的是为了搜索。

说明：将得到的词(Term)传给索引组件(Indexer)，索引组件(Indexer)主要做以下几件事情：

3.5.1创建Term字典

在我们的例子中字典如下：

3.5.2排序Term字典

对字典按字母顺序进行排序

3.5.3合并Term字典

合并相同的词(Term)成为文档倒排(Posting List)链表

在此表中，有几个定义：

• document Frequency 即文档频次，表示总共有多少文件包含此词(Term)。
• Frequency 即词频率，表示此文件中包含了几个此词(Term)。

到此为止，索引已经创建好了。

最终的索引结构是一种倒排索引结构也叫反向索引结构，包括索引和文档两部分，索引即词汇表，它的规模较小，而文档集合较大。

倒排索引结构是根据内容（词汇）找文档，如下图：

分词及检索的详细的流程：

上图详细演示了一下： 创建索引的过程 （此过程为下的索引库构建过程，中文有一定差异）

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值（加权值）

相关度排序是查询结果按照与查询关键字的相关性进行排序，越相关的越靠前。比如搜索“Lucene”关键字，与该关键字最相关的应该排在前边。

Lucene对查询关键字和索引文档的相关度进行打分，得分高的就排在前边。

如何打分呢？Lucene是在用户进行检索时实时根据搜索的关键字计算出来的，分两步：

1. 计算出词（Term）的权重
2. 根据词的权重值，计算文档相关度得分。

什么是词的权重？ 通过索引部分的学习，明确索引的最小单位是一个Term(索引词典中的一个词)。搜索也是从索引域中查询Term，再根据Term找到文档。Term对文档的重要性称为权重，影响Term权重有两个因素：

• Term Frequency (tf)： 指此Term在此文档中出现了多少次。tf 越大说明越重要。 词(Term)在文档中出现的次数越多，说明此词(Term)对该文档越重要，如“Lucene”这个词，在文档中出现的次数很多，说明该文档主要就是讲Lucene技术的。
• document Frequency (df)： 指有多少文档包含此Term。df 越大说明越不重要。 比如，在一篇英语文档中，this出现的次数更多，就说明越重要吗？不是的，有越多的文档包含此词(Term), 说明此词(Term)太普通，不足以区分这些文档，因而重要性越低。

boost是一个加权值（默认加权值为1.0f），它可以影响权重的计算。在索引时对某个文档中的field设置加权值，设置越高，在搜索时匹配到这个文档就可能排在前边。

Field是文档中的域，包括Field名和Field值两部分，一个文档可以包括多个Field，document只是Field的一个承载体，Field值即为要索引的内容，也是要搜索的内容。

下边列出了开发中常用 的Filed类型，注意Field的属性，根据需求选择：

Field域如何设计，取决于需求，比如搜索条件有哪些？显示结果有哪些？

常见问题： 不存储是指不在lucene的索引域中记录，目的是为了节省lucene的索引文件空间。

如果要在详情页面显示描述，解决方案： 从lucene中取出商品的id，根据商品的id查询关系数据库（MySQL）中item表得到描述信息。