影像數據庫調研

參考Paul Graham比較各種編程語言的方法，我們比較各種數據庫的特點如下：

Oracle: 我們需要企業級數據庫。

MySQL: Oracle不開源。

PostgreSQL: MySQL的功能不夠多。

SQLite: 你可以把我嵌入到任何地方。這樣，4種數據庫夠大家用了。

MongoDB: 為什么我們要用join和模式(schema)?

CouchDB: 為什么我們要有集合(collection)?

Redis: 為什么我們要面向文檔？

Memcached: 為什么我們要用硬盤？

Neo4j: SQL缺乏足夠的關系。

Bigtable: MongoDB的對web的擴展性不管好。

Hbase: Bigtable不開源。

Cassandra: Bigtable不是Facebook開發的。

Riak: Cassandra不是用Erlang語言編寫的。

OrientDB: 讓我們把所有東西都放到同一個數據庫里！

?

下面看看各種數據庫的特點，或許會更清楚其中的幽默～

?

一、滿足極高讀寫性能需求的Kye-Value數據庫：Redis，Tokyo Cabinet，levelDB

Redis

Redis是一個很新的項目，剛剛發布了1.0版本。Redis本質上是一個Key-Value類型的內存數據庫，很像memcached，整個 數據庫統統加載在內存當中進行操作，定期通過異步操作把數據庫數據flush到硬盤上進行保存。因為是純內存操作，Redis的性能非常出色，每秒可以處 理超過10萬次讀寫操作，是我知道的性能最快的Key-Value DB。

Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數據結構，而且還支持對List進行各種操作，例 如從List兩端push和pop數據，取List區間，排序等等，對Set支持各種集合的并集交集操作，此外單個value的最大限制是1GB，不像 memcached只能保存1MB的數據，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的Set可以做高性能的tag系統等等。另外Redis也可以對存入的Key-Value設置expire時間，因此也可以被當作一 個功能加強版的memcached來用。

levelDB：LevelDB是Google開源出的一個Key/Value存儲引擎，它采用C++編寫的，支持高并發訪問和寫入，特別適合對于高寫入業務環境。影像數據庫讀次數遠大于寫。

sqlLite：多個進程或線程可以訪問同一個數據。可以并行的滿足多個讀訪問。但是只能有一個進行寫訪問；否則寫訪問失敗并帶有一個錯誤代碼(也可以在可配置的超時過期之后自動的重試)。缺點：采用文件鎖機制，限制了讀寫并行執行。

FastDb： 是高效的內存數據庫系統，具備實時能力及便利的C++接口。

缺點：FastDB不支持client-server架構因而所有使用FastDB的應 用程序必須運行在同一主機上。對每一 個使用數據庫的應用數據庫文件被影射到虛擬內存空間中，因而它受物理內存空間大小的限制。

Hibari ：（在日語中意思為“云雀”）是一個專為高可靠性和大數據存儲的數據庫引擎，可用于云計算環境中，例如 webmail、SNS 和其他要求T/P級數據存儲的環境中。Hibari 支持 Java, C/C++, Python, Ruby, 和 Erlang 語言的客戶端。

Hibari 并不是一個關系數據庫，主要是通過 key-value 的方法進行數據存儲。

主要特點：

• A Hibari cluster is a distributed system.
• A Hibari cluster is linearly scalable.
• A Hibari cluster is highly available.
• All updates are durable.
• All updates are strongly consistent.
• All client operations are lockless.
• A Hibari cluster’s performance is excellent.
• Multiple client access protocols are available.
• Data is repaired automatically after a server failure.
• Cluster configuration can be changed at any time.
• Data is automatically rebalanced.
• Heterogeneous hardware support is easy.
• Micro-transactions simplify creation of robust client applications.
• Per-table configurable performance options are available

二、 滿足海量存儲需求和訪問的面向文檔的數據庫：MongoDB，CouchDB

1、MongoDB

MongoDB是一個介于關系數據庫和非關系數據庫之間的產品，是非關系數據庫當中功能最豐富，最像關系數據庫的。他支持的數據結構非常松散，是 類似json的bjson格式，因此可以存儲比較復雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語 言，幾乎可以實現類似關系數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。

