?

為解決大規模數據集合多重數據種類帶來的挑戰，NoSQL 應運而生，但現在卻也遇到了諸多問題，本文作者 Rick Negrin，曾在微軟工作 12 年，并在 SQL Server 團隊度過大部分光陰，他提出，是時候「和 NoSQL 說再見」了！

作者 |?Rick Negrin

譯者 |?明明如月

責編 | 唐小引

頭圖 | CSDN 下載自東方 IC

出品 | CSDN（ID：CSDNnews）

以下為譯文：

是時候承認我們早就知道的事實了：NoSQL 并不適合現代應用程序，我們該對它說再見了。

由于數據超過了數據庫能夠處理的規模，NoSQL 技術就應運而生。這種新型的數據服務的興起解決了十年前它出現時網絡和數據快速增長的問題。NoSQL 還提供了冷存儲或批量訪問 PB 級數據的低成本的新途徑。然而，由于急于解決大數據和高并發的挑戰，NoSQL 放棄了數據庫的一些高性能和簡單易用的核心特性。

對大數據和高并發與高性能和易用性做出的權衡是 NoSQL 在數據庫領域做出的最大貢獻。將大數據和成熟的關系型結構和靈活性結合到一起，從而產生了一個可伸縮的關系數據庫，造就了一場變革。

關系型數據庫的發展創造了一個全新的系統，可以處理幾乎所有的任務，具有現代應用程序所需的可伸縮性、可靠性和可用性要求。隨著從傳統的工作任務（例如事務處理應用程序和業務分析）到更新的工作任務（例如多租戶服務和運營分析）的轉變，一些新興的數據庫如 Google Spanner、Azure 數據倉庫和 MemSQL 開始出現，證明了大多數情況下，關系型數據庫比 NoSQL 更容易使用且表現通常也更好一些。

我知道上述言論可能引起爭議。我也知道你可能會認為我的觀點富有偏見。但是請讓我介紹一下數據庫的歷史、架構和應用程序的相關知識，你再做出自己的判斷也不遲。

NoSQL 的崛起

盡管 NoSQL 在更早的時候就已經開始了，然而，直到在 21 世紀 10 年代中后期才全面發揮作用。它的出現主要是為了解決現有數據庫系統的規模問題。很明顯，對于構造大型系統來說，能夠橫向拓展更劃算。對于 Google、Facebook、微軟和雅虎等最大的電子郵件和搜索系統來說，這是唯一的擴展方式。

2007 年，當我閱讀詹姆斯·漢密爾頓 (James Hamilton) 關于設計和部署大規模互聯網服務的論文時[1]，我第一次懂得了擴展的價值。首先因為應用層無狀態的系統拓展起來更容易。拓展存儲層則不同。根據定義，數據庫是有狀態的，在分布式系統中維護狀態（ACID）非常困難。存儲層通常是基于現存的數據庫系統（如 MsSQL、SQL Server 等）來構造分布式存儲系統的。

當我在微軟的 SQL Server 團隊擔任產品經理時，我碰到了下面幾個例子。第一個例子發生在微軟內部，微軟在內部建立了 Webstore，它是 Hotmail 和相關服務使用的 SQL Server 之上的一個分片層。事實上，Webstore 是現在 Azure SQL 數據庫的前身。雖然 Webstore 很笨重，缺少很多核心功能，但是它很有效，并且給微軟提供了一種擴展到所需數據規模和實現高可用性的能力。但 Webstore 需要整個工程師團隊來構建和維護。

在 21 世紀 10 年代中期， MySpace 使用大量的 SQL Server 服務器來管理快速增長的數據。由于該公司的用戶增長非?？?#xff0c;導致該公司每天都要增加新的 SQL Server 機器。運行這些 SQL Server 服務器并且支持跨服務器查詢的工作非常復雜，需要大量的工程師來維護。

同樣的情況也出現在 Facebook 或其他企業的身上，因為所有新興科技巨頭都在不斷擴大規模，所以都面臨著相似的問題。

很明顯，隨著數據大規模的使用和增長，就需要新的數據解決方案來獲取、管理和查詢數據。理想情況下，我們需要一個可以提供接口并且可以通過加機器實現拓展性的工具。

最終，大規模的云服務（Google、 Facebook、雅虎、微軟等) 都建立了自己定制的系統來滿足這種數據需求。雖然這些系統各不相同，但是他們的思想都是通過直接的方式或者學術手段間接共享的。最終，開源系統開始借鑒這些思路，NoSQL 因此應運而生。

