大数据学习第14天

倒排索引概述
编辑

在关系数据库系统里，索引是检索数据最有效率的方式,。但对于搜索引擎，它并不能满足其特殊要求：
1）海量数据：搜索引擎面对的是海量数据，像Google，百度这样大型的商业搜索引擎索引都是亿级甚至百亿级的网页数量 ，面对如此海量数据 ,使得数据库系统很难有效的管理。
2）数据操作简单：搜索引擎使用的数据操作简单 ,一般而言 ,只需要增、 删、 改、 查几个功能 ,而且数据都有特定的格式 ,可以针对这些应用设计出简单高效的应用程序。而一般的数据库系统则支持大而全的功能 ,同时损失了速度和空间。最后 ,搜索引擎面临大量的用户检索需求 ,这要求搜索引擎在检索程序的设计上要分秒必争 ,尽可能的将大运算量的工作在索引建立时完成 ,使检索运算尽量的少。一般的数据库系统很难承受如此大量的用户请求 ,而且在检索响应时间和检索并发度上都不及我们专门设计的索引系统。 [1]
倒排索引构建方法
编辑

倒排索引简单法

索引的构建相当于从正排表到倒排表的建立过程。当我们分析完网页时 ,得到的是以网页为主码的索引表。当索引建立完成后 ,应得到倒排表 ,具体流程如图所示：
流程描述如下：
1）将文档分析成单词term标记，
2）使用hash去重单词term
　　3）对单词生成倒排列表
　　倒排列表就是文档编号DocID，没有包含其他的信息（如词频，单词位置等），这就是简单的索引。
　　这个简单索引功能可以用于小数据，例如索引几千个文档。然而它有两点限制：
　　1）需要有足够的内存来存储倒排表，对于搜索引擎来说， 都是G级别数据，特别是当规模不断扩大时 ,我们根本不可能提供这么多的内存。
　　2）算法是顺序执行，不便于并行处理。

倒排索引合并法
归并法,即每次将内存中数据写入磁盘时，包括词典在内的所有中间结果信息都被写入磁盘，这样内存所有内容都可以被清空，后续建立索引可以使用全部的定额内存。
归并索引
如图 归并示意图：
合并流程：
1）页面分析，生成临时倒排数据索引A，B，当临时倒排数据索引A，B占满内存后，将内存索引A，B写入临时文件生成临时倒排文件，
　　2) 对生成的多个临时倒排文件 ,执行多路归并 ,输出得到最终的倒排文件 ( inverted file)。
合并流程
索引创建过程中的页面分析 ,特别是中文分词为主要时间开销。算法的第二步相对很快。这样创建算法的优化集中在中文分词效率上。 [3]

倒排索引更新策略
编辑
更新策略有四种：完全重建、再合并策略、原地更新策略以及混合策略。
完全重建策略：当新增文档到达一定数量，将新增文档和原先的老文档整合，然后利用静态索引创建方法对所有文档重建索引，新索引建立完成后老索引会被遗弃。此法代价高，但是主流商业搜索引擎一般是采用此方式来维护索引的更新（这句话是书中原话）
再合并策略：当新增文档进入系统，解析文档，之后更新内存中维护的临时索引，文档中出现的每个单词，在其倒排表列表末尾追加倒排表列表项；一旦临时索引将指定内存消耗光，即进行一次索引合并，这里需要倒排文件里的倒排列表存放顺序已经按照索引单词字典顺序由低到高排序，这样直接顺序扫描合并即可。其缺点是：因为要生成新的倒排索引文件，所以对老索引中的很多单词，尽管其在倒排列表并未发生任何变化，也需要将其从老索引中取出来并写入新索引中，这样对磁盘消耗是没必要的。
原地更新策略：试图改进再合并策略，在原地合并倒排表，这需要提前分配一定的空间给未来插入，如果提前分配的空间不够了需要迁移。实际显示，其索引更新的效率比再合并策略要低。
混合策略：出发点是能够结合不同索引更新策略的长处，将不同索引更新策略混合，以形成更高效的方法。

倒排索引应用
编辑
反向索引数据结构是典型的搜索引擎检索算法重要的部分。
一个搜索引擎执行的目标就是优化查询的速度：找到某个单词在文档中出现的地方。以前，正向索引开发出来用来存储每个文档的单词的列表，接着掉头来开发了一种反向索引。 正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。
实际上，时间、内存、处理器等等资源的限制，技术上正向索引是不能实现的。
为了替代正向索引的每个文档的单词列表，能列出每个查询的单词所有所在文档的列表的反向索引数据结构开发了出来。
随着反向索引的创建，如今的查询能通过立即的单词标示迅速获取结果（经过随机存储）。随机存储也通常被认为快于顺序存储。

简述什么是倒排索引

倒排索引

（英语：Inverted index）

，也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。

倒排索引

倒排索引有两种不同的反向索引形式：

一条记录的水平反向索引（或者反向档案索引）包含每个引用单词的文档的列表。

