【源文】https://www.datanami.com/2017/09/25/sql-databases-integrating-nosql-like-features
【譯文】
過去的幾十年間，關系型數據庫（SQL）在全世界幾乎應用到所有類型的業務。其技術可靠，標準穩定，整體成熟已超過20多年。

非關系型數據庫（NoSQL）的概念實際早于關系型數據庫，但他們只是在10年前變成切實可行。然而，在他們開始做后，主要在兩類業務中快速被推廣應用。第一類是大型數字經濟公司，他們需要前所未有的擴展，第二類是技術初創公司，他們尋找廉價易用的數據庫解決方案，以滿足其擴展要求。

鑒于NoSQL功能流行度的提升，SQL數據庫廠商開始注意，并在其數據庫架構中實現類NoSQL類的功能。

在我們深入討論之前，有必要先更好的理解為什么NoSQL會取得現在的地位。

NoSQL的誘惑力

NoSQL數據庫主要的亮點體現在兩個方面：擴展性和彈性。

在基礎設施和擴展性方面，幾十年間隨著業務的增長，數據量也同步增長，傳統的手段是垂直擴展，即升級至更強的數據庫服務器。然而，基于云計算、商業服務器，企業現在可以實現水平擴展解決性能和高可用需求，即分布式部署NoSQL數據庫，跨數據中心復制數據（如果必要，跨全球也可實現）。

管理關系型數據庫是一項有技巧、成本高的運維工作，既是是使用開源產品，這就阻礙了其在初創企業的應用。使用NoSQL數據庫將大幅削減對DBA角色對需求，尤其是當使用云服務時，該角色甚至消失。

在數據架構中，彈性已成為關鍵。傳統做法是，遵循范式規則創建數據模型，該方法成型的年代，存儲設備非常昂貴，人們盡力避免數據冗余。但范式規則對改進產生了巨大對束縛。對于數據庫模式做的任何變更都意味著繁重的操作和高成本的協調，既是是為了改進應用，這限制了企業的靈活性。除了上面提到的基礎設施的革新，NoSQL的真正革命性的方面是其彈性，可以快速適應業務改變的需求。NoSQL數據庫這方面被錯誤的稱之為“無模式”。

這個詞一方面有效的抓住了人們的注意力，但也傳遞了錯誤但印象，即開發者不需要思考待存數據但結構。事實上，在使用NoSQL數據庫時，數據建模甚至比之前更家重要。為了表達持續的彈性，更好的術語可能是“動態模式”。

NoSQL降低了總體擁有成本

感謝上面的兩個特性，應用的總體擁有成本（TCO）得到了大幅降低，因為企業開發變得更加靈活，IT部門可以更加快速的響應競爭環境的變化。

NoSQL易入門、擴展性好、可靠性高、彈性好，且靈活，這些因素導致只需更少成本的程序就能滿足業務需求。這可能不足以證明翻寫已有的應用，但對于任何新項目，采用NoSQL就有意義了，它可以阻止技術債的增長和創造高成本的資產。

選擇關系型數據庫的常見論點是，它們的一致性、引用完整性以及能基于兩階段提交來處理事務。的確如此，當今這些功能技術對于大型、本地復雜應用依然有用。然而，在以異步、無狀態WEB服務組成的相互連接的世界中，這種優勢正在快速消失，這這種應用環境中要求應用能容忍事務處理的失敗。基于NoSQL數據庫，大部分業務可以接受和實現最終一致性，尤其是這能讓網站用戶保持耐心。

JSON的影響

對于特定的應用有許多不同的方式來設計關系型數據庫，范式規則和引用完整性提供來一種防護措施來應對各種設計問題。對于NoSQL文檔數據庫，JSON的特點是靈活性和功能強大，它給新用戶一種錯誤的安全感。相比關系型數據庫，對于NoSQL數據庫而言，數據建模變得更加重要，它使用戶創建不同的What-if腳本。

NoSQL數據庫開始成為主流后，SQL數據庫廠商感受到一些影響。對于傳統數據庫廠商最簡單的事情是增加對JSON文檔對支持。這種方式對應了NoSQL文檔數據庫對靈活性的優點。需要小心的是，每個廠商本地檢索復雜對象的能力是否與這種新能力匹配。同時，每個廠商擴展策略仍然沒有太多改變。這就意味著你不能自然的使用NoSQL技術來真正的實現水平擴展。

盡管如此，也很少發現在SQL數據庫中實際存儲JSON數據的用戶。廠商們或許不知道這個比例，但依然好不猶豫的采取防御措施，嘗試將NoSQL數據庫排除在企業IT部門之外。無論如何，在SQL數據庫中增加JSON存儲似乎只是一種附加物，而NoSQL文檔數據庫則明顯是有意內置的。同時，我們也觀察到一些大的SQL數據庫廠商收購了一些NoSQL數據庫，這也反應了NoSQL市場的增長。有人會認為這是產品經理忙于將不同的產品打包至一個解決方案中。

幾乎每個月都有一款新NoSQL產品發布，但這難以持續下去。面對快速發展的每個細分市場，我們可能更關注改組、強化、合并。已確立的運動員會防衛他們的場地，以捍衛現有的得分，另一面挑戰者會出創新牌。一些挑戰者會壯大，而另一些挑戰者會被收購、兼并。讓我們期待最好的技術能勝出，而不是最好的市場推廣能力。

NoSQL數據庫廠商的回應

當然，NoSQL廠商并不會坐而待斃。首先，他們從單一功能，轉變為多模型方法。而且，在宣稱NoSQL數據庫為“非關系型”后，人們意識到關系存在于數據語義學中，無論數據庫是否支持外鍵約束。結果，用戶要求NoSQL數據庫廠商增加關系特征，例如，MongoDB引入了跨多集合的lookup功能和只讀視圖，以應對執行用戶的請求，還有增加ACID能力來應對缺乏事務支持對非議。另外，一些增加了類似SQL對查詢句法來幫助開發者過渡。

最后一個需要考慮的是，如果你從沒有強制規范化過，那么使用JSON來進行數據建模會很自然，但是習慣的力量是頑固的，尤其你是SQL老手。結果，如果你從事過關系數據庫，使用JSON建模則需要換思路，不論是在傳統數據庫中內置JSON組件，還是NoSQL文檔數據庫。你需要取挑戰那些不可改變的原則，那些范式和事務原子性。

為了合理的利用NoSQL的優勢，你需要強迫自己忘記第三范式，而從如何訪問數據的角度來思考。你想要寫數據庫是連接數據，所以你要做的是當你讀取時將其存儲在一起。這種思想轉變很難，尤其是在同樣的數據庫里，你可能暫時需要能以傳統規范的方式存儲數據。

NoSQL玩家持續增加特性以幫助該技術的成熟，NoSQL數據庫會占據一席之地，最終會成為主流，走入企業IT的視線。同時，SQL廠商可能會說服已安裝的數據庫保持現狀。標準化一份老的技術也許會很安全，IT部門也不會使自己喪失新技術帶來的益處。他們會實驗和判斷，以選擇合適的的工具來完成各自的業務需求。

關于作者 Pascal Desmarets

Pascal Desmarets為Hackolade創始人、CEO，他帶領團隊打造來一系列可視化工具，以幫助NoSQL技術在IT架構中應用推廣。Hackolade軟件讓NoSQL文檔數據庫的數據建模更加舒適和易用。pascal.desmarets@hackolade.com.