為了解決網絡規模問題，NoSQL 在一些關鍵方面和傳統的數據庫相背離。接下來讓我們看看它為什么要這么做。

最終一致性的表現和風險

ACID 代表原子性（Atomic）、一致性（ Consistent）、隔離性（Isolation）和持久性（Durable）。它涵蓋了大多數關系型數據庫的保證。ACID 保證了寫操作必須等數據落盤后才能給客戶端返回成功。另外，如果很在意持久性（即不丟失數據），那么可以將數據庫配置為等待，直到寫操作通過網路傳輸到其他機器，并且待對方落盤為止。這就保證了寫數據的正確性但是降低了寫數據的性能。

BASE 是 NoSQL 系統的典型特征，即基本可用（Basically Available）、軟狀態（Soft State）和最終一致性（Eventually Consistent）。因為程序不需要確認數據持久化完成，因此最終一致性寫的性能更高。一旦數據存儲設備接收到了一個寫操作，它就可以在持久化或送達其他機器之前告知應用程序此次寫操作已經成功，應用程序就可以執行下一個操作。雖然你獲得了寫性能的提高，但卻冒著看不到剛才寫入的數據和異常條件下數據可能完全丟失的風險。

最終一致性是持久化風險和可用性之間的合理權衡。如果你的業務是消費者參與，而延遲對你的收入有直接的影響 (對于所有的內容、社區和商業應用程序都是如此) ，那么你追求的是更快的響應速度。如果你必須要支持數百萬計的用戶并發，那么你就不能容忍任何瓶頸。如果偶爾丟失某人的帖子或評論這種風險是可以接受的話，就適合采用最終一致性的方案。

持久性與風險之間的另一面是金融應用程序。您不希望銀行使用最終的一致性來存儲 ATM 交易或股票銷售的結果。在這些情況下，您仍然讓用戶要求很少甚至沒有等待時間，但是不愿意接受未寫入磁盤的事務。

最終一致性占有一席之地，但是它不是唯一的解決方案。數據系統的架構師和開發人員應該根據實際需要選擇他們想要的一致性級別。這種選擇應該在用例級別而不應該在平臺級別進行。

無模式化

目前還不清楚為什么在 NoSQL 運動中丟失了模式。早期很難構造一個分布式元數據管理器來維護跨分布式系統的模式來操作，比如添加一列。因此，在早期設計中沒有使用模式也不足為奇。但是，模式沒有找到添加它的理由，被簡單地刪除掉了。很多人認為模式并沒有那么敏捷。好的模式設計非常困難，需要仔細斟酌。當事物快速發生變化時，你不希望被模式所束縛。

但這是一個謬論。

的確，缺乏模式增加了工程師開發的敏捷性。然而，它把這個問題推給了數據的讀者，這些讀者的數量通常更多，而且在寫數據時往往不知道數據的狀態。這些用戶通常需要重數據中挖掘價值，因此應該盡可能少地設置障礙。

打個比方，想象一下圖書館說他們正在廢除杜威十進制圖書分類法，只是把書扔到地上的一個大洞里，并宣稱這是一個更好的系統，因為它對圖書管理員來說工作量更少。對于半結構化數據有時間和地點屬性，因為有時你事先并不知道某些數據結構，或者它是否稀疏。但是，如果你不知道即將到來的數據的任何特征，那么有啥用呢？

事實上，模式總是存在的。這些數據對某些人來說總是有意義的。有些人應該花時間將知識編碼到一個平臺上，以便下一個人可以學習使用。如果這些數據是不易理解和快速變化數據的混合體，那么可以將易變的部分放到數據庫的半結構化的列中，然后確定以后可以映射到哪些列。15 年前 SQL Server 和 Oracle 就可以通過 XML 實現這個功能。其他現代數據庫也可以通過 JSON 數據來實現這種功能。文檔數據（鍵/值對）存儲是現代數據庫的一個特征，而不是唯一功能。

查詢的非 SQL 語法

在 NoSQL 數據庫設計中的這一決定遵循了無模式的原則。如果沒有模式，那么拋棄 SQL 語法更合理。此外，很難為單個機器構建查詢處理器，而構建分布式處理器則更難。最值得注意的是，如果你是一個開發者，想讓一個新的應用程序啟動并運行，基于 NoSQL 來構建系統會更容易。

