本篇要評測的nosql產品是hbase，和其他簡單的key-value結構不同，hbase主要面向處理海量資料的應用，可以認為是google bigtable的乙個開源版本。由於facebook使用hbase來儲存訊息內容和大資料量的實時分析而使得這一產品備受關注。
一、hbase簡介
hbase是用j**a開發的，是乙個開源的、分布式的、面向列的資料庫，其儲存的每個值都有乙個時間戳，可以根據定義好的規則儲存多個版本(預設是3個)，這樣就可以記錄資料的變動情況。
hbase和hadoop無縫整合，可以利用hdfs實現資料的底層分布式儲存，保證冗餘和可靠性，通過zookeeper來實現一致性和高可用性。
hbase有兩種部署方式：一種是比較簡單的單例項方式，它已經內建了0.20版本的hadoop包和乙個本地zookeeper，它們執行在同乙個jvm之下，可以用本地檔案系統而不用hdfs。
另外一種比較複雜的分布式部署，需要在每乙個節點替換自帶的hadoop包以免有版本問題，而且必須有乙個hdfs例項，同時需要獨立的zookeeper集群，這也是處理海量資料時的推薦的部署方式。本文為測試方便，使用簡單的單例項部署方式。
二、安裝和使用
首先從映象**最新版的hbase，目前最新的版本是0.90.3：
[root@localhost hbase]# wget
先檢查下本地的jdk版本是否在1.6以上：
[root@localhost hbase]# j**a -version
j**a version "1.6.0_24"
解壓並配置資料檔案的路徑：
[root@localhost hbase]# tar zxvf
[root@localhost hbase]# cd hbase-0.90.3/conf
[root@localhost conf]# vi
/home/banping/hbase/data
啟動hbase程序：
[root@localhost hbase-0.90.3]# bin/
starting master, logging to /home/banping/hbase/hbase-0.90.3/bin/../logs/
可以通過自帶的shell命令來進行基本的操作：
[root@localhost hbase-0.90.3]# bin/hbase shell
hbase(main):002:0> create 'test','cf'
0 row(s) in 0.9940 seconds
hbase(main):019:0> list
table
test
1 row(s) in 0.0290 seconds
hbase(main):022:0> put 'test', 'row1', 'cf:a', 'value1'
0 row(s) in 0.2130 seconds
hbase(main):023:0> put 'test', 'row2', 'cf:b', 'value2'
0 row(s) in 0.0120 seconds
hbase(main):024:0> put 'test', 'row3', 'cf:c', 'value3'
0 row(s) in 0.0130 seconds
hbase(main):025:0> scan 'test'
row column+cell
row1 column=cf:a, timestamp=1310027460885, value=value1
row2 column=cf:b, timestamp=1310027469458, value=value2
row3 column=cf:c, timestamp=1310027476262, value=value3
3 row(s) in 0.0870 seconds
hbase(main):026:0> get 'test', 'row1'
column cell
cf:a timestamp=1310027460885, value=value1
1 row(s) in 0.0250 seconds
hbase(main):027:0> disable 'test'
0 row(s) in 2.0920 seconds
hbase(main):029:0> drop 'test'
0 row(s) in 1.1440 seconds
hbase(main):030:0> exit
停止hbase例項：
[root@localhost hbase-0.90.3]# ./bin/
stopping hbase......
如果使用php操作hbase，可以使用facebook開源出來的thrift，官網是： ，它是乙個類似ice的中介軟體，用於不同系統語言間資訊交換。首先**最新的版本0.
6.1：
[root@localhost hbase]# wget
安裝需要的依賴包：
[root@localhost thrift-0.6.1]# sudo yum install automake libtool flex bison pkgconfig gcc-c++ boost-devel libevent-devel zlib-devel python-devel ruby-devel
編譯安裝：
[root@localhost thrift-0.6.1]# .
/configure --prefix=/home/banping/hbase/thrift --with-php-config=/usr/local/php/bin/
[root@localhost thrift-0.6.1]# make
[root@localhost thrift-0.6.1]# make install
生成php和hbase的介面檔案：
[root@localhost hbase]# thrift/bin/thrift --gen php /home/banping/hbase/hbase-0.90.3/src/main/resources/org/apache/hadoop/hbase/thrift/
[root@localhost hbase]# cd gen-php/hbase
[root@localhost hbase]# ll
total 320
-rw-r--r-- 1 root root 285433 jul 7 19:22
-rw-r--r-- 1 root root 27426 jul 7 19:22 hbase_
把php客戶端需要的包及剛才生成的介面檔案複製出來供php程式呼叫：
[root@localhost hbase]# cp -a /home/banping/hbase/thrift-0.6.1/lib/php /home/webtest/thrift/
[root@localhost hbase]# cd /home/webtest/thrift/
[root@localhost thrift]# mkdir packages
[root@localhost thrift]# cp -a /home/banping/hbase/gen-php/hbase /home/webtest/thrift/packages
啟動hbase和thrift程序：
[root@localhost hbase-0.90.3]# ./bin/
[root@localhost hbase-0.90.3]# ./bin/ start thrift
starting thrift, logging to /home/banping/hbase/hbase-0.90.3/bin/../logs/
thrift服務預設監聽的埠是9090。至此測試環境搭建完畢。
三、測試說明
1、測試環境
hbase部署在一台pc 伺服器上，配置如下：
cpu為xeon 2.80ghz *4
記憶體為4g
硬碟為一塊400g sata盤
作業系統為64位centos 5.3版本
2、測試方法
採用php客戶端進行測試，在安裝過程中我們已經獲取了php客戶端訪問hbase需要的包含檔案。
為了不對測試伺服器產生額外的影響，測試客戶端部署在另外一**立的伺服器上，執行的php的版本是5.3.5，web server是nginx 0.
8.54，通過fastcgi的方式呼叫php服務。使用apache ab工具實現多個請求和併發操作。
測試過程首先是進行寫操作，通過500個請求，每個請求寫入10000條記錄，併發度為1來共寫入500萬條資料，每個行(row)定義為數字1到5000000，列(column)標記為id:對應的行id，列value為100個位元組大小的資料，版本預設為記錄3個。然後是讀操作，發起5000個請求，每個請求隨機根據row id值讀出1000條記錄，併發度為10共讀出500萬條記錄，評測的重點是寫入和讀出資料的時間，以及在此過程中伺服器的資源使用情況。
四、測試結果
1、寫操作
成功寫入500萬條記錄，共耗時5418秒，平均每秒寫入資料923筆。磁碟上的資料檔案大小620m。寫入過程中，伺服器記憶體、cpu和磁碟等資源使用情況如下圖所示：
可見，記憶體使用平穩上公升，最後占用1g左右，主要用來快取資料，中間有偶爾的記憶體使用高峰，猜測是j**a 的垃圾**後會釋放記憶體。cpu使用非常平穩，idle穩定在79左右，幾乎沒有wait發生。磁碟io非常低，但是寫入速度較慢。
總體來說占用資源很少，表現也很平穩。
2、讀操作
成功讀出500萬條記錄，共耗時8521秒，平均每秒讀出資料587筆。
讀資料過程中磁碟io很低，幾乎沒有波動。cpu消耗較多，idle值穩定在13左右，等待cpu資源的程序一直有3到14個。記憶體表現平穩沒有波動。
四、總結
通過以上測試結果可以看出，hbase讀寫效率並不高，因為它是針對海量資料處理來設計的，側重的是海量儲存下的效能而非key-value儲存的效率，因此這也是正常的，另外由於寫入速度慢，因此磁碟io占用非常低，這和其他幾款nosql有明顯的區別。隨著**等國內網際網路巨頭不斷加大使用hbase的規模，相信在國內會有越來越多的成功案例。
NoSQL與SQL資料庫對比分析
目錄1.背景 3 2.傳統資料庫的缺點 3 3.nosql 解決方案 4 4.總結 30 隨著大資料時代的到來，越來越多的 應用系統需要支撐海量資料儲存，高併發 高可用 高可擴充套件性等特性要求。傳統的關係型資料庫在應付這些已經顯得力不從心，並暴露了許多難以克服的問題。由此，各種各樣的 nosql ...
資料庫之醫藥銷售管理系統
資料庫原理課程設計 題目醫藥銷售管理系統 學院 x 專業 班級 xx 學號 x 學生姓名 指導教師 編寫日期 2013.07.11 隨著近年來我國醫藥事業的迅速發展，我國藥品企業的經營呈現了多型式，例如大型藥品超市 連鎖藥店 小型藥品商店等綜合發展。隨著社會經濟的發展提高，這些醫藥企業也在不斷地擴大...
資料庫課程設計之飯卡管理系統
x大學 資料庫課程設計報告 題目名稱學生飯卡管理系統 班級小組成員 指導教師 2010年 1 月 2 日 目錄1 引言 1 1.1 系統定義 1 1.2 開發目的1 1.3 系統背景1 2 需求分析 1 2.1 資料流程圖1 2.2 資料字典4 2.2.1 資料項4 2.2.2 資料結構5 2.2....