其他

Nutch外掛程式機制非常好，它給我們提供了爬取各個步驟的介面，使我們能夠自己定製想要的功能，關於nutch外掛程式編寫的例子請看我之前的一篇文章，這裡主要介紹下如何通過外掛程式方式對爬取的內容進行過濾。我把需要過濾的內容以關鍵詞的形式儲存在資料庫中，爬取時從資料庫中提取到記憶體中，當建立索引時，如果網頁包含有需要過濾的內容，則丟棄該網頁。要實現索引過濾就必須實現org.apache.nutch.indexer.IndexingFilter這個介面，參考代碼如下：public class

AutoCompleteAction.java@SuppressWarnings("serial")@ParentPackage(value = "actions" )public class AutoCompleteAction extends ActionSupport{public static final Log LOG = LogFactory.getLog(AutoCompleteAction.class); //注入keywordsServiceprivate

1.安裝配置JDK，自己找教程 2.修改cassandra目錄下的conf/log4j-server.properties修改系統記錄檔的存放位置，例：linux下log4j.appender.R.File=/var/cassandra/log/system.logwindows下log4j.appender.R.File=F:/cassandra/log/system.log 3.修改cassandra目錄下的conf/cassandra.yaml 修改資料庫資料檔案的存放位置data_fil

 根據下面這個連結教程編碼後實驗發現標題只是加上了<strong></strong>標籤，並沒有實現<strong>標籤的效果。不知道作者用的是那個版本的nutch，我用1.2版沒效果。http://hi.baidu.com/conquer84/blog/item/50bc43eea1a147fdb2fb959a.html 連結的教程： 在org.apache.nutch.searcher.HitDetails這個類中 添加一個新定義：public

用nutch2.0+cassandra1.0爬取和儲存網頁時發現gbk編碼的網頁解析提取文本時中文全都變成亂碼，非常奇怪，之前nutch1.x從來就不會出現中文亂碼的問題的，因為nutch1.x和nutch2.x用的爬蟲代碼差不多是一樣的，所以我猜可能是儲存到cassandra時有問題。看了下它儲存網頁到cassandra的源碼，所有需要儲存的值它都轉換成二進位封裝成ByteBuffer對象傳到gora中持久化。看下gora-cassandra的源碼中操作cassandra的部分Cassandr

Here are the things that could potentially slow down fetching下面這些是潛在的影響爬取效率的內容： 1) DNS setup 2) The number of crawlers you have, too many, too few. 3) Bandwidth limitations 4) Number of threads per host (politeness) 5) Uneven distribution of urls to

錯誤1.由linux下允許開啟的最大檔案數量引起錯誤訊息：java.io.IOException: background merge hit exception: _0:C500->_0 _1:C500->_0 _2:C500->_..... [optimize] at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:2310) at

分區分布是把索引分區分布到節點的過程。這個操作會在初次啟動叢集，副本分配，負載平衡，或增加刪除節點時進行。下面是一些與分區分布相關的設定：cluster.routing.allocation.allow_rebalance設定根據叢集中機器的狀態來重新分配分區，可以設定為always,

elasticsearch-head是一個elasticsearch的叢集管理工具，它是完全由html5編寫的獨立網頁程式，你可以通過外掛程式把它整合到es。或直接下載源碼，在本地開啟index.html運行它。該工具的git地址是： https://github.com/Aconex/elasticsearch-head外掛程式安裝方法：1.elasticsearch/bin/plugin -install

今天更新了下nutch，發現已經出了1.3版，下載時就發現只有70多M，之前的可是100多M的，肯定是什麼東西刪了，下載完後發現原來nutch內建的搜尋功能都被刪了，現在只能用solr作為索引和搜尋來使用。於是就配了個solr3.2，運行一下試試，結果到建立索引時出現了[was class java.io.CharConversionException] Invalid UTF-8

bigdesk是elasticsearch的一個叢集監控工具，可以通過它來查看es叢集的各種狀態，如：cpu、記憶體使用量情況，索引資料、搜尋情況，http串連數等。項目git地址： https://github.com/lukas-vlcek/bigdesk。和head一樣，它也是個獨立的網頁程式，使用方式和head一樣。外掛程式安裝運行：1.bin/plugin -install lukas-vlcek/bigdesk2.運行es3.開啟http://localhost:9200/_plug

