其他

HashSet是實現Set介面的一個類，具有以下的特點：Ø         不能保證元素的排列順序，順序有可能發生變化。Ø         另外HashSet不是同步的，如果多個線程同時訪問一個Set，只要有一個線程修改Set中的值，就必須進行同步處理，通常通過同步封裝這個Set的對象來完成同步，如果不存在這樣的對象，可以使用Collections.synchronizedSet()方法完成。Set s = Collections.synchronizedSet(new HashSet(...)

一.遍曆HashMapMap<Integer, String> map = new HashMap<Integer, String>();  for(int i=0;i<100;i++)  {   map.put(i, "123");  }方法一：效率比方法二高for(Entry<Integer, String> entry:map.entrySet())  {   System.out.println(entry.getKey()+"="+entry.

原版nutch中對中文的處理是按字劃分，而不是按詞劃分。為適應我們的使用習慣必須加上中文分詞，我加的是 IKAnalyzer。下面是我的方法，我把前台和後台爬蟲用兩種方法實現中文分詞，後台直接替換nutch的analyzer，前台則修改NutchAnalysis.jj（註：我的前台和後台是兩個項目）。前台修改：在src/java/org/apache/nutch/analysis包下找到NutchAnalysis.jj（1） 在

直觀的講，網路就是一些點和串連這些點的線段。這些線段可以有方向，可以沒有方向（雙向）。方便起見，只看那些紐帶是無方向的網路。 大致上，可以把各種不同的網路按照放在“極端有序”（左邊）到“極端無序”（右邊）這個譜繫上。它們都對應一個唯一的數學表達（N*N的矩陣，N是節點的數目，矩陣裡的元素不是0，就是1）。來源：Bordalier

1. 搭建Lucene的開發環境：在classpath中添加lucene-core-2.9.1.jar包   2. 全文檢索搜尋的兩個工作: 建立索引檔案,搜尋索引.   3. Lucene的索引檔案邏輯結構  1) 索引(Index)由若干塊(片段)(Segment)組成  ★2) 塊由若干文檔(Document)組成: 一個檔案對應成一個文檔。資料庫表中的一條記錄映射成一個文檔。  ★3)

        最近幾個月忙著達芬奇的項目，一個人邊學邊做趕進度，從底層驅動，再到上層應用，再到DSP最佳化，天昏地暗，好在自己對這些東西高度興趣，並不覺得苦。直到項目快要完結，覺得必須得回過頭去再把以前的東西系統地看一下了。於是乎就把4年前的ARM7板子翻出來了，拋開作業系統，好好研究一下底層的東西，讓自己心裡也踏實一些。下面這篇日誌的內容剛好和我的開發板的一模一樣，索性留下來，作為參考。        上一篇日誌都是9月份找工作的時候的了，差不多4個月沒寫過了，堅持是一種品質，不能懈怠啊~~

在索引演算法確定的情況下，最為影響Lucene索引速度有三個參數－－IndexWriter中的 MergeFactor, MaxMergeDocs, RAMBufferSizeMB

1.nutch把索引映射到solr，一定注意solrj的jar包版本一定要保持一致，不然會報版本不一致問題。我在用nutch1.3時，將索引映射到solr1.4.1時，就報版本不一致的錯了，將solr換成3.1就好了用nutch1.2時，可以將索引映射到solr1.4.1，但不能映射到solr3.1

 K 均值聚類演算法的最大的優點是：原理簡單，實現起來也相對簡單，同時執行效率和對於大資料量的延展性還是較強的。然而缺點也是很明確的，首先它需要使用者在執行聚類之前就有明確的聚類個數K的設定，這一點是使用者在處理大部分問題時都不太可能事Crowdsourced Security Testing道的，一般需要通過多次實驗找出一個最優的 K

近幾天，一直糾結中文亂碼問題，solr查詢出來的結果沒有亂碼，但如果加高亮顯示，中文就會有亂碼，到現在還搞不清楚原因 結合上次寫的檔案上傳下載刪除樣本，現在的想法，是當使用者傳一個檔案成功後，即將這個檔案同時也加到solr索引中，然後提供一個簡單的查詢頁面，這個頁面可以根據使用者輸入的關鍵字，來檢索到是哪個文檔，並提供該檔案的下載便可，不用像百度那樣，高亮顯示關鍵字，並展示文檔關鍵字部分文字，老師說暫時不用做那麼複雜，呵呵，正好，高亮顯示中文亂碼 為了solr支援中文查詢,將tomcat中的se