MongoDB 在簡化安裝步驟和首次體驗方面做得非常完善。但事實證明，關系模型是非常強大的。如果想實現“獲取 id 為 2 的對象”這種功能，直接用 get 和 put 函數即可。但是大多數應用所需的并不止如此。如果你想學習一個使用 MongoDB 做了兩個項目的人的感悟，可以看看這篇文章。這篇文章解釋了文檔數據庫的不足[2]。

你總是希望以不同于存儲數據的方式來查詢數據。諷刺的是，為了解決這個問題，關系模型在 20 世紀 60 年代就被發明出來。一個具有連接功能的關系型數據庫是獲取數據的唯一方式。一開始比較困難，但總好于將所有的數據都加載到應用程序中自己去建立關聯。但我卻反復看到顧客一次一次在 NoSQL 中這么做，結果可想而知。

很多 NoSQL 系統實現了它們的目標。它們提供了具有統一接口的數據存儲，這些接口可以拓展到很多機器上實現高可用。雖然已經取得了諸多成功，但是 NoSQL 還是遇到了一些阻礙。

原因有很多。性能是其中一個關鍵因素，特別是在對任意類型的服務等級協議（SLA）進行分析查詢時?？芍卫硇允橇硗庖粋€原因，因為分布式系統本身就出名地難以治理。但是 NoSQL 的最大阻礙是需要對人員的重新培訓。在過去的 10 年里，NoSQL 一直在試圖改變世界，但是收效甚微。NoSQL 公司的只占 500 億美元數據庫市場份額的一小部分。

雖然軟件工程師似乎很喜歡 NoSQL，但數據人員（DBA、數據架構師和數據分析師）卻與之相反。因為這就意味著他們必須重新學習新的 API、工具和生態，意味著要拋棄多年來成功的方法、模式和經驗。他們希望使用經過驗證的模型來做事情，但是仍然可以在不妨害系統持久性、可用性和可靠性的情況下擴大規模。

從 NoSQL 到 NewSQL ——性能和規模無需妥協

當選擇使用 MemSQL 時，首先我們假定用戶喜歡關系型數據庫的功能，卻又想要拓展系統的可用性和可靠性。我們目標是兩全其美。

MemSQL 是一個分布式的關系型數據庫，支持交易和分析，并且支持硬件上的拓展。在 MemSQL 中，你可以看到熟悉的關系模型、SQL 查詢語法和龐大的工具生態系統。它支持可拓展性和可用性的現代、云原生的系統。

讓我們結合 NoSQL 系統的核心差異來重新審視這一點。

一致性和性能的平衡

MemSQL 提供了有一些“旋鈕”，可以在一致性和性能之間進行權衡。權衡不可避免，但是你不必在平臺級別對一致性和性能進行權衡，可以在用例級別對兩者進行選擇。

一致性和性能的選擇并不是一個哲學問題，而是要根據應用的實際情況和需求進行選擇。MemSQL 有兩個設置可以讓你調整。第一個是讓你決定是否要等待磁盤持久化。在事務被持久化到磁盤之前會存儲到內存的緩沖區中。你可以在成功訪問緩沖區或磁盤后立即返回數據。如果在到達緩沖區就返回，可能會在持久化之前機器發生故障或者重啟，那么數據就會丟失。另外一方面，如果等待數據持久化到磁盤就會耗費更多的時間。

此外，MemSQL 提供兩種復制模式來實現高可用，分別是同步復制和異步復制。通過復制確保一個機器上的數據在另外一臺機器上有副本。如果將復制設置為同步模式，則需要等到備份服務器上接收到事務后，才能將成功返回給客戶端。如果打開了異步復制模式，則在將數據復制到備份服務器之前，事務將返回成功。這為你提供了在一致性和性能之間進行權衡的機會。

圖：MemSQL 7.0 快速同步復制和同步持久化

分布式系統中模式的維護

MemSQL 通過在小型內部數據庫中存儲元數據，并在所有節點發生更改時同步復制元數據來實現模式。它使用兩階段提交來確保 DDL 更改可以正確地在集群中傳播，以一種不會導致查詢阻塞的方式實現。

MemSQL 不僅僅支持關系模型。您可以輸入一個 JSON 列，并在其中存儲到一個 JSON 文檔。如果你以后要查詢某一列，可以將該屬性映射為列并對其進行索引。MemSQL 還支持空間類型和全文索引。客戶需要在一個熟悉的系統中混合使用各種數據類型，并且所有類型的數據可以自然地共存。

保留 SQL“通用語言”

