我对算法的一点感触

benjiam

以后再遇到瓶颈，采用B+树算法构建索引文件

并不合适， 多个客户端 一起用 也是非常麻烦的。

醉卧水云间

楼主你就直说了吧，最后用什么方法快，别卖关子了，你说的那些处理都很平常，多数人都知道不灵的。

rtp

原帖由 MMMIX 于 2007-8-31 19:35 发表

不要动不动就把算法抬那么高 :em11:

幼稚。

swordfish.cn

这叫“摸着石头过河”么。

xtthnfr

任何事情都要考虑效果和效率,程序设计尤其如此.

一般来讲分为4种情况

1.效果好,效率高.

2.效果好,效率低.

3.效果差,效率高.

4.效果差,效率低.

程序设计出来能正常运行,这是效果;程序设计出来效果好,运行速度快,这是效率,也就是算法.

作为绝大多数公司,都对程序的要求是第一种,先要求效果....效率放到第二位.

解决了生存问题的公司和我们程序设计人员,才能资格和机会去追求第一种效果.

福瑞哈哥

楼主的url排重有什么好方法吗？

bloom-filter？还是干脆用map-reduce？你所列的前几种方法都无法适应大规模的应用。

xtthnfr

我都说了是自己写HASH了....

搜索引擎里面很多地方都用到HASH.

xtthnfr

原帖由 福瑞哈哥 于 2007-9-3 10:42 发表
楼主的url排重有什么好方法吗？

bloom-filter？还是干脆用map-reduce？你所列的前几种方法都无法适应大规模的应用。

搜索了一把.....我感觉bloom-filter基本上也还是hash....map-reduce看了半天....没搞太明白....但我总的感觉就是特殊处理.

我在接着细化讨论一点URL排重吧.

URL有很多特点....

1.URL太长的不多....太短的也不多.....你大概能分析出来URL的平均长度.

2.网页数目特别多的超级的大网站也不多.....可以对各个网站进行分级.

3......

URL排重具备很多特点,和纯粹的算法上的随机分布完全是两回事.

所以,URL的排重的HASH就要根据你对URL的特点归纳整理出来之后来设计.

比如说:先按照域名做第一次HASH....然后各个具体网站上面的在做2级HASH...象sina和sohu那样的大网站,还可以按照频道去做3级hash.....

//这只是我个人的想法....

nully

我的算法：

1.重排URL变量
2.md5一次，16个字节128位
3.将16字节运算得到34位数据
4.34位数据刚好使用2G文件(* 8 bit)来记录是否出现过

可能有重叠情况发生，但16G的位空间应该够用了。

lemosa

算法就像登山中寻找的路。
找对了，能省很多力气！