NoSQL 已死：我們不需要他了
作者：Rick Negrin是MemSQL的產品管理團隊負責人，他在微軟工作過12年，曾是SQL Server團隊的成員。
是時候承認我們早就知道的一個事實了：NoSQL 是並不適合許多現代應用使用場景的工具，是我們該翻篇的時候了。
由於當時的資料庫無力處理所需的規模，NoSQL 技術應運而生。這種新一代數據服務的興起解決了十多年前它問世時互聯網規模和數據迅速增加帶來的許多問題。NoSQL 還為冷存儲/偶爾批量訪問PB級數據提供了一條經濟高效的新途徑。然而，因急於解決大數據和大量並發用戶帶來的難題，NoSQL 丟棄了資料庫的一些核心功能，而這些功能使得資料庫擁有高性能和易於使用的優點。
進行這番取捨也許是NoSQL為資料庫領域做出的最大貢獻。NoSQL掀起了一場變革，集最佳的大數據功能與成熟關係模型的結構和靈活性於一體，推出了一種易於擴展的關係資料庫。
關係資料庫不斷發展，打造了全新一代的系統，可處理幾乎所有的工作負載，滿足現代應用所需要的可擴展性、可靠性和可用性等要求。傳統的工作負載（比如事務應用和業務分析）轉向比較新的工作負載（比如多租戶服務和操作分析）。Google Spanner、Azure Data Warehouse和 MemSQL，這些新的資料庫大行其道證明了這點：對於大多數使用場景而言，關係資料庫比 NoSQL系統更易於使用，性能通常更勝一籌。
我知道這可能會引起爭議，也知道你可能立馬覺得我的觀點有偏見。不過容我仔細介紹一下這種資料庫的歷史、架構和應用，之後你自行判斷也不遲。
NoSQL的崛起
NoSQL 在2000年代末大放異彩，不過它很早就問世了。它的出現主要是為了解決現有資料庫系統的規模問題。很顯然，橫向擴展（scale out）對於構建大型系統而言是一種更經濟高效的模式。對於谷歌、Facebook、微軟和雅虎構建的超大電子郵件和搜索系統而言，這是擴展規模的唯一方式。
2007 年我讀了James Hamilton 介紹設計和部署大規模互聯網服務的一篇文章（https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton_html/index.html）後，首次認識到了橫向擴展的價值。先是擴展應用層，因為無狀態系統擴展起來比較容易。擴展存儲層是另一回事。根據定義，資料庫是有狀態的，跨分散式系維護該狀態的保證機制（即ACID）非常困難。於是在現有資料庫系統（比如MySQL和SQL Server 等）的上面構建層，以創建一個分散式存儲層。
我在微軟的 SQL Server 團隊擔任產品經理期間碰到過這方面的幾個例子。第一個例子出現在微軟內部：微軟構建了Webstore，這是 Hotmail及相關服務使用的SQL Server上面的分片層。實際上，Webstore是構建最終成為如今的Azure SQL Database的資料庫系統的動因。雖然Webstore笨拙，缺少許多核心功能，但它很管用，讓微軟既能夠針對所需的數據規模來擴展，又能夠獲得高可用性。但 Webstore 需要整個工程師團隊來構建和維護。
2000年代中期，MySpace使用大量的SQL Server伺服器來管理這個迅速壯大的網站。該公司的用戶增長非常快，每天需要增加新的SQL Server機器。運行所有這些SQL Server、並且跨這些系統進行查詢是一項非常複雜的工作，需要大批工程師來維護。
同樣的情況出現在了Facebook及其他公司，因為所有新興的科技巨頭都面臨擴展難題。
很顯然，由於用戶眾多、數據不斷增加，這些新的數字服務巨頭需要一種新的解決方案來獲取、管理和發掘數據。理想情況下，我們需要這樣的系統：可直接提供單一介面，但又能橫向擴展到許多機器上，並擁有內置的高可用性。
最終，大規模雲服務（谷歌、Facebook、雅虎和微軟等）都自行構建了定製的系統，以滿足規模擴展需求。那些系統各不相同，但採用了同樣的基本思路，有的直接共享，而有的通過學術共享。最終，採用這些同樣思路的開源系統開始湧現出來，NoSQL浪潮方興未艾。
為了解決互聯網規模問題，NoSQL在幾個關鍵方面有悖於傳統資料庫。接下來讓我們看看為什麼做出這些選擇。
最終一致性的性能和弊端
存儲系統有兩種模型：ACID和BASE。
ACID 代表原子性（Atomic）、一致性（Consistent）、隔離性（Isolation）和持久性（Durable）。它涵蓋了你從大多數關係資料庫獲得的保證。ACID 保證寫入操作必須等數據進入磁碟後才能向客戶端返回成功訊號。此外，如果你很在意持久性（即不丟失數據），你可以對資料庫進行配置，以便等到寫入操作通過網路傳輸到另外某台機器，數據同樣進入該機器的磁碟。因此保證了寫入數據的正確性，但降低了寫入速度方面的性能。
BASE是NoSQL系統所特有的，代表基本可用（Basically Available）、軟狀態（Soft State）和最終一致（Eventually Consistent）。由於應用程序不必等待查看寫入是否持久化，寫入時可更快地確保最終一致性。一旦數據存儲系統收到寫入操作，但在持久化到磁碟或另一個機器之前，它會告知應用程序寫入操作成功，應用程序可以進入到下一個操作。因此你獲得了性能方面的優勢，但面臨的風險是無法看到剛寫入的數據，或者數據在出錯情況下可能完全丟失。
最終一致性合理兼顧了持久性與可用性。如果貴公司與消費者互動，延遲對貴公司的收入又有直接影響（所有內容、社區和商業應用環境都面臨這個問題），你希望用戶界面（UI）有最快的響應速度。如果你要擴大規模以支持數百萬的並發用戶，就無法容忍任何瓶頸。資料庫架構中採用最終一致性帶來的缺點是偶爾丟失某人的帖子或評論，而這種風險對於這些類型的應用而言是可以接受的。
需要兼顧持久性與可用性的另一個例子是金融應用。你不希望銀行使用最終一致性來存儲 ATM交易或股票銷售的結果。在這種情況下，用戶仍要求延遲基本為零，而銀行又不願意接受未寫入到磁碟的交易。
最終一致性有一席之地，但並非始終是唯一的解決方案。數據系統的架構師和開發員應能夠選擇自己想要哪種級別的一致性。應在使用環境層面而不是在平台層面進行這種選擇。
走無模式道路
目前不清楚為什麼NoSQL潮流中不見資料庫模式（schema）的影子。是的，早期很難構建一個分散式元數據管理器以便跨分散式系統來維護模式以支持操作，比如添加列。因此，早期設計沒有模式不足為奇。但最終完全消除了模式，而不是後來設法添加模式。有人認為模式會降低敏捷性，這也可以理解。好的模式設計很困難，需要事先認真思考。情況迅速變化時，你不希望被模式所束縛。
但這是一個謬論。
誠然，沒有模式為負責將數據錄入到系統的工程師增強了敏捷性。然而，它把這個問題推給了數據的讀取者（即用戶），而用戶的數量通常高出一個數量級，而且數據寫入時常常不了解數據的狀態。這些用戶通常從數據中創造價值，因此應面臨盡量少的障礙。
打個比方，設想一下圖書館聲稱廢除杜威十進分類法，只是把書扔到地上的一個大洞里，聲稱這是一種更好的分類法，因為圖書管理員要做的工作量少得多。半結構化數據有時間和地點屬性，因為有時你事先不知道一些數據的結構，或者它是否稀疏。但如果你真的不知道任何進來的數據或數據是什麼樣子，那麼數據又有何啥用？
事實上，模式總是存在。數據對某人來說始終有意義。此人應該花時間將該數據編碼到一個平台上，以便下一個人可以使用。如果數據混合已了解的數據和迅速變化的數據，那麼將後者放到資料庫中的半結構化列，然後搞清楚以後從中映射哪些列。15 年前，SQL Server和Oracle可以對XML執行這項任務。MemSQL及其他許多現代資料庫現在可以對JSON數據執行這項任務。文檔數據存儲（以及鍵/值）應該是現代資料庫的一項特性，而不是產品的唯一功能。
面向查詢的非SQL語法
NoSQL資料庫設計中的這個決定遵循了無模式化原則。如果你沒有模式，那麼丟棄SQL語法還算合理。此外，很難為單單一種設備構建查詢處理器，而構建分散式查詢處理器難得多。尤其是，如果你是開發員，想讓一個新的應用程序啟動並運行起來，這種系統讓人覺得更容易。
MongoDB 在簡單安裝和首次體驗方面做得堪稱完美。但結果證明，關係模型非常強大。如果你根本不想回答「獲取id是2的對象」之外的任何問題，單單有get和put函數就行。但是外頭大多數應用程序到頭來需要的不止如此。這篇文章解釋了文檔資料庫的不足之處。
在稍複雜一點的任何系統，你總是希望以不同於存儲數據的方式來查詢數據。具有諷刺意味的是，20世紀60年代發明了關係模型，就是為了解那個年代的數據存儲系統（IMS和Codasyl）存在的這個問題。擁有連接（join）功能的關係資料庫是取出數據的唯一合理方式。是的，一開始比較難，但比將所有數據都獲取到你的應用程序中、自行創建連接容易得多。我看到客戶一次次地對NoSQL這麼做，結果總是讓人抓狂。
許多這些NoSQL系統實現了主要目標。它們提供了單一介面的數據存儲系統，可以橫向擴展到許多機器上，擁有內置高可用性。雖然已取得了一定的成功，但NoSQL的採用還是遇到了阻礙。
這有幾個原因。性能是關鍵因素，尤其是在有服務級別協議（SLA）的情況下進行分析查詢時。可管理性是另一個原因，因為分散式系統管理起來特別難。但是阻礙NoSQL採用的最主要因素還是需要對人員重新培訓。許多人原先接受的是關係資料庫方面的培訓和教育。在過去這10年，NoSQL一直試圖讓關係資料庫人員改弦易轍，但收效甚微。所有NoSQL公司在產值500億美元的資料庫總共也僅佔一小部分的市場份額。
雖然軟體工程師似乎喜歡NoSQL，但數據人員（資料庫管理員、數據架構師和分析員）老大不情願地進入NoSQL領域；想實現必要的規模，NoSQL又似乎是唯一的途徑。而這意味著他們要重新學習新的API、工具和生態系統，扔掉多年來積累的成功方法、模式和資產。他們希望使用一種成熟的模型來做事情，希望在不影響系統持久性、可用性和可靠性的情況下仍可以擴大規模。
從NoSQL到NewSQL ——確保性能和規模，又沒有弊端
我們構建MemSQL時，假設客戶喜歡關係資料庫的功能，又想要橫向擴展型系統的可用性和可靠性。我們的目標是讓客戶可以兩全其美。
MemSQL是一種支持事務和分析的分散式關係資料庫，可在商用硬體上橫向擴展。你可以獲得熟悉的關係模型、SQL 查詢語法和龐大的工具生態系統，以及現代雲原生系統的擴展性和可用性。
不妨對照一下NoSQL 系統的核心差異。
兼顧一致性和性能
MemSQL有一些旋鈕（knob），讓你可以在一致和性能之間進行適當的兼顧。這種取捨始終不可避免，但如今你不必在平台層面在這兩者進行選擇。你可以為合適的每個使用場景來進行選擇。
一致性vs性能並不是某個棘手的哲學命題，關鍵是哪個對你的應用和需求更重要。MemSQL有兩個設置可以讓你對此進行調整。第一個設置讓你可以決定是否等待磁碟持久化。有一個內存中緩衝區，可以在事務被持久化到磁碟之前存儲事務。可以在數據一進入緩衝區就返回成功訊號，也可以在數據進入磁碟後返回成功訊號。如果進入緩衝區就返回，可能會在持久化之前出現機器故障或重啟，數據就會丟失。另一方面，等待數據持久化到磁碟要花更長的時間。
此外，如果是高可用性環境，有兩種複製模式：同步複製和非同步複製，確保數據在另一台機器上有第二個副本。如果你將複製設置為同步模式，你要等到輔助機器上收到事務後，才能將成功訊號返回給客戶端。如果使用非同步複製模式，事務返回成功訊號之後，數據複製到輔助機器。這讓你能夠調整一致性和持久性，以獲得適合你風險/性能具體要求的性能。
MemSQL 7.0包括快速同步複製和同步持久性
保持分散式系統中的模式
MemSQL實現模式的方式是，將元數據存儲在小型內部資料庫中，元數據更改時就將元數據同步複製到所有節點。它使用兩階段提交來確保DDL更改在集群中正確地傳播，以一種不會阻塞選擇性查詢的方式來構建。
不過MemSQL不僅僅支持關係模型。你可以輸入一個列作為JSON列，並存儲一個JSON 文檔。如果你覺得以後想要查詢幾個列，可以將屬性映射為列，並編製索引。MemSQL還支持空間類型和全文索引。我們明白，客戶需要在一個熟悉的系統中有混合類型的數據，所有類型的數據都能自然地共存。
保留SQL「通用語」
MemSQL解決了在大規模環境下跨分散式資料庫使用SQL語法的問題。分散式查詢處理器讓你可以使用標準SQL語法來表達查詢，系統負責將查詢任務分配到集群中的各節點，並幫你匯總結果。MemSQL支持所有常見的ANSI SQL操作符和函數，它們為你提供了可表達幾乎任何查詢的強大模型。
MemSQL通過系統中兩種類型的節點：匯聚器（aggregator）和葉子（leaf）來做到這一點。匯聚器節點處理分散式系統的元數據、路由查詢和聚合結果。葉子節點存儲數據，並處理在分區上執行查詢這項繁重任務。如果可以，MemSQL會在本地執行連接，這表明了為何模式設計相當重要。如果不行，MemSQL將根據需要轉移數據。因此，客戶可以在不知道數據在底層如何分區的情況下使用SQL語言。
MemSQL跨匯聚器節點和葉子節點分發數據
這意味著藉助MemSQL，你可以利用貴公司已有的技能、資源和工具，或者人們可以像使用其他關係資料庫那樣使用 MemSQL，不需要重新培訓。此外，由於MemSQL支持MySQL連線協議，現有的龐大生態系統（包括BI、ETL及其他中間件工具）完全與MemSQL兼容。你沒必要僱用新的員工、學習一堆新工具或者引進新軟體。只管用就行。
向NoSQL說再見！
由於Web應用和多租戶服務大行其道，NoSQL應運而生，以滿足規模需求。想想解決這些問題的難度，就可以理解早期試圖在存儲層處理規模擴展的舉措為何迫使用戶作出艱難的取捨。
但關係資料庫迎來了發展。它們可以處理幾乎所有的工作負載，滿足現代應用程序所需的可擴展性、可靠性和可用性等要求。
由於所有公司意識到數據驅動的價值，它們希望所有員工都能獲得最新的數據。為此，需要一種新的分析系統，可以擴展規模以支持成百上千的並發查詢、不需要預先聚合就可以快速查詢，並且在數據創建時實時獲取數據。除此之外，它們希望向客戶和合作夥伴敞開數據，這需要切實可行的SLA、安全功能、性能和規模，而目前的數據存儲系統卻滿足不了這個要求。幾種新的工作負載促使企業需要遺留資料庫和NoSQL系統無力提供的新功能，操作分析之類的工作負載只是其中之一。
關係模型經受住了時間的考驗，它在不斷添加新的創新。此外，它吸納了新的數據類型 （搜索、空間和半結構化數據等）和一致性模型，那樣各種數據就可以在一個系統中共存。關係模型或SQL查詢語法沒有固有的可擴展性難題。它只要不同的存儲實現方法，就可以充分利用橫向擴展型架構。
MemSQL等新的資料庫已證明，對於大多數使用場景而言，關係資料庫更容易使用，通常性能比NoSQL系統更勝一籌。
謝謝你，NoSQL。你對資料庫社區施加了壓力，迫使社區解決雲規模領域的難題。NoSQL很管用。然而，關係資料庫取得了發展，可以滿足那些要求。我們已進入到下一個階段。