已經解決了在分布式數據庫中大規模使用 SQL 語法的問題。分布式查詢處理器允許您使用標準 SQL 語法表達查詢，系統負責將查詢任務分配到集群中的各個節點，并幫你匯總結果。MemSQL 支持所有常見的 ANSI SQL 操作符和函數。

MemSQL 通過系統中兩種類型的節點實現這種功能，匯聚器和葉子節點。聚合器處理分布式系統的元數據、路由查詢和聚合結果。葉子存儲數據，并在分區上執行繁重的查詢。如果可能 MemSQL 將在本地執行連接，這也說明了模式設計的重要性。如果不能，MemSQL 將根據需要對數據進行重組。因此，客戶可以在不知道數據是如何分區的情況下使用 SQL 語言。

圖：MemSQL 在聚集器和葉子節點分發數據

這意味著你可以利用你公司已有的技能、投資和工具使用 MemSQL。人們可以像使用其他關系數據庫一樣使用 MemSQL，而不需要再接受額外培訓。此外，由于 MemSQL 支持 MySQL 有線協議，現有的大規模商業智能（BI）、 ETL（數據抽取、轉換和加載） 和其他中間件工具都能與 MemSQL 一起協作。你不需要雇傭新的員工，學習一堆新的工具，或者引進新的軟件。只管用就可以了。

向 NoSQL 說再見！

NoSQL 的出現是為了滿足 Web 應用和多租戶服務的規模需求。想想解決這些問題的難度，就能理解為何早期他們在存儲層進行拓展時為何要迫使用戶進行艱難地權衡了。

但是關系型數據庫也已經有了長足的發展。它們可以處理幾乎所有的工作負載，可以滿足現代應用程序所需的可伸縮性、可靠性和可用性要求。

工作負載包含操作分析。當所有的公司意識到數據驅動的價值時，他們希望所有的員工都能獲得最新的數據。要做到這一點，需要一種新型的分析系統，它可以擴展到數百個并發查詢，不需要預先聚合就可以交付快速查詢，并且在創建數據時就可以提取數據。最重要的是，他們希望向客戶和合作伙伴公開數據，這需要一個可操作的服務等級協議（SLA）、安全性能、性能和規模，而目前的數據存儲是不可能的。這只是其中一個特性，實現了遺留數據庫和 NoSQL 系統所不能提供的新功能的需求。

關系模型經受住了時間的考驗，而且它還在不斷創新，比如 MemSQL SingleStore。此外，它還吸收了新的數據類型 (搜索、空間、半結構化等) 和一致性模型，使它們能夠在一個系統中共存。關系模型或 SQL 查詢語法沒有固有的可伸縮性挑戰。它只需要一個不同的存儲實現即可利用橫向擴展架構。

新的數據庫如 MemSQL 已經證明，對于大多數用例來說，關系數據庫更容易使用，并且通常比 NoSQL 系統執行得更好。

謝謝 NoSQL，是你對數據庫社區施加了壓力，迫使其解決云規模世界的各種挑戰。這招很管用。然而，關系型數據庫已經發展到可以滿足這些需求的地步，接下來交給我們吧。

[1] https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton_html/index.html

[2] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

英文：Thank You for Your Help NoSQL, but We Got It from Here

鏈接：https://www.memsql.com/blog/why-nosql-databases-wrong-tool-for-modern-application/

作者簡介：Rick Negrin。Rick 負責 MemSQL 的產品管理團隊，在微軟工作了 12 年，大部分時間在 SQL Server 團隊工作。

譯者：明明如月，知名互聯網公司 Java 高級開發工程師，CSDN 博客專家。

本文為 CSDN 翻譯，轉載請注明來源出處。

【End】

推薦閱讀?

?隔離是否有效？北大面向新冠疫情的數據可視化分析與模擬預測

?愛荷華大選 App 投票釀鬧劇的反思：為什么我們在軟件工程方面如此糟糕？

?一文告訴你，如何使用Python構建一個“谷歌搜索”系統 | 內附代碼

?愿得一心人：硅谷億萬富豪們的婚姻怎樣？有人白首相守七十年

?Python + ElasticSearch：有了這個超級武器，你也可以報名參加詩詞大會了！| 博文精選

?區塊鏈中的哈希到底是什么？

你點的每一個在看，我認真當成了喜歡

猛戳“閱讀原文”，填寫中國遠程辦公-調查問卷

---------------------
作者：CSDN資訊
來源：CSDN
原文：https://blog.csdn.net/csdnnews/article/details/104352146
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件

總結

以上是生活随笔為你收集整理的[转]再见 NoSQL！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。