我最開始在選用資料庫時，為了不使用第三方庫，打算使用erlang自帶的mnesia。但是因為涉及到字串匹配搜尋，mnesia的查詢語句在我看來太不友好，在經過一些資料查閱後就直接放棄了。關於這個網路的工作原理，參看：
p2p中dht網路爬蟲以及寫了個
磁力搜尋的網頁。
然後我打算使用couchdb，因為它是erlang寫的，而我正在用erlang寫程式。第一次接觸非關係型資料庫，發現nosql資料庫使用起來比sql類的簡單多了。但是在erlang裡要使用couchdb實在太折騰了。我使用的客戶端庫是couchbeam。
因為couchdb暴露的api都是基於http協議的，其資料格式使用了json，所以couchbeam實際上就是對各種http請求、回應和json的包裝。但是它竟然使用了ibrowse這個第三方http客戶端庫，而不是erlang自帶的。ibrowse又使用了jiffy這個解析json的庫。這個庫更慘烈的是它的解析工作都是交給c語言寫的動態庫來完成，我還得編譯那個c庫。
couchdb看起來不支援字串查詢，我得自己建立乙個view，這個view裡我通過翻閱了一些資料寫了乙個將每個doc的name拆分成若干次查詢結果的map。這個map在處理每一次查詢時，我都得動態更新之。couchdb是不支援區域性更新的，這還不算大問題。然後很高興，終於支援字串查詢了。這裡的字串查詢都是基於字串的子串查詢。但是問題在於，太慢了。每一次在web端的查詢，都直接導致erlang程序的call超時。
要讓couchdb支援字串查詢，要快速，當然是有解決方案的。但是這個時候我已經沒有心思繼續折騰，任何乙個庫、程式如果介面設計得如此不方便，那就可以考慮換乙個其他的。
我選擇了mongodb。同樣的基於文件的資料庫。2.4版本還支援全文搜尋。什麼是全文搜尋呢，這是一種基於單詞的全文搜尋方式。hello world我可以搜尋hello，基於單詞。mongodb會自動拆詞。更關鍵更讓人爽的是，要開啟這個功能非常簡單：設定啟動引數、建立索引。沒了。mongodb的erlang客戶端庫mongodb-erlang也只依賴乙個bson-erlang庫。然後我又埋頭苦幹，幾個小時候我的這個爬蟲程式就可以在瀏覽器端搜尋關鍵字了。
後來我發現，mongodb的全文搜尋是不支援中文的。因為它還不知道中文該怎麼拆詞。恰好我有個同事做過中文拆詞的研究，看起來涉及到很複雜的演算法。直到這個時候，我他媽才醒悟，我為什麼需要基於單詞的搜尋。我們大部分的搜尋其實都是基於子字串的搜尋。
於是，我將種子檔案的名字拆分成了若干個子字串，將這些子字串以陣列的形式作為種子文件的乙個鍵值儲存，而我依然還可以使用全文索引，因為全文索引會將整個字串作為單詞比較。實際上，基於一般的查詢方式也是可以的。當然，索引還是得建立。
現在公開乙個DHT網路爬蟲
p2p系統的應用越來越廣泛，在檔案共享 流 服務 即時通訊交流 計算和儲存能力共享以及協同處理與服務等方面都能看到p2p的存在，一些p2p應用如napster emule bittorrent等早已是家喻戶曉了。效果可以看下具體51搜尋展示結合xunsearch全文檢索技術，可以達到毫秒級的資料搜尋...
現在公開乙個DHT網路爬蟲
p2p系統的應用越來越廣泛，在檔案共享 流 服務 即時通訊交流 計算和儲存能力共享以及協同處理與服務等方面都能看到p2p的存在，一些p2p應用如napster emule bittorrent等早已是家喻戶曉了。效果可以看下具體51搜尋展示結合xunsearch全文檢索技術，可以達到毫秒級的資料搜尋...
現在公開乙個DHT網路爬蟲
dhtcrawler最早的版本有很多問題，修復過的最大的乙個問題是關於erlang定時器的，在dht實現中，需要對每個節點每個peer做超時處理，在erlang中的做法直接是針對每個節點註冊了乙個定時器。這不是問題，問題在於定時器資源就像沒有gc的記憶體資源一樣，是會由於程式設計師的 問題而出現資源...