簡介

假設說你想要開發一個網站或應用程式，顯然你需要管理資料的方法，對了，就是資料庫。那麼，你的選擇是 MySQL、MS-SQL、Oracle 或 PostgreSQL？畢竟，沒有什麼能像關聯式資料庫那樣漂亮地運用 SQL 管理資料。

不過嘛，就讓我為你介紹一個獨特且非常規的資料庫模型，NoSQL。NoSQL 意指不僅僅是 SQL，出發點不在於反對 SQL，而是對資料儲存提供替代方案。然而，顯然大多數用戶都對 SQL 很熟悉，許多 NoSQL 資料庫也會提供類似 SQL 的查詢介面。

為什麼要用 NoSQL？

這問題問的合理，以下有若干原因：

• 管理大規模資料：NoSQL 資料庫能輕易處理大量的讀寫週期、眾多用戶，以及數以 petabytes 計的資料。
• 資料庫綱要 (Schema)？不需要：多數 NoSQL 資料庫沒有綱要，所以相當彈性。當涉及到綱要建構之時，它們提供了相當廣泛的選擇空間，能輕易地和物件相對應。這表示再也看不到像是正規化與複雜資料連接 (complex joins) 等字眼。
• 開發者親和性：NoSQL 資料庫對各主要程式語言提供了簡單的 API，因此再也用不著複雜的 ORM 框架。如果特定程式語言沒有 API 可用時，還是可以透過簡單的 RESTful API，使用 XML 以及 JSON 格式經由 HTTP 存取資料。
• 可用性： 多數分散式 NoSQL 資料庫都提供簡易的資料複製，單一節點的毀損不會過分地影響資料的可用性。
• 延展性：NoSQL 資料庫不需要專用的高效能伺服器。事實上，它們可以輕易地運行在一般硬體組成的叢集上，只要增加新節點就可輕易向外延展。
• 低延遲：除非你跑的是 trillion 等級資料伺服器組成的叢集，否則 NoSQL 應該可以協助你達成絕佳的低延遲性。當然，延遲本身與可成功載入記憶體中的資料量有關。

SQL 思想

NoSQL 基本上拋棄了傳統的 SQL 思想，轉而靠往 CAP 定理或稱 Brewer 定理 (Brewer’s Theorem)。該定理由 Eric Brewer 於 2000 年提出，談的是有關一致性、可用性與分區容忍性 (Consistency, Availability and Partition Tolerance，CAP) 這三條基本法則，並指出分散式資料庫最多僅能滿足其中兩個條件。由於採用了較一致性更為寬鬆的最終一致性 (Eventual Consistency)，NoSQL 實現了此一定理，因此大幅改進了可用性與延展性。此一典範通常稱之為 BASE，意指基本可用 (Basically Available)、軟狀態 (Soft state)、最終一致性。

NoSQL 資料模型

NoSQL 之間的主要差異如下：

1. 文檔儲庫
2. 階層式
3. 網絡
4. 以列為導向
5. 物件導向
6. 鍵值 (Key-value) 儲庫
7. Triple 儲庫

文檔儲庫

資料組織簡單到僅有列與行的日子已經一去不返。今天，資料通常以 XML 或 JSON 的格式表達 (基本上我們談的是 Web)。採用 XML 或 JSON 的原因，是上述兩者可攜性都很高，且簡潔又標準化。說白了，把 XML 或 JSON 文件對應到關聯式模型上沒有什麼意義。更聰明的抉擇是運用已經存在的文件儲庫。為什麼？因為 NoSQL 資料庫沒有綱要，不用對 XML 或 JSON 文件事先定義，結果就是每個文件都是彼此獨立的。這樣的資料庫可以用在 CRM、網路相關資料、即時資料等。此模型的著名實作包括 MongoDB、CouchDB、RavenDB。事實上 MongoDB 已經運用在 bit.ly 與 Sourceforge 等網站上。

階層式資料庫

