雲裡霧裡的資料庫

隨著風起“雲”湧，近幾年已經浮現了一些非關係型，英文說法即 “non-relational, non-schematic” 的資料庫，不少人被搞得雲裡霧裡的。

Oracle 和 IBM，另外包括儲存廠商如 EMC、Teradata、HDS等（廣義來講，還包括虛擬化廠商 VMWare、Citrix等），因為上述廠商技術紮根都在傳統企業IT和資料儲存市場，即基於多年來非常成熟、基於SQL關係型模型的 OLTP 交易型和 OLAP 分析性應用。所以這些傳統IT廠商推廣雲端計算的時候，更強調將自家產品用於企業內部雲／私有云的場景，而非專用於亞馬遜、Google、Joyant等收租的公共雲IDC運營模式。

幾年前 Google 和 Amazon 所僱用的大量計算機專業博士們，基於多年積累、未商品化的學術研究成果，帶來了一些很不一樣的資料處理手段，即一般統稱的“非關係型”（或技術上不夠精確的所謂“非SQL”）資料庫（其中最火、最出名的是Apache Hadoop）。這些技術的的基本設計思路，在本質上，和上述傳統技術有著很大的區別，他們的設計理念源於支援網際網路行業平行計算，每天面對海量使用者所產生的增量資料，所帶來的現實資料壓力，這些是傳統企業IT技術架構無法在有限的經費內滿足的（即便軟體成本為零）。這些技術是基於以下條件所設計：

• 沒有任何單一儲存能大到 1) 容納得下整份資料，而且要 2) 能線性適應每天海量的資料增長速度 -- 現在這些使用者量大的Web2.0公司的資料，如 facebook，是以 P (petabyte) 級、而非 T 級，也就是千倍於T，很快要到 exabyte 級（順道一提，這是Oracle的一體機Exadata和Exalogic的命名意涵由來），也就是T級的百萬倍。所以這類新資料庫，在先天上都是分散式設計，自動分割槽，並且儲存於最廉價的commodity商品型伺服器的本地盤，而非光纖外聯高價的專業儲存裝置（“commodity”一詞的意涵，主要突出品牌的不重要性，如同商品期貨市場中交易的石油、黃豆、大米等）。
• 由於叢集了大量的廉價commodity伺服器硬體，穩定性和可靠性較低，硬體故障率 (MTBF) 變得比較頻繁，因此這類新型資料庫的設計，變成將硬體故障視為常態，而非異常。每筆資料在寫的時候，別臺硬體的磁碟上同時自動生成備份。
• 交易型的應用，採用一種新的終極一致性 (eventual consistent) 的設計，而非傳統 OLTP、兩階段提交這種立刻一致。亞馬遜內部使用的 Dynamo （Apache Cassandra是外人基於他們發表的學術論文而開源實現的一個資料庫），是這方面的領頭羊。這類資料庫比較適合對資料做反覆更新，而不像 Hadoop，更適合一次寫，多次讀。

分析型的資料庫和儲存，基於上述設計前提，出現了一批有別於傳統 OLAP+集中儲存的架構，在公共雲領域獨領風騷的是 Google 的 MapReduce 架構（和實現它的開源 Apache Hadoop；因為 Google 不將自家技術開源分享，儘管帶來了很多架構突破和創舉，但同時也被不少人詬病；Google 自家的 BigTable 和開源專案 HyperTable 也是一樣的關係）。這類資料庫適合一次寫（更新的效能很差，但只讀操作很快，有點類似 LDAP 伺服器的特性），和豐富的資料探勘方式和工具、程式設計／指令碼語言（如 Pig）。

雲空間中另外還有一些類似 Oracle Coherence 記憶體資料網格, Berkeley DB等採用“鍵-值對”雜湊的資料儲存技術，和相關開源專案。

國外有篇文章，對各類雲裡的資料庫，做了很扼要的分類和說明，挺不錯的。

如此一來，那是否意味著，這些非關係型資料庫，很快即將橫掃市場整個IT市場，顛覆傳統關係型資料庫，如許多所謂no SQL運動支持者們鼓吹的那樣？個人認為，在企業IT市場，基於傳統企業級應用的技術，在未來多年後，仍會保持主流的地位，大多數企業的業務在資料儲存、冗餘、交易一致性等方面的要求和所面對的上下文，實際上和有著海量使用者的網際網路公司或運營商相比，仍是有相當大的區別的。更何況現有企業的投資、人才、管理過程、政策等，都還是圍繞著傳統企業應用和關係型資料庫相關技術的。九十年代來勢洶洶的物件導向資料庫，並沒有如許多專家們預測般，取代了關係型資料庫（反倒是自己被融合了）。再舉個例子，就算是一個專搞面向消費市場／網際網路公共雲的公司，尤其是上市公司，仍是需要 Oracle 或 SAP 的財務應用（例如蘋果用的就是Oracle 的電子商務套件），而這些應用的背後，仍可能是Oracle資料庫。


本文僅代表作者個人觀點，與甲骨文公司無關。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16186206/viewspace-683425/，如需轉載，請註明出處，否則將追究法律責任。