你肯定會認為這兩方?jīng)Q不可能和睦相處，但事實上，成千上萬的公司一直都在努力將關(guān)系型和非關(guān)系型數(shù)據(jù)庫結(jié)合起來，而且很多年前就有這樣的嘗試了。
但新技術(shù)的發(fā)展往往和過去的技術(shù)對立。當NoSQL發(fā)展起來時，光這個名字聽起來就像是要宣告關(guān)系數(shù)據(jù)庫的終結(jié)，但這是不可能的，至少不會這么快。
Craigslist的成功
Craigslist公司無縫集成結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)檢索是個很好的例子。過去，該公司一直用MySQL處理頻繁的任務和分類廣告。
盡管工作量很大，MySQL還是能輕松地完成這項任務。只有當存檔數(shù)據(jù)達到超紀錄的級別時，才會產(chǎn)生對NoSQL的需求。由于管理的要求，Craigslist必須將所有歷史數(shù)據(jù)存檔——即使是SXSW期間為奧斯汀那昏暗、高價的公寓所做的廣告也得存檔。
如果一個關(guān)系型數(shù)據(jù)庫依靠數(shù)據(jù)之間的邏輯，那前端架構(gòu)的更改必然會影響到存檔數(shù)據(jù)。這是一個高風險、高時耗的過程，而且它會造成停機時間損失。想象一下去更新帶有10億條記錄的MySQL服務器集群!
Craigslist發(fā)現(xiàn)需要以離散方式處理兩類數(shù)據(jù)——當前數(shù)據(jù)和歷史數(shù)據(jù)。Craigslist或許已經(jīng)轉(zhuǎn)而使用MongoDB幫助應對數(shù)據(jù)的增長，但是與MySQL一起運行的NoSQL也從沒有出現(xiàn)過問題，這說明MySQL和NoSQL可以很好的結(jié)合。
開源同盟
越來越多的應用開發(fā)商和托管服務提供商認識到NoSQL和MySQL一直是開源同盟，沒有因數(shù)據(jù)庫類型不同而成為不相往來的仇敵。歸于一點，數(shù)據(jù)就是數(shù)據(jù)，它應該用來為應用程序和用戶服務，不應該受到后端數(shù)據(jù)庫的限制。
越來越多的Rackspace客戶發(fā)現(xiàn)自己面臨和Craigslist同樣的處境。當關(guān)系型數(shù)據(jù)庫涵蓋所有他們的數(shù)據(jù)領(lǐng)域時，他們構(gòu)建了自己的數(shù)據(jù)結(jié)構(gòu)，而現(xiàn)在他們已經(jīng)進入應用時代了。
達到100萬客戶原先需要數(shù)年時間，現(xiàn)在只需要幾周就可以了，而且社會共享和實時查詢對數(shù)據(jù)提出了新的要求——也需要支持這些數(shù)據(jù)的基礎設施，這一系列變化使他們面臨的數(shù)據(jù)量達到了每月10億之巨。
他們不一定要挖掘MySQL數(shù)據(jù)庫，但他們需要增加數(shù)據(jù)引擎。為了增加數(shù)據(jù)庫的速度和靈活性，MongoDB、Cassandra或者Redis(這類數(shù)據(jù)庫)會被納入數(shù)據(jù)結(jié)構(gòu)中。但這些開源數(shù)據(jù)庫不太可能用于存儲用戶機密信息或者財務記錄，因為這些內(nèi)容必須始終保持一致性。
目前，技術(shù)公司在聘請傳統(tǒng)關(guān)系型數(shù)據(jù)庫管理員同時，組建一個NoSQL應用開發(fā)團隊也很常見。有時，基于關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫的同一個應用甚至可以在Web層進行通信。
過去的數(shù)據(jù)庫管理員必須和新一代使用NoSQL編程的開發(fā)人員合作，進行有關(guān)部署和體系結(jié)構(gòu)的決策(也許這些數(shù)據(jù)庫管理員和開發(fā)人員也能成為朋友)。
可能這類公司連數(shù)據(jù)庫管理員也沒有，它們將所有的應用和數(shù)據(jù)層外包給托管服務供應商，這樣的話，它們就得充分利用深厚的專業(yè)知識和團隊合作，才能跨越SQL與NoSQL之間的鴻溝。
選擇其中一個?還是兩者都要?
應用程序是否應該與關(guān)系型數(shù)據(jù)庫或NoSQL(也許是兩者)相一致，當然，這得基于被生成或被檢索數(shù)據(jù)的性質(zhì)。和大多數(shù)科技領(lǐng)域的事物一樣，做決定時要折中考慮。
如果規(guī)模和性能比24小時的數(shù)據(jù)一致性更重要，那NoSQL是一個理想的選擇 (NoSQL依賴于BASE模型——基本可用、軟狀態(tài)、最終一致性)。
但如果要保證到“始終一致”，尤其是對于機密信息和財務信息，那么MySQL很可能是最優(yōu)的選擇(MySQL依賴于ACID模型——原子性、一致性、獨立性和耐久性)。
作為開源數(shù)據(jù)庫，無論是關(guān)系型數(shù)據(jù)庫還是非關(guān)系型數(shù)據(jù)庫都在不斷成熟，我們可以期待還會有一大批基于ACID和BASE模型的新應用產(chǎn)生。
暫且把它稱為混合方案。有時這些應用程序的設計需要認真地權(quán)衡利弊，有時還能意外的得到發(fā)展，做出一系列調(diào)整以適應不斷變化的數(shù)據(jù)需求，畢竟，誰能預測到今天社會共享數(shù)據(jù)的大規(guī)模增加(即使是在五年前)?
像往常一樣，開發(fā)人員處于這種創(chuàng)新的最前沿，他們促使托管服務提供商將這兩個數(shù)據(jù)領(lǐng)域結(jié)合到一起。在必要時候，他們還會對開源數(shù)據(jù)技術(shù)進行修正。
比如，在Oracle占有了MySQL后，MySQL有閉源的風險，基于MySQL的MariaDB很好的替代了MySQL。開發(fā)者社區(qū)要求其開源工具完全透明，包括開放對測試用例bug修復的權(quán)限。
此混合方案在2014年將繼續(xù)發(fā)展，托管公司也會提供更好的支持。在媒體上，我們就不會再說“要么關(guān)系型數(shù)據(jù)庫，要么非關(guān)系型數(shù)據(jù)庫”這樣的話了。
這和混合云領(lǐng)域所用方法是類似的。專用硬件有著優(yōu)越的性能，而公共云有很好的可擴展性，結(jié)合兩者優(yōu)點可以帶來更大的靈活性，產(chǎn)生最合適的解決方案，這才是解決問題的最優(yōu)辦法。
畢竟，數(shù)據(jù)收集和解釋的最終目標是捕獲這個瞬息萬變世界發(fā)生的每一條信息。數(shù)據(jù)，無論來自何處，都只是一個窗口，真正重要的是透過這個窗口看到的景象。
