我對算法的一點感觸

benjiam

以后再遇到瓶頸，采用B+樹算法構(gòu)建索引文件

并不合適， 多個客戶端 一起用 也是非常麻煩的。

醉臥水云間

樓主你就直說了吧，最后用什么方法快，別賣關(guān)子了，你說的那些處理都很平常，多數(shù)人都知道不靈的。

rtp

原帖由 MMMIX 于 2007-8-31 19:35 發(fā)表

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

幼稚。

swordfish.cn

這叫“摸著石頭過河”么。

xtthnfr

任何事情都要考慮效果和效率,程序設(shè)計尤其如此.

一般來講分為4種情況

1.效果好,效率高.

2.效果好,效率低.

3.效果差,效率高.

4.效果差,效率低.

程序設(shè)計出來能正常運行,這是效果;程序設(shè)計出來效果好,運行速度快,這是效率,也就是算法.

作為絕大多數(shù)公司,都對程序的要求是第一種,先要求效果....效率放到第二位.

解決了生存問題的公司和我們程序設(shè)計人員,才能資格和機會去追求第一種效果.

福瑞哈哥

樓主的url排重有什么好方法嗎？

bloom-filter？還是干脆用map-reduce？你所列的前幾種方法都無法適應(yīng)大規(guī)模的應(yīng)用。

xtthnfr

我都說了是自己寫HASH了....

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

xtthnfr

原帖由 福瑞哈哥 于 2007-9-3 10:42 發(fā)表
樓主的url排重有什么好方法嗎？

bloom-filter？還是干脆用map-reduce？你所列的前幾種方法都無法適應(yīng)大規(guī)模的應(yīng)用。

搜索了一把.....我感覺bloom-filter基本上也還是hash....map-reduce看了半天....沒搞太明白....但我總的感覺就是特殊處理.

我在接著細(xì)化討論一點URL排重吧.

URL有很多特點....

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

2.網(wǎng)頁數(shù)目特別多的超級的大網(wǎng)站也不多.....可以對各個網(wǎng)站進(jìn)行分級.

3......

URL排重具備很多特點,和純粹的算法上的隨機分布完全是兩回事.

所以,URL的排重的HASH就要根據(jù)你對URL的特點歸納整理出來之后來設(shè)計.

比如說:先按照域名做第一次HASH....然后各個具體網(wǎng)站上面的在做2級HASH...象sina和sohu那樣的大網(wǎng)站,還可以按照頻道去做3級hash.....

//這只是我個人的想法....

nully

我的算法：

1.重排URL變量
2.md5一次，16個字節(jié)128位
3.將16字節(jié)運算得到34位數(shù)據(jù)
4.34位數(shù)據(jù)剛好使用2G文件(* 8 bit)來記錄是否出現(xiàn)過

可能有重疊情況發(fā)生，但16G的位空間應(yīng)該夠用了。

lemosa

算法就像登山中尋找的路。
找對了，能省很多力氣！