開源數據興起：選擇 MySQL 、 NoSQL 或是兩者都要

◎本文翻譯自 The Next Web，原作者為 John Engates：https://thenextweb.com/dd/2014/03/04/open-source-data-grows-choosing-mysql-nosql/?fromcat=all#!yEuER

John Engates 是 Rackspace Hosting 的 CTO ，也是開放式雲端的推廣者。

開源數據具有分裂的特性。

NoSQL 的狂熱者們喜歡接連地對關聯式數據資料庫發表具有攻擊性的長篇演說，接著 MySQL 的愛好者們會堅定的捍衛其所有結構－與所有的數據資料整齊地存放在目錄的某個地方。

對於所有的說辭，你可能會覺得這兩方從沒和睦相處過。但事實上，有成千上萬的公司每天都在使 MySQL 和 NoSQL 好好地運作，而且也已經持續了許多年。

但是新技術的發展趨勢有極化的傾向。當 NoSQL 開始興起，它像是在訴說 MySQL 的結束。短時間內不太可能發生－這是個很好的理由。

進入 Craigslist

Craigslist 是一個使結構化和非結構化的數據檢索無縫結合的好例子。該公司也已經使用 MySQL 來處理工作和分類廣告的突擊。

儘管工作繁重， MySQL 還是輕易地完成了任務。只有當要將數據歸檔遇到困難時，需要 NoSQL 的想法才出現。由於管理上的需要， Craigslist 必須將它所有的歷史資料歸檔－甚至是五年前的暗淡廣告，在 SXSW 期間，一間在 Austin 定價過高的公寓。

如果一個關聯式數據資料庫只有唯一的邏輯在運作，那麼，只要一個在前端的架構改變，將會影響到歸檔。這是一個存在風險且耗時的前景，它意味著當機的時間。試著想像一下 MySQL 群集的服務器更新十億筆記錄！

Craigslist 發現自己有處理兩種不同類型數據資料的需求－現在的和過去的－以分開的方式。 Craigslist 可能會求助於 MongoDB 來幫助它的數據能順利地展開，但它在 NoSQL 與 MySQL 的並排運行上從來沒有出現問題。它不過是正確的工作方法。

開源同盟者

越來越多的應用程式開發者和主機供應商，有了在不同方面的數據資料庫內，NoSQL 和 MySQL 並不是敵人，而是開源盟友的認知。在一天的結束，數據資料就是數據資料，它應該要服務其應用程式和使用者，而不是限制其後端數據資料庫的技術。

也有越來越多的 Rackspace 客戶群發現他們有著像 Craigslist 一樣的情況。當關聯式數據資料庫取代了他們所有的基礎，並且發現自己正處於應用程式的時代深處時，他們建立了自己的數據結構。

當要達成一百萬個客戶已經從幾年下降到幾周的時間，且對於數據資料在社交分享和即時查詢上有新的需求時－即支援該數據的基礎構造。突然地，他們每個月都會出現大量的數據資料。

他們不是要詛咒自己的 MySQL 數據資料庫，不過他們期待將數據引擎擴大。有時將 MongoDB 、 Cassandra 、 Redis （和其他的）數據結合，大規模地混合他們的速度和機動性。但這些開源數據存儲不太可能用於機密的使用者資訊或是財務記錄上，因為那必須在任何時候都保持相容一致。

現今，對技術公司來說雇用關聯式的數據管理員和一個開發團隊使用它們建立在應用程序的 NoSQL 一樣，是很常見的。有時候，相同的應用程式與 MySQL 和 NoSQL 的數據資料庫在 Web 層連結。

在興起的 NoSQL 之下，守舊派的數據管理員和新一代的開發者，在作關於配置和組織的判斷時必須合作。（誰知道呢，數據管理員和開發者有可能成為朋友。）

對於上述這些公司，它也可能沒有任何一個 DBA 和外包整個應用程序及數據資料層的主機供應商，在這種情況下，他們希望以專業知識及團隊合作來跨越 SQL / NoSQL 的分裂。

選擇哪一個？或者你甚至必須選擇？

應用程式是否應該伴隨著 MySQL 或者以 NoSQL 替代（或者兩者兼具），當然，數據資料的性質正是在於產生和檢索。然而，像大多數在科技世界裡的事情一樣，它有著一套折衷的權衡機制在作判斷。

如果規模和性能比全天候數據資料的一致性更為重要，那麼 NoSQL 的世界充滿前途無限的選項。（ NoSQL 信賴 BASE model －基本可用、舒適的狀態和結果一致性）。

但是，如果「始終保持一致」是指令的一部份，特別是對於機密訊息和財務資訊，那麼 MySQL 很可能是最好的選擇。（ MySQL 信賴 ACID model －原子性［不可分割性］、一致性、隔離性和耐久性）。

隨著開源數據資料在結構化數據資料庫牆的兩側成熟發展，我們看到 ACID 和 BASE models 雙方都發揮出相對優勢的新類型應用程式。

我們稱呼它為一種混合的方式。有時這些應用程式在設計上需要注意平衡，而有時他們發展成意外事件，一套適應不斷改變要求的數據資料。畢竟，誰能夠預料到這大規模社會共享數據資料的串連，甚至是五年前？

像往常一樣，開發人員們走在這種創新的前端。他們推動主機供應商將兩個數據資料最好的優點結合。他們也在必要時將開源數據技術的軌跡作修正。

例如 MariaDB ，是企圖改造開源根基的 MySQL 在 Oracle 之後擁有了它。這些社區發展者需要自由的開源工具，包含在測試的案例下能自由地運作 bug 的修復處理。

由於這種混合方式一直持續到 2014 年以及往後，主機公司只能提供更好支持。就像媒介，我們停止數據資料的世界是個「任一的／或者」二元方程式的假設。

將專用硬體的性能和公用雲端的可擴展性混合，不但可以增強其機動性，更成就了一個最適合的解決方法。這就是工作的正確手段。像在混合雲端發生的事情一樣，並沒有太大的不同。

收集和解釋數據資料的目的，畢竟像快速通過一樣，只能捕捉住這世界的某一小部分。數據資料，無論它從何而來，它僅僅是一個窗口。重要的是用不同觀點發現另一側的視野。