超越傳統：NoSQL資料庫大比拼 助你輕鬆選擇資料庫

在兩三年前，選擇資料庫是一件非常容易的事。 資金充足的企業會選擇甲骨文資料庫，使用微軟產品的企業通常SQL Server，而預算不足企業則會選擇MySQL。 不過，如今的情況已經大不相同了。

最近兩三年，許多企業都推出了他們自己的開源專案以用於存儲資訊。 在許多案例中，這些專案拋棄了傳統的關聯式資料庫準則。 許多人將這些專案稱為NoSQL，即「Not Only SQL」的縮寫。 雖然有些NoSQL資料庫很簡單，但是還有一部分NoSQL資料庫極為複雜。 不過，它們的目標都是通過替代關聯式資料庫，並實現更高的系統性能。

NoSQL的支援者通過放棄傳統架構成功建立起了速度更快，擴充性更高的應用。 不過，一些保守的資料庫管理員對此卻不屑一顧。 他們認為，許多SQL已經解決的問題將成為NoSQL的絆腳石。 對此，NoSQL支援者並不在意，因為他們有著不同的專案需求，而如今他們正在瞄準新的目標。

NoSQL專案有什麼不同之處呢？ 這些新型資料庫被人們以自己的方式建立起來。 相反，老的SQL資料庫則聚合了大量的功能和一套標準語言。 套裝程式可能會將鍵與值進行配對，但是它們可以針對不同的使用案例進行調整。 主要的變數並不在於資料格式，而在於它們多久被覆制、存儲和分割。

例如，你是否存儲一些例如個人電子郵件地址等經常被恢復的資料？ 一些資料是否被存儲起來，以防不時之需，比如日誌檔？ 你是希望有更多使用小容量資料的使用者，還是希望只有幾名使用大容量資料的使用者？ 如果你丟失了幾行使用者資料，那麼你的行為是否會影響到你的使用者的生存，這些使用者是否會起訴你？

過去，每名架構師都會為MySQL的設置而苦惱。 現在，架構師可以選擇一個全新的專案。 如果你的專案需求與新型資料庫的性能匹配，那麼這種混亂中無疑蘊藏著巨大的優勢。 如果它們非常規整，性能將會獲得不可思議的提升。 但是，開發人員不會建造出一個可以解決所有問題的「無畏戰艦」。

以前，開發者會創建很好的跨資料庫函式程式庫以消除差異，讓它們變得更加容易轉換。 例如，許多JAVA開發者會在JDBC函式程式庫上編寫代碼。 這些資料庫有著很好的互通性。 老的函式程式庫沒有一個可以與這些新資料庫協同工作。 儘管許多專案使用的是相似的方法，但是將一個函式程式庫移植到另一個之上需要進行大量的重新編寫工作。

更糟糕的是，許多輔助專案消失了。 報告生成工具有許多種類，但是沒有一個新型資料庫可以使用這些工具。 如果不進行一番折騰，它們是不會工作的。 與SQL協同工作的套裝程式可能有成百上千種，但是能夠説明NoSQL的套裝程式卻很少。 有跡象顯示，這種互通性需要很長時間才能出現在NoSQL上。 此外，查詢語言也存在著很大的差異。

Cassandra

Facebook需要一個更快、更廉價的方式處理數以億計的狀態更新。 因此，他們啟動了這一專案，並最終將其移植到了Apache上，這就是Cassandra。 在Apache上，它能夠得到許多社區的説明。 目前Cassandra已經不再僅僅用於Facebook，許多為該專案工作的程式師來自其他公司。 如今DataStax.com公司正致力於為Cassandra供應商業支援。

Cassandra是一個跟蹤如Facebook上的狀態更新等大量資料的優秀工具。 這一工具可以説明創建一個電腦網路，網路上的所有計算都擁有相同的資料。 這意味著每台機器都可以被相互替代。 一旦資料通過P2P網路節點，它們的一致性就會喪失。 關鍵是「最終一致」，而不是「時刻一致」。 如果你發現你的狀態更新在Facebook消失一下，然後又重新出現，你就明白這意味著什麼。

CouchDB

CouchDB被用於存儲文檔，最大的變化在於查詢。 取代一些基本查詢結構的是，CouchDB通過兩種功能來搜索文檔，以導航並減少資料。 一個編排文檔格式，另一個確定包括哪些文檔。 一名清楚存儲程式的、熟練的甲骨文資料庫操作人員會做同樣的事情。 但是，導航和減少結構將讓基層程式師大開眼界。 目前，AJAX開發人員已經能夠編寫出相當複雜的搜索程式，這些程式可以寫入一些更為複雜的邏輯。

CouchDB的核心由Erlang編寫。 但是API和介面卻是JavaScript或是JSON。

JavaScript API僅僅是加強CouchDB對普通Web開發人員的吸引力。 這些開發人員可以將文檔，甚至整個網站存儲在資料庫中。

MongoDB

