对于搜索引擎, 在索引量和搜索量大到一定程度的时候, 索引更新的效率会逐渐降低, 服务器的压力逐渐升高, 因此基本上整个搜索引擎的利用率可以说是越来越低了, 并且随着海量数据存储带来的困难, 设计一个良好的分布式搜索引擎将是一个搜索引擎能否面相未来发展的关键因素了. 那么分布式搜索引擎的最主要的核心问题是哪些呢? 1. 分布的信息获取和计算以及对此进行的数据统一 这里面包括爬虫/或者相应的数据获取机制的分布, 对信息进行加工的统一管理 2. 数据处理后的分布存储和管理 主要是文件的准确定位和更新,增加,删除,移动的机制 3. 前端搜索服务的分布 主要处理大规模并发请求时的分发机制 基于以上3个基本需求, 基本上可以构造如下4类的分布式搜索引擎: 1. 分布式元搜索引擎 2. 散列分布搜索引擎 3. P2P 分布搜索引擎 4. 局部遍历型搜索引擎 下面逐步介绍以上4类可扩展的搜索引擎: 1. 分布式元搜索: 拥有多个单个的搜索引擎, 中心搜索引擎是利用这些分布的单个的搜索引擎的结果进行撮合得到完整的结果. 这样的设计方案要求各个单元的搜索引擎拥有相同的排序算法和基本相同的数据输出结构，以便由中心搜索进行整理。 对于这类的搜索引擎，关键的设计是要求每一个单元所拥有的索引不构成重复，但是进行数据的采集（爬虫）时可以采取独立的系统获取后再按照规则分布到各个单元上。 优点，设计简单，快速，并且任何一个单元可以随时的摘掉但并不影响太大。 缺点，对于大规模的并发并非好的解决办法 ２．散列分布搜索引擎 根据Query对索引服务器和文档服务器进行散列，做到对于任何的索引词能够准确的定位到具体的索引服务器并从而定位到正确的文档服务器。 优点，抗压，设计简单 缺点，对于单个索引服务器或者文档服务器的容量等动态的调整较困难 ３．Peer 2 peer 搜索引擎 著名的Napster就是这样的一种设计，利用集中方式的索引，配合分布于世界各地的单个的计算机形成的文件源，构成了世界上最庞大的p2p搜索引擎之一。 这种设计里的中心索引服务器只记录一些相对关键的信息，例如位置（IP，序列号），歌曲的名字，作者等，其它的信息一概可以从任何在线并且拥有本条全面信息的计算机上获取。同时p2p也可以根据搜索建立一些中间路由的缓存，即将一些搜索结果存在单个或者相近的节点上，加快搜索速度。 优点，可以超级大，基本上不需要有维护成本 缺点，中心服务器的更新效率很低，信息源不稳定 4. 局部遍历型搜索引擎 这类的搜索引擎又可以采用多种设计方案，其中比较可行的是对信息进行聚类后建立信息树，搜索时只需要从树的一个分支下去遍历便可以了。局部遍历应当有一定的规则，并且在设计初期就需要对每一个加入的索引进行相对准确的位置安排，使得放置在合适的节点上，以保证搜索的效率。 优点，容易解决抗压，搜索精度高，搜索效率高 缺点，设计复杂，调整索引所在节点的位置不易 总体来说，搜索引擎的设计方法可以很多，这里只是抛砖引玉，相信未来会有更多的巧妙的设计方案出现。...
Google 要通吃么?
Google 不断的往前赶路, 这不, 收购的Google 分析 analytics (Urchin)上线了. 简单的说这就是一个 referral 的记录分析工具, 一个专业的玩具. 顺便说一句, booso 的referral 依然工作, 最近也在进行代码更换和升级. 越来越觉得 google 变成了一个庞大的信息挖掘机器, 庞大而有绪. 看来, google 真的想通吃了....
博客搜索和博客联播发布
博客搜索一共收录了200多万的博客，一共索引600多万条记录。 博客联播是您随时发现新文章的一个来源，平均每天收录8万条记录，并且滚动播出（过滤程序将一些字数少于200，色情等的先过滤掉了），是中文博客的即时风向标。 Booso.com 最早是我在博客动力的时候业余时间利用refer 服务的数据制作的搜索引擎，今年年初因为事物繁忙，就逐渐荒废了开发，直到这次回国后才又有精力带领团队进行完善。Booso 从诞生到现在，一直是一个试验田，一共进行过如下的尝试：1] Referral 的服务 2] refer 和 关键词搜索的服务 3] 自动分类引擎的测试 4] 贴吧 5] 新闻搜索服务 6] 新闻聚类服务 7] 博客搜索服务 8] 博客联播服务。虽然前前后后历经一年之久，很多服务也是中途夭折，但是基本上正是这些尝试，我和我们的团队得到了很多锻炼和经验，这些财富才是最值得收藏的。 对于这两个服务，我和我的团队还在完善中，如果有好的建议或者砖头请不要吝啬。...
垂直与水平
最近"垂直"这个词非常火,似乎每一个人都在谈论垂直, 当然无法跟google,baidu进行竞争的时候每个人都会想到缩小战场, 收缩到一个相对小的范围. 那么水平呢? 其实很多的搜索并非是完全的垂直, 水平也是有用的. 集成方式的搜索搜索 超女或者搜索 天空是两个很好的例子, 站内外的blog和图片都可以方便的被搜索到. 如下图:...
Google的启示
最近在对现有的搜索引擎进行分布式的改进, 回顾以前阅读过的 google file system 的文章时发现google的思维和我们平时固守的思维很不一样, 可以说很多在我们看来是有一些"偏激"的,可是正是由于这些偏激, 才导致google与其跟随者的不同. 以下为几个例子: 1. google认为, 所有的硬件都是容易产生故障的, 因此google认为故障是必然的, 不产生故障才是偶然现象. 这个想法和我们通常的意识是相反的. 2. Google认为, 一旦写入, 再也不删除和修改. 这点上google认为修改和删除会对系统造成潜在的伤害, 例如文件的不连续性, 文件定位的困难.. 3. Google将Linux的 file system的block更改为 64M , 也就是说, 写文件的最小单元是64M, 而不是我们通常的512字节, 两者整整相差了128000倍. 4. Google认为修复是没有必要的, 当一个服务器出现问题的时候, 撤下来, 换上另外一个 google unit(google 单元)即可, 因为维修的成本远远大于直接上线一个全新的服务单元的成本. 说来容易, 其实只有当google结构真正实现高冗余和分布式这样的操作才可行, 而这些正是google的核心. 当我们设计一个系统的时候, 我们最简单的做法通常是会根据需求对已有的一些经验进行匹配, 这个过程中我们通常走的是近路,而且我们的经验常常会束缚我们的想法, 没有抛开经验进行全新的分析和设计, 也自然就难以有所创新....
博客手拉手
博客中国的[博客手拉手] 系统从推出到现在已经有两个月整了, 期间经过多次调整, 精确度和相关度都有明显的提升. 对于用户的任何一篇文章, 系统自动从以往的旧文章里匹配到最相关的5篇文章, 作为博客手拉手. 例子如下: 原文[Google Talk一出，MSN、QQ必死无疑] 匹配文章: [2005-07-15] QQ被MSN打败的10大理由 [2005-08-01] 腾讯QQ穿上西装挤入商务通讯 看TM激斗MSN [2005-07-19] 我看QQ、MSN、UC [2005-08-01] MSN、QQ走出虚拟空间走向实际应用 [2005-07-07] MSN Messenger ?c MSN Spaces 中?? 原文:我的5个怪癖 匹配文章: [2005-09-02] 我的５个怪癖 [2005-08-25] 我的5个怪癖，嘿嘿 [2005-08-23] 我的5个怪癖 [2005-08-25] 五个怪癖 [2005-08-29] 五个怪癖 下一步是什么呢? 也许一个月,也许两个月, 当新的博客平台出现的时候, 会有一些更有意思的玩艺....
搜索引擎的缓存机制
以前曾经提到过搜索引擎的缓存策略, 根据搜索引擎搜索的关键词的统计分布, 可以优化设计搜索引擎的缓存策略. 就普通的缓存策略上讲, 缓存是因为在一定的时间段内的搜索的关键词集中在一定的范围内, 并且这些搜索相对稳定. 例如每天搜索"美女"的人总有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分布, 因此才会在缓存上有显著的提升. (这个属于猜测)...
Tag Engine 测试发布(标签搜索引擎)
博客中国个人博客系统全面支持 tag, 支持 tag 并不是一件困难的事情, 困难的事情是要将这些 tag 如何处理. tag engine 即 标签搜索引擎是将这些 tag/标签 进行归类整理的搜索引擎, 是一个能够进行智能分类的搜索引擎, 希望借助这个搜索引擎将现有的众多的文章进行整理和分类. 这里我引用以前我写的一段文字: 什么是Tag 兼谈软分类- - 硬分类：就是已往我们发文章的时候通过选择系统现有的固定的分类。 软分类：根据文本或者信息的意义由信息的组织者为信息指定一个或者多个“标签”。 Tag(中文叫做“标签”) 是一种新的组织和管理在线信息的方式。它不同于传统的、针对文件本身的关键字检索，而是一种模糊化、智能化的分类。例如我可以为本文打上如下的标签： Tag、标签、分类、博客 标签的增加有信息的组织者自主添加,带有很强的个性化因素. 因此在个性中寻找共性将是一个Tag engine 区别于其它搜索引擎的一个特征....
Google Sitemaps 的意义
格式化网络是一个不可避免的趋势, Google 利用现有的品牌来进行推广他的sitemap (网站更新地图), 是一个google从主动角色到网站为主动角色的变换. 搜索引擎的主动性将由此转嫁到网站主并且"要求,希望"网站主来积极的配合, Don't be Evil 的口号的风险越来越高. 另外的思考: sitemap 和blog的 rss 又有什么本质的区别呢?...
Google网页加速器的工作原理
最近一直忙着写论文，周末终于有空放松半天时间，到网络上看看，铺天盖地的关于google最新的消息，原来google又出了新玩艺，Google Web Accelerator。 听说很神，特地找了一台Windows电脑准备一试。可是我去google网站下载时却发现google 说用户太多，不提供了。 感谢Owen硬盘里还有保留，终于得到了珍贵的“绝版”Google网页加速器。 我尝试访问了6个网站，并且分析了日志，基本上明确了Google网页加速器的工作原理，其实很简单：Proxy + 缓存。 1. 本地化的Proxy + 缓存 当运行了 google 的网页加速器，本机会启动一个httpd的服务，端口是9100 : http://127.0.0.1:9100 这个服务实际上是一个本地化的Proxy+缓存，就是所有的 http 的请求都是通过这里走的。那么为什么能够加速呢？ 缓存。当你第一次访问一个网页的时候，相当多的图片，静态文字全部的存储下来，然后当你再次访问的时候，就直接从缓存里调出来，因此大大加快了访问速度。 我这里做了一个有趣的试验： 访问我自己的blog一个日志(http://blog.wespoke.com/archives/000907.html)的日志记录： adsl-69-154-77-102.dsl.rcsntx.swbell.net - - [09/May/2005:12:34:38 +0800] "GET /archives/000907.html HTTP/1.1" 304 - 刷新这个网页，Apache的记录仍然是 304。表明没有传输内容，紧紧验证了 expired的信息。 touch archives/000907.html (改变这个文档的时间标记) 再次刷新，这次不一样了： adsl-69-154-77-102.dsl.rcsntx.swbell.net - - [09/May/2005:12:35:28 +0800] "GET /archives/000907.html HTTP/1.1" 200 10319 这次是返回了200，并传输了10319个字节。 这个就是工作的原理，在第一种的情况下，节省了10319个字节的传输。 当然，这也是所有的缓存proxy的设计原则。 2. Google 的缓存＋路由 当我发现我访问的日志上记录的IP和我本地的IP不一样的时候，看来Google 自己也还是有缓存服务器的，就是说当我们请求一个网页时，如果联接非常的慢，google会让这个请求通过google的缓存服务器，同时改变路由。这就是为什么看到的IP不是自己机器的IP了。 由此看来，Google的网络加速器实际上是一个个人的小型Proxy缓存服务器＋Google帝国的一个格点状的Proxy缓存服务器系统构成并有效的来管理这些缓存，并非什么特别的技术，而是将大家忽视了多年的一些基本的概念从新应用了起来。 3. 看看这里就更加明白一些：http://race.google/http://www.wespoke.com，注意，必须启动了加速器后才能连接，因为google Web Accelerator讲这个域名解释为本机并采用Iframe显示。您可以将http://www.wespoke.com替换成您想要到达的网页，看看有没有加速？ 关于加速的原理，你应该了解expired模块。 http://httpd.apache.org/docs/mod/mod_expires.html...
Google Pagerank 在玩弄谁？
其实 Google Pagerank 光辉的历史任务差不多已经完成，因此记得去年有人询问Google 说他们的网站的 PageRank 低的问题的时候，Google的答复是 Pagerank 是娱乐性质的，千万别当真。 其实说是娱乐，可是不当娱乐的人却大有人在，这不，昨天google pagerank更新了，就有人发email问我“你的单片日志如何做到 PageRank 6 的？”并附上了一个联接。 我记得我以前这个blog的PageRank是4，主站都才4，难道单篇日志能到6。打开一看(Firefox 的PageRank plugin)，果然是6，不单这一篇，翻了几篇，竟然全部是6。 Google PageRank 真的有用么？说句老实话，我觉得真得就是一骗人的玩艺，还真得好多网站信誓旦旦打出这样的标语“本站只和PageRank >= 5 的网站做联接”，听起来就跟跟PageRank 低的网站做联接掉了身份似的。其实还不是被google 的Pagerank 给骗了？ 可是话说回来，其实大家都很重视身份，有一个PageRank 5 ，6的网站特别是个人blog就跟被Google 授予了荣誉证书似的，有种特别的感觉。 PageRank 即便历史使命已经完成，可是造成的灾害却是后患无穷，例如现在的Link Spam，Comment Spam，refer Spam有哪一个不是Google PageRank 的影响造成的呢？想在互联网上挑战人们在道德和利益之间的选择，你会发现人们最终选择的是利益而不是道德。 垃圾留言泛滥的年代，是google PageRank 带来的唯一好处就是让这个互联网在道和魔的斗争中更上了一层。 附 一些网页的PageRank及其变动。 http://www.wespoke.com/ has PageRank 5/10. http://blog.wespoke.com/ has PageRank 5/10. http://blog.wespoke.com/archives/000925.html has PageRank 6/10. http://www.wespoke.com/archives/000922.html has PageRank 6/10. http://www.wespoke.com/archives/000931.html has PageRank 6/10. http://www.wespoke.com/archives/000932.html has PageRank 6/10. http://www.wespoke.com/archives/000934.html has PageRank 6/10. http://www.wespoke.com/archives/000935.html has PageRank 6/10. 以上是我的blog的PageRank，两个blog的首页都是PageRank=5，但是发现了我的blog一堆PageRank是6的单片日志。 最可笑的是这一篇： http://www.wespoke.com/archives/000935.html 因为是6，而且有一个联接，交互联接到下面这个网址： http://1001ml.blogdriver.com/1001ml/589835.html has PageRank 6/10. 这个日志的pagerank也是6了。 http://blogmark.blogchina.com/ has PageRank 5/10. http://www.365key.com/ has PageRank 6/10. http://niu.la has PageRank 4/10 前次提到社会书签的pagerank很低，刚发不久，365key就被google解封，这次一下子到了6. 比博采和niu.la都高了。 当然，也有不幸的： http://booso.com has PageRank 0/10. 被定义成了 spam 变成了0....
Google 为什么不支持Rss
看到不少人发表关于Google为什么不支持Rss的问题和看法，这个问题以前不止一个人问起过我，我坚持的看法是Google在有新的赢利基础替代搜索之前是不会支持Rss的，而且我也没有看出来Google需要支持Rss的必要。「虽然我会去Hack google的服务，使得自己有Rss可用」 因为Rss太简单了，简单到将搜索引擎的门坎到了一种令Google感觉到一种压力的地步。 利用rss，可以简单的绕过搜索引擎里面最复杂的一个环节：HTML parse的过程，而这个过程，是众多小型搜索引擎的门坎和瓶颈，因为Rss提供规整化的结构化的数据，使得搜索引擎数据整理的过程简单了许多。可以想象，如果Google支持Rss，那么等于将这个市场的门坎降低，会导致大量的小型的竞争对手来分享未被蚕食的long tail，Google还不至于傻到这个地步。 为什么MSN和Yahoo会支持Rss呢？ MSN和Yahoo的赢利空间里不像Google那么纯粹的倚赖搜索，例如MSN和Yahoo都是门户，服务是其核心，而不搜索。要击败Google这个巨人，可以有很多种做法，其中之一就是培养市场，让搜索市场的门坎降低，培养很多Google的潜在对手，最终使得这个行业的利润薄利化，达到消减Google的目的。 难道MSN和Yahoo不会被消减么？ 当然会了，可是如果这样一个大的竞争对手(Google)不断壮大，有朝一日google进入服务（其实现在已经进入了网络服务行业）将反过来蚕食Yahoo和MSN的市场，那么还不如及早的阻击这个敌人。...