對於lucene全文檢索索引，可以簡約地看看它的7個主要類，這7個類同時也表達了處理全文檢索索引的7個意念。因為資料庫比較為人所熟悉，它又與全文檢索索引某些理念極為相似，所以在對下面的概念說明時，將會大量在滲入資料庫和全文檢索索引間的類比。 1）Document

       實在是等不及了，下了開發版的nutch2.0來玩玩，nutch2.0有什麼不同呢？從官網wiki（見參考資料）可看到，主要是以下幾個方面：1.抽象儲存層       把儲存層抽象出來，不僅像之前那樣可以存放在hdfs上，也可以存在其它nosql中，如：hbase，cassandra，或關聯式資料庫。2.精簡外掛程式      

cas+shiro配置好後，在本地測試環境（jetty伺服器）三大瀏覽器測試都沒問題，但部署到線上時，Google瀏覽器在cas登陸成功跳回shiro的回調地址時重新導向到了favicon.ico這個地址，由於後台並沒有這個地址，所以伺服器出了個404頁面。那shiro為什麼會從定向到這個地址呢？百思不得其解，後來查資料才知道favicon.ico是網站的表徵圖，瀏覽器請求網站時也會請求這個表徵圖。但為什麼剛訪問網站時沒有去請求，到了從cas跳回來時才請求呢？我估計這個與具體瀏覽器的實現有關。我

由於項目需要用到嚮導式的跳轉頁面效果，本項目又是用spring mvc實現的，剛開始想到用spring 的webflow，不過webflow太過笨重，對於我們不是很複雜的跳轉來說好像有種“殺雞焉用牛刀”的感覺，於是就網上搜尋看有沒有類似的解決方案，網上的答案一般都是叫你繼承AbstractWizardFormContoller這個類來實現，但對於spring

一個Elasticsearch節點會有多個線程池，但重要的是下面四個：索引（index）：主要是索引資料和刪除資料操作（預設是cached類型）搜尋（search）：主要是擷取，統計和搜尋操作（預設是cached類型）大量操作（bulk）：主要是對索引的大量操作（預設是cached類型）更新（refresh）：主要是更新操作（預設是cached類型）可以通過給設定一個參數來改變線程池的類型（type），例如，把索引的線程池改成blocking類型：threadpool: index:

在使用基於lucene的各類搜尋引擎（如：elasticsearch、solr）時，有可能出現類似如下的錯誤：Caused by: java.io.EOFException: read past EOF:

elasticsearch的索引邏輯簡單分析，這裡只是理清主要的脈絡，一些細節方面以後的文章或會闡述。假如通過java api來調用es的索引介面，先是構造成一個json串（es裡表示為XContent，是對要處理的內容進行抽象），在IndexRequest裡面指定要索引文檔到那個索引庫（index）、其類型（type）還有文檔的id，如果沒有指定文檔的id，es會通過UUID工具自動產生一個uuid，代碼在IndexRequest的process方法內。 if

Github“Github使用Elasticsearch搜尋20TB的資料，包括13億的檔案和1300億行的代碼”這個不用介紹了吧，碼農們都懂的，Github在2013年1月升級了他們的程式碼搜尋，由solr轉為elasticsearch，目前叢集規模為26個索引儲存節點和8個用戶端節點（負責處理搜尋請求），詳情請看官方部落格https://github.com/blog/1381-a-whole-new-code-searchFoursquare”即時搜尋5千萬地點資訊？Foursquare每

1.由gc引起節點脫離叢集     因為gc時會使jvm停止工作，如果某個節點gc時間過長，master ping3次（zen discovery預設ping失敗重試3次）不通後就會把該節點剔除出叢集，從而導致索引進行重新分配。解決方案：（1）最佳化gc，減少gc時間。（2）調大zen discovery的重試次數（es參數：ping_retries）和逾時時間（es參數：ping_timeout）。後來發現根本原因是有個節點的系統所在硬碟滿了。導致系統效能下降。2.out of