MongoDB是一個關於JavaScript如何掌握世界的典型。 程式獲取格式化為JSON格式的資料，然後將它們存儲起來。 查詢是JavaScript的基礎功能，這與使用瀏覽器主控台沒有太大的差別，只是簡化了一些東西。 最大的區別是，MongoDB會為你的資料庫創建索引，如果索引被正確地創建，那麼回饋查詢結果的速度將會很快。 另外，該資料庫可以與大量的其他工具協同工作。

Redis

與CouchDB和MongoDB一樣，Redis用於存儲文檔和由鍵值對組織的檔。 與其他的NoSQL資料庫不同的是，其存儲的不僅僅是字串或是數位，其中還包括分類和未分類的字串集合作為與鍵關聯的值。 這一特點使其可以為使用者提供更為複雜的集合操作。 使用者不再需要下載資料計算交集，因為Redis能夠在伺服器上做這一工作。

Redis催生了一些沒有過多編碼的簡單結構。 Luke Melia通過創建一個全新集合追蹤其網站上的訪問者。 最後五個集合的並集可確定那些當時線上的訪問者。 這一帶有好友清單的並集的交集可以生成線上好友清單。 這類集操作擁有許多應用。 Redis集群為我們揭示了其強大的功能。

Redis將資料存儲在記憶體中，僅記錄下每次變化的清單。 由於其具有功能強大，可寫入硬碟中寫入的緩存，許多人甚至並不將Redis稱之為資料庫。 由於Redis只需要在資料讀入記憶體之前進行等待，因此速度要比傳統資料庫快很多，但是不適時機的斷電導致其存在潛在的應用風險。

Riak

Riak是設計最為精巧的資料存儲，其擁有其他產品的絕大多數功能，並且對副本有著更多的控制。 儘管基本結構存儲著多對鍵值，但是恢復它們和確保它們的一致性的選項很多。 比如寫入操作包括了要求Riak確認資料何時被成功傳輸到集群其他機器上的參數。 如果你不希望僅信任一台機器，在發送確認資訊前，你可以要求其等待，直至兩台、三台或是54台機器寫入了資料。 這也是該團隊能夠打出「最終一致性不是資料遺失的藉口」這一口號的原因。

資料自身並不僅僅寫在硬碟中。 這只是其中的一個選項，但是並不是主要的。 Riak使用的是外掛程式式儲存引擎（預設為Bitcask）。 該引擎用它們自己的內部格式將資料寫入硬碟中。 此外，它還有多種選項，包括MySQL使用的InnoDB版本。 Riak的集群能力可以確保所有一切都萬無一失。

在抓取資料時，Riak會消除任何可能出現的錯誤。 如果在兩個節點的目標版本不同，那麼Riak會選擇最新升級版本，或是將兩個目標版本都回饋回來，交由你的用戶端代碼做決定。 對於發現資料中存在的潛在錯誤，這是一個非常有用的選項。

Neo4J

在我們所提到的幾個應用之中，Neo4J是最具特色一個。 它可以用於存儲圖而不是資料。 它對圖資料是以節點和邊（關係）模式進行存儲。 社交網路應用是它的強項。 Neo4J非常的新，開發人員仍然在尋找更好的演算法。 在新版本中，開發人員開始嘗試新的緩存策略：由於Neo4J能夠緩存節點資訊，因此搜索演算法運行速度很快。 開發人員還為其增加了類似XSL模式匹配的新查詢語言。

Neo4J受到了Neo Technology公司的支援。 該公司推出的商業用版本資料庫擁有備份、故障恢復和複雜監視功能。

FlockDB

有些人抱怨代碼過於複雜，他們認為Neo4J過於複雜，超出了他們的需求。 那麼他們不妨嘗試一下FlockDB。 FlockDB是一個即時的、分散式的資料庫，是Twitter網站基礎設施的核心元件。 Twitter在一年多以前推出了基於Apache許可證的開源專案FlockDB。 如果你想建立起自己的Twitter，那麼你需要下載Gizzard工具，其作用是分割跨多個Flock的資料。 由於FlockDB存儲兩個節點之間的關聯，我們中的許多人將FlockDB稱為「圖資料庫」。 不過，也有人認為這一稱呼僅適用于像Neo4J這類複雜的工具。

如何選擇NoSQL資料庫？

關於如何選擇NoSQL資料庫這一問題並不好回答。 許多IT部門會隨便選一個，有時候他們選擇的資料庫並不能滿足他們的需求。 由於優秀的開發人員希望能夠平衡專案的優勢、商業支援的可獲得性以及文檔品質，因此選擇一個最佳資料庫是十分困難的。

這些資料庫都存儲了大堆的鍵和值，但是真正的問題是如何在伺服器中合理分配負載，如何將變更傳遞給它們。 另一個問題是託管。 雲服務能夠替你完成所有的維護，這一點非常具有吸引力。 與SQL資料庫相比，NoSQL資料庫的資料交換更為困難。 目前全球還沒有一個標準的查詢語言，也沒有一個像JDBC一樣的大型虛擬層。 儘管如此，NoSQL資料庫已經對我們具備了足夠的吸引力。

(責任編輯：admin)