Gus Mueller 给你7个半建议，让你在1068天内成为一个独立程序员：
按照我个人写共享软件的经验，我好像基本上是这样做的哦，最后一点太好玩了，不过在中国有难度。
有几位同事也在研究简单的搜索，我们的搜索只要是针对垂直内容就可以了，但是同样我们的资源不是很充分，因此也必须在技术上花一些脑筋。下面这篇文章或许会有一些帮助。
以前曾经提到过搜索引擎的缓存策略, 根据搜索引擎搜索的关键词的统计分布, 可以优化设计搜索引擎的缓存策略. 就普通的缓存策略上讲, 缓存是因为在一定的时间段内的搜索的关键词集中在一定的范围内, 并且这些搜索相对稳定. 例如每天搜索”美女”的人总有10万,20万, 而结果在这段时间相对稳定, 因此没有必要每次去检索索引文件, 而将上一个人搜索的结果直接返回便可以了.
搜索引擎缓存策略也同搜索引擎的算法密切相连, 除了搜索缓存, 索引缓存也是一个好方法. 独立或者分布一些权重较高的文档也是一种提高效率的方法. 例如我们有1000万的网页的权重(可以简单的理解为pagerank)比较高, 那么这些网页的排序相比另外一些权重较低的网页相对较为稳定, 就不妨独立出来进行相对独立的索引缓存.
关于缓存的分布, 一般的小型搜索引擎不会用到, 但是如果每天处理上亿次的搜索, 缓存的分布就应当有一定的分布规划, 例如根据提交的关键词构成hash table, 然后对应于不同的搜索服务器, 实现缓存的分布.
让我们看看实际例子吧, 我们拿百度, google, yisou, 中搜, tag.bokee.com 进行简单的测试:
因为测试, 要搜索一些在过去7天没有人搜索过的关键词, 或者组合词. 为了保证没有人搜索过, 我选择在各个搜索引擎里搜索”a s d f v g h” , 这是我在键盘上随机打出的一些组合, 相信这世界上在7天没有人相同搜索, 这样保证我的第一次的搜索是 fresh search, 就是一定需要搜索引擎去检索索引文件, 而不是通过缓存策略.
以下是结果:
百度: 0.279秒
google: 0.24 秒
一搜: 0.24 秒
中搜: 0.001秒(无结果!!!!)
博客搜索: 0.041 秒
下面是第二次搜索的结果:
百度: 0.001秒
google: 0.05 秒
一搜: 0.09 秒
中搜: 0.002秒(无结果!!!!)
博客搜索: 0.019 秒
经过简单的测试, 可以看出缓存机制只有在Baidu和google搜索引擎里都有, 但是各自效率不一样, 如下是简单的比例:
百度: 100
google: 5
一搜: 没有明显的缓存
中搜: 没有明显的缓存
博客搜索: 没有明显的缓存
而在缓存效率上百度要远远大于google, 这点大概是因为google的gfs本身的分布效率已经相当不错, 因此进行缓存也不会有数量级的提升.
而百度, 根据测试可能是集中方式的数据存储, 但是根据搜索进行hash分布, 因此才会在缓存上有显著的提升. (这个属于猜测)
1. google认为, 所有的硬件都是容易产生故障的, 因此google认为故障是必然的, 不产生故障才是偶然现象. 这个想法和我们通常的意识是相反的.
2. Google认为, 一旦写入, 再也不删除和修改. 这点上google认为修改和删除会对系统造成潜在的伤害, 例如文件的不连续性, 文件定位的困难..
3. Google将Linux的 file system的block更改为 64M , 也就是说, 写文件的最小单元是64M, 而不是我们通常的512字节, 两者整整相差了128000倍.
4. Google认为修复是没有必要的, 当一个服务器出现问题的时候, 撤下来, 换上另外一个 google unit(google 单元)即可, 因为维修的成本远远大于直接上线一个全新的服务单元的成本. 说来容易, 其实只有当google结构真正实现高冗余和分布式这样的操作才可行, 而这些正是google的核心.
当我们设计一个系统的时候, 我们最简单的做法通常是会根据需求对已有的一些经验进行匹配, 这个过程中我们通常走的是近路,而且我们的经验常常会束缚我们的想法, 没有抛开经验进行全新的分析和设计, 也自然就难以有所创新.
图书馆管理员们提出最多的问题之一是：“对于什么样的结果应该位于搜索列表的最上方，Google是如何选择的？”现在品质工程师马特-卡兹介绍了快速入门的知识，解释了Google是如何在网上爬行和索引，以及如何评定搜索结果等级的。马特也向学校图书馆管理员提出建议，告诉他们如何辅导学生。
爬行和索引
在你浏览包含了Google搜索结果的网页之前，要发生很多事情。首先是在万维网数以十亿计的网页上爬行和索引，这个工作是由Googlebot完成的，它负责与全球的网络服务器连接以收集文件。爬行不是真的在网上漫游，而是访问网络服务器返回到一个特定的网页上，接着扫描该网页建立超链接并为每一个网页编上号码。爬行可收集大量的文件，但这些文件还不能直接用于搜索。
如果没有索引，在你想查询如“civil war”（南北战争）等内容时，Google的服务器将不得不在你每次搜索时阅读每一份文件的内容。因此第二个步骤是要建立一个索引，这样就需要“转换”爬行所获得的数据。为了不必在每一份文件上扫描每一个单词，就需要在数据上做些文章，以便显示包含了特定单词的所有文件。例如，假设单词“civil”在编号为3、8、22、56、68和92的文件上出现过，而单词“war”出现编号为2、8、15、22、68和77的文件上。
一旦建立了索引，就开始对文件进行等级评定并确定它们的相关性。假如某个人上Google搜索并输入“civil war”，为呈现和评价搜索结果需要做两件事：一是查找包含了用户提问的网页；二是按照相关性排定匹配网页的位置。Google已经开发出一个有趣的技术可加速第一步骤的过程：不是将所有索引存储在一台电脑上，而是使用数百台电脑做这种工作。由于任务被分配到很多电脑上，使得查询答案更为迅速。
为更加形象地描述这个过程，可以设想下一本30页厚书的索引。如果一个人在索引中查找数页的信息，那么每一次搜索都至少需要花几秒钟的时间；但如果你将索引的每一页分给不同的人去查找呢？三十个人分别查找索引的不同部分，要比一个人独自查找快的多。同样，Google也是将数据分配到各台电脑上以便可以更快地查找文件。
如何查找包含了用户提问的网页？让我们返回到上面举的“civil war”例子。单词“civil”在编号为3、8、22、56、68和92的文件上，单词“war”在编号为2、8、15、22、68和77的文件上，我们可以在网页上显示文件并寻找包含两个单词的文件（从下表中可以看出是8、22和68号文件）。
单词civil 3 8 22 56 68 92
单词war 2 8 15 22 68 77
两个单词都出现 8 22 68
包含了一个单词的文件列表被称为“文件标识列表”，查找包含两个单词的文件被称为“文件标识列表的交集”。
评定搜索结果
有了包含用户提问的网页后，就该按照相关性评定网页了。Google使用了很多技术，其中PageRank算法是最有名的。PageRank评定的是两种事情：从网站到某一网页有多少个链接，提供链接的网站的排名。使用PageRank，来自CNN和纽约时报网站的链接的价值，是很多不太有名网站的两倍。
除了PageRank外Google还使用了很多其他技术，例如一份文件所包含的“civil”和“war”两个单词靠的很近，就比只使用了“war”单词的包含“Revolutionary War”（独立战争）的文件相关性要大的多。另外在题目中出现了“civil war”的网页，它的相关性就比题目为“19th Century American Clothing”（19世纪的美国服装）要重要的多。同样如果“civil war”在网页上出现了数次，比出现一次的网页要相关的多。
Google的目的是要找到知名度和相关性都大的网页。如果两个网页出现匹配提问的信息数量几乎一样，我们常常会选择更有名网站的链接。但如果其他方面表明一个网页更为相关，也会选择更少链接或更低排名的网页。例如，一个网页全篇都是讲“南北战争”的内容，会比只是略微提到“南北战争”的网页更为有用，即使这个网页是出现不太有名的网站上。一旦我们有了文件的列表和分值，就会选择最高分值、最匹配的文件。
Google从包含了提问单词的每一份文件中提取几句话作为摘要显示，接着将排好的URLs和摘要显示在搜索结果上。正如你所知道的运行一个搜索器需要大量的计算资源。每一次搜索需要500台以上的电脑一起工作，搜索的时间还不到半秒钟