這一類的資料庫將資料以階層相關性的形式加以儲存，也就是樹狀或親子關聯。在關聯式模型中，可以稱之為 1:N 關係。基本上，空間地理資料庫可以用階層形式儲存基本上是階層式的位置資訊。地理標記與地理定位 (geotagging and geolocation) 近來盛行，使得空間地理資料庫變得非常切題，可以被運用在地理資訊系統中，主要的例子包括 PostGIS、Oracle Spatial 等。階層式資料庫著名的實作包括 Microsoft 的 Windows Registry 與 IBM 的 IMS 資料庫。

圖形 (Graph) 網絡資料庫

圖形資料庫是網絡資料庫最普遍的形式，用來儲存可以用圖形 (Graph) 形式表達的資料。基本上，用圖形資料庫儲存的資料會以指數速度成長，因此圖形資料庫最適合儲存會經常改變的資料。撇開理論部分，圖形資料庫最令人驚艷的案例是 Twitter 用以實現用戶追蹤 (follow) 圖形的 FlockDB。FlockDB 使用了 Gizzard 框架達到每秒 1 萬次的資料庫查詢。對圖形進行查詢的典型技術，是從任意或特定起始節點開始，跟著以廣度優先或深度優先方式，走訪整個圖形。多數圖形資料庫允許開發者用簡單的 API 完成查詢工作。除了 FlockDB，知名的圖形資料庫還有 HyperGraphDB 與 Neo4j。

以列為導向的資料庫

Google 針對內部使用的 BigTable 分散式儲存系統，發表研究論文之後，以列為導向的資料庫蔚為風潮。知名的其他實作包括 Hadoop Hbase、Apache Cassandra、HyperTable。

這類資料庫的實作更像是三維陣列，第一維是行識別碼，第二維是列族 (column family) 與列識別碼，第三則是時間戳記。Facebook、Reddit、Digg 等都運用了以列為導向的資料庫。

物件導向資料庫

雖然物件導向資料庫是否為 NoSQL 資料庫還有爭議，不過因為與傳統關聯式資料庫的資料模型差距甚遠，因此通常被視為是 NoSQL 資料庫其中之一。這類資料庫允許資料以物件形式儲存。知名的像是 db4o、NEO、Versant 等。物件導向資料庫一般被用在研究用途或 web 規模的生產環境中。

鍵值儲庫

鍵值儲庫是以 Amazon 的 Dynamo 研究論文以及分散式雜湊表為基礎。這類資料模型非常簡單，一般只包含一系列的全域鍵值對，每個值各伴隨有獨特的鍵。因此這類資料庫有高度延展性，不以關聯性方式儲存資料。知名實作包括 LinkedIn 開源的 Voldemort 專案、Redis、Tokyo Cabinet 等。

Triple 儲庫

Triple 儲庫以主語、謂語、對象 (subject-predicate-object) 的形式儲存資料，用謂語作為主語和對象間的連接因素。因此，Triple 儲庫也算是網路資料庫的變形。以“Jonny Nitro 閱讀資料中心雜誌”為例，Jonny Nitro 是主語，資料中心雜誌是對象，閱讀則是連接兩者的謂語。很顯然，要把這樣的語義查詢對應到 SQL 相當困難，因此 NoSQL 提供了一個可行的替代方案。Triple 儲庫主要實作包括 Sesame、Jena、Virtuoso、AllegroGraph。

結論

那麼，你已經對 NoSQL 有些瞭解了，但這表示你應該從 SQL 跳到 NoSQL 嗎？這個答案要視個別情況而定。如果你覺得 SQL 查詢太難以對付，NoSQL 對你而言可能同樣不簡單。然而，如果你正在找尋更有彈性的替代方案，且不介意親自動手，你無疑應該嘗試看看 NoSQL。選擇權在你手上。祝你資料管理快樂！

相關網址：

1. NoSQL 入門指引
   https://www.codeproject.com/Articles/630103/A-Beginners-Guide-to-NoSQL