一个单词的水平反向索引（或者完全反向索引）又包含每个单词在一个文档中的位置。

后者的形式提供了更多的兼容性（比如短语搜索），但是需要更多的时间和空间来创建。

现代搜索引擎的索引都是基于倒排索引。相比“签名文件”、“后缀树”等索引结构，

“倒排索引”

是实现单词到文档映射关系的最佳实现方式和最有效的索引结构。

ElasticSearch与Solr优缺点对比

Elasticsearch的优缺点：

优点

Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。

Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。

处理多租户不需要特殊配置，而Solr则需要更多的高级设置。

Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。

各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。

缺点

只有一名开发者（当前Elasticsearch GitHub组织已经不只如此，已经有了相当活跃的维护者）

还不够自动（不适合当前新的Index Warmup API）

Solr的优缺点

优点

Solr有一个更大、更成熟的用户、开发和贡献者社区。

支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。

Solr比较成熟、稳定。

不考虑建索引的同时进行搜索，速度更快。

缺点

建立索引时，搜索效率下降，实时索引搜索效率不高。

Elasticsearch与Solr的比较

当实时建立索引时, Solr会产生io阻塞，查询性能较差 。

实时建立索引 Elasticsearch具有明显的优势

随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。

随数据量的增加 搜索效率会变得更低

综上所述，Solr的架构不适合实时搜索的应用。

实际生产环境测试

Elasticsearch与Solr的比较总结：

二者安装都很简单；

Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;

Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；

Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；

Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。

Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

其他基于Lucene的开源搜索引擎解决方案

直接使用Lucene

说明：Lucene 是一个 JAVA 搜索类库，它本身并不是一个完整的解决方案，需要额外的开发工作。

优点：成熟的解决方案，有很多的成功案例。apache 顶级项目，正在持续快速的进步。庞大而活跃的开发社区，大量的开发人员。它只是一个类库，有足够的定制和优化空间：经过简单定制，就可以满足绝大部分常见的需求；经过优化，可以支持 10亿+ 量级的搜索。

缺点：需要额外的开发工作。所有的扩展，分布式，可靠性等都需要自己实现；非实时，从建索引到可以搜索中间有一个时间延迟，而当前的“近实时”(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善

详述ElasticSearch分布式架构

ES里面的将数据分为工作数据和持久化数据两种：

工作数据就是正常的提供查询和索引的数据，这部分数据假定是瞬时的，并且是不可靠的，随时可能丢失的数据，而持久化数据则是可靠的，一致的数据，工作数据可以都放在内存中，这样可以保证非常好的性能，而持久化数据则专心保证数据的一致性就ok了，我们自动的分布式系统有CAP原则，通过对数据分离方式，我们很好的解决了C和A的问题，你可能会问，你内存中的数据如果不对了怎么办？不就会影响数据的一致性吗？一方面数据可以从持久化数据进行加载，另外ES节点间的数据会定时刷新和同步，最终确保数据的一致，就算万一机器都歇了，没关系，从持久化目录里面重新加载数据即可。

单前面说的那个还不算什么，如果不能很好的解决动态扩容的问题，那就不算是ElasticSearch了，在ElasticSearch里面，索引目录有如下两个概念：shard（碎片）、replica（副本）碎片(shard)的意思很好理解，db可以有sharding，索引也可以做嘛，单个索引目录太大，GB级别的索引文件，你再继续往里塞数据，文件合并，优化，有过这种经验的人应该会明白这种痛苦，怎么办？拆呗（china？拆那？），一般的做法是按数据拆，自己按租户，按时间拆等等，很是麻烦，并且拆完了之后的事情也不少，跨目录查询怎么办？更新怎么办？接口要怎么变？这些在ElasticSearch里面都帮你想到了，对你而言，全是透明的，你操作的就是一个索引，你在创建索引的时候，根据索引的规模指定碎片的大小，其他的你就不用管了，至于它里面怎么实现数据的平均分配，其实很简单，就用了一个取模的算法，随机分配到各个碎片中，至于一致性哈希之类的，目前来说完全没有必要。

碎片可以解决单个索引太大的问题，但是凡任何事有利必有弊，索引碎片在实现上其实就分成了很多个索引目录，索引目录越多，对建索引的速度会有提示，尤其是多线程环境，因为我们建索引的时候单个索引目录肯定加锁，一旦涉及锁，势必要减慢速度，不过我多几个目录，不就可以并发执行了吗？是的，ES就是这么做的，但是前面说了，有利就有弊，索引搞得到处都是，ES查询起来就很费劲了，一般情况下，我们在没有使用Routing的情况下（后面再介绍routing），ES会同时多个线程去读取各个碎片的索引数据，然后再合并查询结果，另外在ES的分布式环境下，碎片如果分布在多台服务器上就要加上网络的开销，势必会影响查询速度了，在海量数据的前提下，这些其实都还好，并且ES支持多种查询方式(reflink:search type)：
Query And Fetch：
Query Then Fetch：
Dfs, Query And Fetch：
Dfs, Query Then Fetch：
Count：
Scan：
根据不同的查询需求，选择合适的查询类型，会收到意想不到的效果。
–
先整体看看单ES节点的模块结构吧：

再看看一次索引操作

再看看一次查询请求

列举五种通过curl操作ElasticSearch的命令

1、开启gzip请求
curl -I http://www.sina.com.cn/ -H Accept-Encoding:gzip,defalte

2、监控网页的响应时间
curl -o /dev/null -s -w “time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n” “http://www.kklinux.com”

3. 监控站点可用性
curl -o /dev/null -s -w %{http_code} “http://www.kklinux.com”

4、以http1.0协议请求（默认为http1.1）
curl -0 …
​ 1）读取网页
　　$ curl linuxidc.com">http://www.linuxidc.com
　　2）保存网页
　　$ curl http://www.linuxidc.com > page.html $ curl -o page.html http://www.linuxidc.com
　　3）使用的proxy服务器及其端口：-x
　　$ curl -x 123.45.67.89：1080 -o page.html http://www.linuxidc.com
　　4）使用cookie来记录session信息
　　$ curl -x 123.45.67.89：1080 -o page.html -D cookie0001.txt http://www.linuxidc.com
option： -D 是把http的response里面的cookie信息存到一个特别的文件中去，这样，当页面被存到page.html的同时，cookie信息也被存到了cookie0001.txt里面了
​ 5）那么，下一次访问的时候，如何继续使用上次留下的cookie信息呢？
　　使用option来把上次的cookie信息追加到http request里面去：-b
　　$ curl -x 123.45.67.89：1080 -o page1.html -D cookie0002.txt -b cookie0001.txt http://www.linuxidc.com

6）浏览器信息~~~~
随意指定自己这次访问所宣称的自己的浏览器信息： -A
curl -A “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)” -x 123.45.67.89:1080 -o page.html -D cookie0001.txt http://www.yahoo.com
这样，服务器端接到访问的要求，会认为你是一个运行在Windows 2000上的IE6.0，嘿嘿嘿，其实也许你用的是苹果机呢！
而"Mozilla/4.73 [en] (X11; U; Linux 2.2; 15 i686"则可以告诉对方你是一台PC上跑着的Linux，用的是Netscape 4.73，呵呵呵

