最近看了看《搜索引擎-应用、实践与应用》这本书，基本可以算做搜索引擎的入门书籍，这本书不错，可深可浅。里面虽然都不很深入，但基本囊括了目前的搜索引擎技术，所以在这里做一下学习笔记，以免以后忘掉。
第一章:历史与现状。历史没有什么，主要是分类：全文搜索、目录搜索和元数据搜索。这里要以大类区分开。
第二章:数据挖掘技术。里面对序列模式、分类、聚类等等做了介绍。
第三章:搜索引擎的数据结构。这一章比较重要。
首先讲了四种基本存储方法：顺序存储、链接存储、索引存储和hash散列存储。这里一定要注意，这四种存储方法并不是全部不相干的，不能将其作为四种对等技术来看。比如索引存储里面就包含了顺序存储或链接存储。
其次.讲了索引的基础数据结构--倒排表
第四章：搜索引擎的基本结构。讲了三大基本机构：爬虫、索引部分、检索部分。这里只是概述，以后章节细化。
1.爬虫。没有什么可说的，不关心...
2.排序。这里重点讲了pagerank、向量空间模型和扩展相关信息。
pagerank：基于引用度
向量空间模型：基于两个结论，构建向量模型。1.一个查询词的权重与它出现在这个网页中的次数成正比。2.一个查询词的权重与出现此查询词的网页数量成反比
扩展相关信息：一个词并不能单个来看，比如近义词、相关词等等这些都是影响排名的关键。
3.索引系统。主要讲了倒排表，这里延伸了一下硬盘存储倒排表右部文件。
4.缓存机制。将经常搜索到的词的倒排表项缓存。
第五章：爬虫。基本可说的就是深度优先和广度优先，其他没什么了。
第六章：索引系统。这里有以下几点比较重要。
1.倒排表右部的硬盘存储。文件名+偏移位置（文件顺序存储）。
2.倒排索引的压缩。其中重要的是“游程编码”，使用场景是将文件号压缩，核心思想是基于增量压缩。比如5.8.12.13.15压缩为5.3.4.1.2
3.直接I\0,即调用操作系统函数，减少缓存层级，从这里可以看出c在做操作系统的天然优势。
4.倒排表合并策略。即小索引合并为大索引，这样做可以减少I/O负担，因为小索引会造成多次I/O开关。
5.利用内存临时索引技术实现即时搜索。这个名字很抽象，看了半天才懂，其实可以这样总结：搜索引擎不是分有爬虫、索引、搜索三大部分吗？其实这里说的就是搜索的时候不是查找已经建立好的索引，而是搜索索引系统那部分正在建立的索引。这里有什么好处呢？1.其实这里和存储的结构有关系。因为其实已经建立好的索引时放在硬盘中的，反复读取会造成内存碎块.2.这样可以实现即时检索。
6.对正排文件进行压缩减少磁盘占用。这里正排文件是文档对应的内容结构，存放正排文件的服务器，称之为文档服务器，里面的内容压缩可以减少I/O和网络资源。
7.lucene使用总结。
设置索引主要步骤：1.设置索引文件夹.2.根据地址初始化IndexWriter.3.建立多个Field(包括title、link、摘要等等).4.初始化Document以及为这个Document对象添加刚才的那些Field.5.使用IndexWriter为这个Document建立索引。建立索引的步骤可以设置是否分词、是否索引、是否存储等等。
建立好索引后就可以用这个索引文件搜索，主要使用IndexSearcher搜索，Query对象可以为多种搜索方式如：单个搜索、联合搜索、范围查询、组合查询、多个索引联合查询等等。
lucene有索引优化机制，如小索引合并为大索引：writer.optimize()。
第七章。分布式搜索引擎设计。这一章是我看的重点之一。比较有价值的东西如下：
1.分布式搜索引擎最主要的核心问题：这个是重点，如果没有遇到问题那就没有必要做分布式。1.分布的信息获取和计算，以及对此进行的数据统一,包括分布式的爬虫和爬到信息的分布式处理。2.数据处理后的分存储和管理，包括文件的准确定位、更新、增加、删除、移动机制。3.前端搜索服务的分布，主要处理大规模并发请求时的分发机制。
2.总结了四类分布式搜索引擎：分布式元搜索引擎、hash分布式搜索引擎、p2p分布式搜索引擎、局部遍历型搜索引擎
3.分布式元搜索引擎。master-slave结构，分布观察点以要索引的文件，即倒排表右侧项，将要索引的文件平行分布，减少索引压力。但是这里没有减少检索压力，即master的压力是很大的，需要在每个slave中查询。优化措施为多级别master，这里也有多种多级别master，比如1.可以将搜索要求为：a and b，这里可以分两级master，第一级别master分配任务，第二级别的两个master分别处理a和b，最后汇总。这里的问题是下级master向上级master提交的时候会有大量数据，会造成大量的网络通讯流量。2.google的fancy list(Brin/Page提出)。核心思想是减少读取倒排表右部的信息，比如只读取score最高的几个即可，这样可以暂时减少，但是业务真的做大以后，网络流量还是客观的....master的多级分布无法解决的问题，hash分布式搜索可以解决。（检索系统复杂，索引系统简单）
4.hash分布式搜索引擎。分布观察点以倒排表左侧项为基准，每个机器只搜索特定关键词。需要一个词典来查词，两个问题：1.词典挂了整个系统就挂了；2.单个节点挂了会遇到搜该关键词无结果的现象。改进:1.词典分布处理或备份处理.2.取消词典，直接求余(当机器增加会改变余数，造成索引重建，扩展性差...书上吹的很神，个人觉得问题多多...).（检索系统简单、索引系统复杂）
5.文档服务器的分布。分布分布再分布....这里主要方便缓存的实施。
6.对分布式建立缓存机制。各处可加缓存：1.倒排表缓存.2.文档服务器缓存.还有值得挖掘的缓存的地方。
7.混合分布式搜索引擎。元搜索+hash。先hash分布，再限制大小，多余的部分合并成一个倒排索引项。结合两者的优势。不会出现hash中的搜不到的现象。
8.分布式搜索引擎的扩展性。主要涉及节点动态调整，里面给了一种倒树型结构，老的数据占据少的节点，新的数据占多的节点，并且遇到新数据的时候可以使用二叉树的重建使得老的节点释放资源给新的关键词用。
9.p2p分布搜索引擎。这里主要和p2p技术相关，个人认为这里讲的不好，因为对于p2p的分代都没有讲。我这里补充一下：第一代：集中查询；第二代：广播或多播查询；第三代：DHT技术。具体的就不讲了，毕竟和搜索引擎本身没有必然的联系。主要是把索引系统采用p2p技术分布。
10.局部遍历型搜索。充分利用信息相关性进行检索。 比如聚类后建立信息树，根据树更深查询，可以更加智能，而不像以前那么呆板。由此可见数据挖掘技术应用于搜索引擎可以带来智能化的提升。
第八章.Google的搜索引擎结构。这里是我看的最重点内容。总结如下：
1.技术的出现必然有其要解决的问题，google的问题如下：web增长巨大、web中的资源不同（html、image、applet等等）、检索时间要短、各国语言不一样（分词相关）、系统承受的访问量巨大。
1.GFS。google的分布式文件系统。主要思想是按块读取以及三个备份，GFS的块大小是64m，可以有效解决存取问题。
2.MapReduce，大名鼎鼎的MapReduce,其实思想也很简单，对数据先MAP，分而治之，再Reduce，合并结果，一种分布式处理思想。map函数和reduce函数均可自定义。这里值得说的有两点：
(1) GFS与MapReduce是相伴而生的，Map的任务分割为64MB，这样有利于GFS将备份放于同一个机器（这里不理解...）结果：上千台机器能够以本地的速度进行读取操作。
(2) MPI与MapReduce的区别：MPI是基于消息驱动的并行编程，优先选择的场景为：小数据量而大计算量，如很大的for循环，可以并行处理。而MapReduce的优先选择场景为：大数据量小计算，可以看到MapReduce中的计算都是非常小的，而MapReduce的模型也是为了处理大数据量而来的。
3.BigTable。同样是大名鼎鼎的BigTable，主要解决半结构化的数据太多的问题。基本思想就是一张大表（这里和关系型数据库中的大表不同，比如BigTable可以做到单列全部数据读取，无需读取全表数据，而关系型数据库做单列数据读取是必须读取全表数据。而且用户可以定义自己的读取方式，很灵活）。这里值得说的有以下几点：
(1) 读取方式灵活，比如可以单列读取。；
(2) 单行读取隔离化，可以将一张table分为多个tablets（这里好像跟关系型数据库中的分表类似，不过BigTable与GFS结合更灵活）
(3) 应用层可以控制底层存储，比如以下场景：一个公交表中有最早发车时间和最晚发车时间，那么可以建立一个发车时间的group，包含最早发车时间和最晚发车时间，底层存储表现为最早发车时间和最晚发车时间这两列在同一个块中，读取速度大大提高。
因为table是分布存储的，那么给定一个row，如何查到相应的tablets呢？
(1) master节点，瓶颈是性能
(2) 特殊tablets，具体思想是分级查找（这里不太懂...）
第九章。中文分词算法。过于专业...以后留看
第十章。分类和聚类。智能化搜索引擎的关键，以后留看
第十一章。内容小区和SPAM消除。不懂...记录一下以后留看。