Mongo主要解決的是海量數據的訪問效率問題，根據官方的文檔，當數據量達到50GB以上的時候，Mongo的數據庫訪問速度是MySQL的 10倍以上。Mongo的并發讀寫效率不是特別出色，根據官方提供的性能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。對于Mongo的并發讀 寫性能，我（robbin）也打算有空的時候好好測試一下。

因為Mongo主要是支持海量數據存儲的，所以Mongo還自帶了一個出色的分布式文件系統GridFS，可以支持海量的數據存儲，但我也看到有些評論認為GridFS性能不佳，這一點還是有待親自做點測試來驗證了。

最后由于Mongo可以支持復雜的數據結構，而且帶有強大的數據查詢功能，因此非常受到歡迎，很多項目都考慮用MongoDB來替代MySQL來實現不是 特別復雜的Web應用，比方說why we migrated from MySQL to MongoDB就是一個真實的從MySQL遷移到MongoDB的案例，由于數據量實在太大，所以遷移到了Mongo上面，數據查詢的速度得到了非常顯著 的提升。

MongoDB也有一個ruby的項目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的接口，使用起來非常簡單，幾乎和DataMapper一模一樣，功能非常強大易用。

2、CouchDB

CouchDB現在是一個非常有名氣的項目，似乎不用多介紹了。但是我卻對CouchDB沒有什么興趣，主要是因為CouchDB僅僅提供了基于 HTTP REST的接口，因此CouchDB單純從并發讀寫性能來說，是非常糟糕的，這讓我立刻拋棄了對CouchDB的興趣。

三、滿足高可擴展性和可用性的面向分布式計算的數據庫：Cassandra，Voldemort

面向scale能力的數據庫其實主要解決的問題領域和上述兩類數據庫還不太一樣，它首先必須是一個分布式的數據庫系統，由分布在不同節點上面的數 據庫共同構成一個數據庫服務系統，并且根據這種分布式架構來提供online的，具有彈性的可擴展能力，例如可以不停機的添加更多數據節點，刪除數據節點 等等。因此像Cassandra常常被看成是一個開源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開發的：

1、Cassandra

Cassandra項目是Facebook在2008年開源出來的，隨后Facebook自己使用Cassandra的另外一個不開源的分支，而 開源出來的Cassandra主要被Amazon的Dynamite團隊來維護，并且Cassandra被認為是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。

Cassandra的主要特點就是它不是一個數據庫，而是由一堆數據庫節點共同構成的一個分布式網絡服務，對Cassandra的一個寫操作，會 被復制到其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。對于一個Cassandra群集來說，擴展性能是比較簡單的事 情，只管在群集里面添加節點就可以了。我看到有文章說Facebook的Cassandra群集有超過100臺服務器構成的數據庫群集。

Cassandra也支持比較豐富的數據結構和功能強大的查詢語言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter的平臺 架構部門領導Evan Weaver寫了一篇文章介紹Cassandra：http://blog.evanweaver.com/articles/2009/07/06 /up-and-running-with-cassandra/，有非常詳細的介紹。

Cassandra以單個節點來衡量，其節點的并發讀寫性能不是特別好，有文章說評測下來Cassandra每秒大約不到1萬次讀寫請求，我也看 到一些對這個問題進行質疑的評論，但是評價Cassandra單個節點的性能是沒有意義的，真實的分布式數據庫訪問系統必然是n多個節點構成的系統，其并 發性能取決于整個系統的節點數量，路由效率，而不僅僅是單節點的并發負載能力。

2、Voldemort

Voldemort是個和Cassandra類似的面向解決scale問題的分布式數據庫系統，Cassandra來自于Facebook這個 SNS網站，而Voldemort則來自于Linkedin這個SNS網站。說起來SNS網站為我們貢獻了n多的NoSQL數據庫，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的資料不是很多，因此我沒有特別仔細去鉆研，Voldemort官方給出Voldemort的并發讀 寫性能也很不錯，每秒超過了1.5萬次讀寫。

從Facebook開發Cassandra，Linkedin開發Voldemort，我們也可以大致看出國外大型SNS網站對于分布式數據庫， 特別是對數據庫的scale能力方面的需求是多么殷切。前面我（robbin）提到，web應用的架構當中，web層和app層相對來說都很容易橫向擴 展，唯有數據庫是單點的，極難scale，現在Facebook和Linkedin在非關系型數據庫的分布式方面探索了一條很好的方向，這也是為什么現在 Cassandra這么熱門的主要原因。

?

?