7）
另外一个服务器端常用的限制方法，就是检查http访问的referer。比如你先访问首页，再访问里面所指定的下载页，这第二次访问的referer地址就是第一次访问成功后的页面地
址。这样，服务器端只要发现对下载页面某次访问的referer地址不 是首页的地址，就可以断定那是个盗连了~~~~~
讨厌讨厌~我就是要盗连~~~！！
幸好curl给我们提供了设定referer的option： -e
curl -A “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)” -x 123.45.67.89:1080 -e “mail.yahoo.com” -o page.html -D cookie0001.txt http://www.yahoo.com
这样，就可以骗对方的服务器，你是从mail.yahoo.com点击某个链接过来的了，呵呵呵

8）curl 下载文件
刚才讲过了，下载页面到一个文件里，可以使用 -o ，下载文件也是一样。
比如， curl -o 1.jpg http://cgi2.tky.3web.ne.jp/~zzh/screen1.JPG
这里教大家一个新的option： -O
大写的O，这么用： curl -O http://cgi2.tky.3web.ne.jp/~zzh/screen1.JPG
这样，就可以按照服务器上的文件名，自动存在本地了！
再来一个更好用的。
如果screen1.JPG以外还有screen2.JPG、screen3.JPG、…、screen10.JPG需要下载，难不成还要让我们写一个script来完成这些操作？
不干！
在curl里面，这么写就可以了：
curl -O http://cgi2.tky.3web.ne.jp/~zzh/screen[1-10].JPG
9）
再来，我们继续讲解下载！
curl -O http://cgi2.tky.3web.ne.jp/~{zzh,nick}/[001-201].JPG
这样产生的下载，就是

详述elasticsearch搜索项目的工作流程

查询类型(参数search_type指定)：

（一） query_then_fetch 分为两个阶段： 1） 协调节点将请求发送到与搜索语句相关的索引分片（即搜索语句中索引的所有分片）上，各分片分别进行查询（因为每个分片都是一个独立的lucene索引）得到结果，并进行排序，得出（from+size）大小的结果集，然后将轻量级的信息（足够协调节点重新排序）发送给协调节点。协调节点接收到所有分片（超时不侯）的结果，并进行全局排序，这样得到[from,from+size)的结果集。 2） 协调节点从与最终结果相关的分片中获取文档的内容（包括高亮显示的分片等），并返回给客户端。

（二） dfs_query_then_fetch 过程跟query_then_fetch是一样的，不同之处在于第一阶段在计算score的时候使用的term frequency是local的，即只用自己分片的term frequency，会产生的问题是，可能相同的内容在不同的分片得到的得分不一样，也可能出现明明更相关的文档的得分反而比不那么相关的文档的score小。而dfs_query_then_fetch使用全局的termfrequency，这样可以得到更准确的scoring。