最近在研究nutch，找到了關於使用底層命令進行全網爬行的資料。 首先獲得網址集，使用http://rdf.dmoz.org/rdf/ 目錄下的content.example.txt 檔案做測試，建立檔案夾dmoz 命令：bin/nutch org.apache.nutch.tools.DmozParser content.example.txt >dmoz/urls 注射網址到crawldb資料庫： 命令：bin/nutch inject crawl/crawldb

今天看到一篇文章，關於頁面轉化成xml的方式，突然想到nutch的模板匹配問題，因為第一個頁面，寫匹配方式，及寫一些與此同時過濾真的很沒有效率，所以我打算，擴充nutch的htmlParser這個外掛程式，把nutch只當作一個爬蟲，而索引這塊先不考慮。考慮採用自己建立solr伺服器來建立索引。 方案：動態代碼-->html-->轉化成xml或xhtml --> XSLT提取

        前面已對hadoop的MapReduce有了個大概認識，下面在看一下hbase中的MapReduce，TableMapper是繼承Hadoop中的Mapper類的，TableReducer是繼承Hadoop中的Reducer類的，詳見hbase官網API詳細說明。java.lang.Object org.apache.hadoop.mapreduce.Mapper<ImmutableBytesWritable,Result,KEYOUT,VALUEOUT>

mahout seq2sparse對應的源檔案是SparseVectorsFromSequenceFiles.java首先用DocumentProcessor.tokenizeDocuments方法，而這個DocumentProcessor類在mahout api文檔中是這樣描述的：“This class converts a set of input documents in the sequence file format of StringTuples.The SequenceFile

1.環境：主機win7-64，虛擬機器ubuntu-10.04-server-64，在安裝的過程中，選中裝samba，這樣是為了方便與主機共用和互傳檔案 2.到gluster官方網站(http://www.gluster.org/)上下glusterfs源碼，或已經編譯好的二進位檔案.deb 3.安裝glusterfs，不論是源碼編譯，還是選擇用.deb檔案來安裝，官方網站上都有詳細步驟。如果採用源碼編譯，則先解壓源碼包，然後到相應目錄下./configure、make、make

因為solr產生的索引是放在本地磁碟的，為了把搜尋索引放到HDFS上，所以最近看了一下搭建分布式Nutch和Nutch+solr的整合Nutch的抓取流程：對目標網站完成抓取後， 在儲存抓取資料目錄crawl 下產生了五個子目錄： crawldb，linkdb，segments，indexes 和 index 。資料庫 crawldb 中包含頁面的數目等；linkdb 包含頁面在資料庫中的連結，這是抓取器真正抓取網站時由頁面的連結數目決定；Segments

首先安裝jdk和tomcat，見前面兩篇博文。 下 載apache的官方網站 http://www.apache.org/dyn/closer.cgi/lucene/nutch/或http://www.apache.org/dyn/closer.cgi/nutch最新版本是apache-nutch-1.2-bin.tar.gz 安 裝解壓縮到某個目錄下即可，如/home/username/nutch 準備工作(1)

想讓Nutch定時抓取某一網站內容，cron正是解決這個問題的工具。 cron是linux下定時執行工具，可在完全無人工幹預的情況下作業。就像windows中的“任務計劃”功能一樣在Ubuntu server 10.04下，cron是被預設安裝並啟動的。通過/etc/crontab檔案，可以看到以下內容：       ------------------------------------------------------------------------------------------

nutch-1.0 的分布式查詢部署    nutch-1.0整合了hadoop的mapreduce實現分布式爬蟲方式，抓取的網頁及索引等都存放在HDFS上，但hdfs用於查詢是不切實際的，所以建議copy到本地之後做搜尋查詢。但如果索引檔案很多，索引資料量大，在一台機器上部署查詢勢必很慢，這時可以考慮分散式查詢方式，將索引分散在多個機器中；下面是分散式查詢方式的部署方式：首先定義兩點：1. search-servers.txt 所在的機器為主節點，設IP為172.16.100.1；2.