為了最大程度上測試ht的效能，簡單的選擇了隨機的寫入測試，主要是採用了random_write_test的測試程式。該程式主要是隨機的向乙個cf中寫入定長的資料，預設的cf寫入資料是1k位元組，rowkey約為24位元組，具體可以看**，採用自動mutor的方式來提交資料。（ 為了進行一些基本的測試，重新拿原始碼包編譯了一次，耗費了幾乎兩天的時間，遇見需要增加各種版本的依賴庫的要求，貌似都還好說，唯一記得的boost庫的版本要大於1.42，需要提供uuid特性，否則無法編譯，另外cmake的檢查指令碼有各種bug，鄙人直接修改了幾個檔案，幸好還懂點cmake。可能你會問為什麼不直接使用二進位製包中的測試程式來修改再編譯，這個就是hypertable的不成熟了，雖然有原始碼，有庫檔案，makefile也沒有問題，但是在連線靜態庫的時候，會有各種問題，如果你好奇的話，可以試試。還好，原始碼包編譯出來的靜態庫都沒有這些問題，不枉費哥花了快兩天的時間，不過，開發包只有靜態的，沒有動態的，所以，所以，簡單的乙個測試程式都有幾百m，真是坑爹，看來這些急需完善）
為了對比效能，選擇了幾組對比的測試：一，自動提交的mutor和手動提交的mutor；二，自動mutor，寫入的cf長度為1k位元組對比2k位元組；三，採用自動mutor方式提交資料，寫入cf為2k位元組，在兩台機器上，分別寫入200g資料。
測試的機器為8臺rangeserver，為sas盤，16g記憶體，千兆網絡卡，hypertable為預設配置，region**的limit為256m，記憶體使用本機的60%
一，自動的提交對比手動提交，很明顯，自動的mutor佔據了優勢：在1k的cf長度下，寫入總過2g資料的情況下，自動的提交的速度為20m/s，而手動的提交速度為500位元組每秒，相差了近40倍，這個和hbase自動flush是乙個道理。顯示出了批量提交時的高效傳輸。
二，採用自動mutor，寫入cf長度分別為1k和2k，在單個機器上執行random_write_test，寫入20g資料，速度分別為20m/s,和32m/s。
三，在兩個機器上執行測試程式，採用自動提交，寫入的cf長度為2k位元組，寫入資料量各為200g，總計400g。最終，統計得到的寫入速度是單個測試程式為30m/s，總共60m/s的有效寫入速度，相對來說，還是比較給力的，估計應該是強於hbase。但是，測試400g資料的過程中，從監控系統上可以看到有一定的效能的波動：
在插入了近70g資料之後，發生了較大的效能波動，寫入速度從100m/s回落到了60m/s。很明顯，每台rangserver可用記憶體為16×0.6g左右，8臺共計16×0.6×8 = 75g記憶體，在除去其他資料結構使用後，留給插入資料的應該是70g，在記憶體寫滿後，應該是進行flush，壓力主要在hdfs上。看來是主要瓶頸在hdfs上。
不過，從效能監控圖上看，ht對region的split幾乎並不敏感，中間並未因為split造成效能波動。從社群的討論上看，貌似ht採用了較為聰明的softlimit的方式來控制split，避免像hbase那樣的效能因為split而明顯波動。所以，從另外一方面說，在建表的時候，ht根本不需要預先分片這樣的優化措施，這個和hbase有極大的區別。
scrapy之爬蟲初體驗
本篇文章主要將怎樣建立乙個scrapy專案，以及完成第乙個scrapy爬蟲專案。首先是安裝scrapy模組，有很多原因都能導致scrapy模組安裝失敗，網上有很多教程讓怎樣安裝scrapy。親測比較有效的方法使用whl檔案安裝。不過有小夥伴也可以嘗試直接使用pip install scrapy命令進...
jfinal初體驗之Controller學習（一）
1.儲備知識 jfinal框架採用了傳統的mvc架構設計，來不及解釋了，快上車。jfinal的controller是執行緒安全的，所謂的執行緒安全就是在多執行緒訪問時，採用了加鎖機制來保護資料。這樣的做的好處是不會出現髒資料。2.開始旅程 controller中，最好保證它的純潔性，不要寫複雜的的業...
eosio之nodeos初體驗
1.什麼是eosio智慧型合約。2.eos相關概念 eos 軟體 eos平台 eos代幣 eos幣eos社群之間的關係 nodeos node eos nodeos 核心eosio的node守護程序，主要應用場景有 區塊產生，專用api終端，本地開發等。cleos cli eos cleos 與區塊...