NoSQL 入門指引

簡介

假設說你想要開發一個網站或應用程式,顯然你需要管理資料的方法,對了,就是資料庫。那麼,你的選擇是 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



自由軟體鑄造場電子報 : 第 224 期 NoSQL 入門指引

分類: 源碼專案