想用數據庫，我們該選關系型還是NoSQL？曾幾何時，二者之間還存在著明顯的差異，但隨著近年來一系列關系型數據庫中對JSON支持能力的引入，原本明確的邊界開始變得愈發模糊。

但納入JSON支持能力不是應該讓RDBMS擁有更為雄厚的競爭資本，從而與NoSQL展開更加激烈的市場對抗么?話是沒錯，但從長遠角度看卻并非如此。關系型數據庫與NoSQL產品之間的真正差異仍然深在root與core層面，而且二者絕不可能因此而“攻守之勢異也”，即Oracle沒辦法憑借著JSON支持轉型、Hadoop也絕不會借助SQL查詢而倒戈。

JSON并不是問題的關鍵

首先，JSON支持能力本身并不是決定一款數據庫產品應否屬于NoSQL陣營的標準。AdRem軟件公司的Tomasz Kunicki(曾創造出NetCrunch監控系統，其中使用了內存內、SQL以及NoSQL等多種技術)贊同道：“JSON本身其實決定不了什么。它只是一種更為便捷的數據表示方式，特別是在大家利用JavaScript編寫代碼的場景之下。”

根據Kunicki的意見，NoSQL類方案的真正核心在于其“無模式數據庫與可擴展能力——但與大多數人的印象相左，這并不意味著NoSQL不需要數據庫建模。”他同時指出，這種誤解引發了關于NoSQL技術的大量不切實際宣傳與濫用。事實上，此類方案“特別適用于以時間為基礎的數據(且這些數據由該應用程序生成)處理場景”。

作為長期效力于微軟公司的老員工兼Snowflake數據倉庫即服務方案的聯合締造者之一，Bob Muglia認為關系型與NoSQL數據庫之間的本質差異在于二者在目標用途方面的設計思路。

Muglia指出，關系型數據庫在創建過程中強調高度一致性，但同時以速度與規模作為妥協因素——至少以此構建起速度出色且規模龐大的數據庫體系需要付出高昂的成本并面臨一系列難題。NoSQL則在一定程度上犧牲了不同節點之間的一致性水平，但借上實現了理想的速度表現與可擴展能力。

但這并沒有阻止人們嘗試將NoSQL類型的速度與規模引入關系型數據庫的野心，只不過通常而言這是一項極難完成的突破。“我們構建起Snowflake作為起點，并將MySQL作為原初系統來保存元數據，從而滿足事務對于基于ACID數據的全面需求，”Muglia指出。“除了規模擴展，我們還需要實現理想的可用性水平，也就是五個九——要想在關系型數據庫當中獲得五個九級別的可用性表現幾乎是癡人說夢……因此為了實現元數據存儲，我們將其由MySQL遷移到了全面基于ACID的NoSQL系統FoundationDB當中。”

添加了SQL查詢機制的NoSQL存儲體系仍然算是NoSQL

將JSON支持能力加入關系型數據庫并不會使其轉變為NoSQL系統，反過來、將SQL查詢機制納入NoSQL存儲體系也絕不會把它變成關系型數據庫——二者甚至連競爭關系都談不上。利用SQL對NoSQL存儲內容進行查詢能夠為用戶帶來極大便利，且在其內部無需對SQL(或者NoSQL)的運作方式進行任何再次定義。

正如Muglia所指出，由于SQL作為查詢系統的定位，目前已經有趨勢將SQL引入分析體系，“無論其中包含哪些影響因素”(也就是深層當中運行的究竟是怎樣的機制)，而由此引發的結果就是由SQL向事務系統轉型，“至少體現在高擴展能力與高可用性方面”。

Kunicki認為不同數據庫系統之間的固有差異必須得到認同與尊重。“將SQL添加到NoSQL數據庫當中，”他表示，“并將JSON文件的支持能力加入SQL數據庫只不過是一種嘗試欺騙用戶的表面性處理方式。”

當然，也有不少從業者真心看好將關系型數據庫(ACID事務)與NoSQL(速度與可擴展能力)雙方優勢加以合并的可行性與重要性。除了FoundationDB之外，目前還有包括Splice Machine(間接脫胎于Hadoop與Apache Derby項目)在內的一系列其它項目與產品正努力實現這項目標。

這一領域仍然處于起步階段，但真正的下一代產品很可能正來源于那些積極甚至有些激進的實驗性嘗試，而非簡單將數據格式或者查詢系統等底層技術組件進行彼此互換。