計世網

數據庫激蕩 40 年,NoSQL、NewSQL誰能接棒?
作者:Andrew C. Oliver | 來源:計算機世界
2020-09-04
如果關系數據庫的主要問題是后端而不是前端,將會怎么樣?

 


  起初有文件,后來有基于結構化文件的導航數據庫,然后出現了IMS和CODASYL。大概40年前,出現了首批關系數據庫。在20世紀八、九十年代的大部分時間,“數據庫”嚴格意義上指“關系數據庫”。SQL(標準查詢語言)占主導地位。

  后來隨著面向對象編程語言日益流行,一些人認為,解決面向對象語言和關系數據庫“阻抗不匹配”的辦法是在數據庫中映射對象。因此,我們最后迎來了“面向對象的數據庫”。對象數據庫方面有意思的地方是,在許多情況下,它們基本上是內置對象映射器的普通數據庫。這種數據庫后來漸漸失寵,下一個真正的主流嘗試是2010年代的“NoSQL”。

  攻擊SQL

  NoSQL以同樣的方式攻擊關系數據庫和SQL。這回的主要問題是,互聯網顛覆了具有40年歷史關系數據庫管理系統(RDBMS)架構的基本前提。這種數據庫旨在節省寶貴的磁盤空間,并可縱向擴展。然而現在有太多的用戶和太多的任務,一臺胖服務器處理不了。NoSQL數據庫則宣稱,如果數據庫沒有連接(join),沒有標準查詢語言(因為實現SQL需要花費時間),也沒有數據完整性,那么就可以橫向擴展以處理眾多用戶。這解決了縱向擴展的問題,但也帶來了新問題。

  與這些聯機交易處理系統(OLTP)并行開發的是另一種關系數據庫,名為聯機分析處理系統(OLAP)。這種數據庫支持關系結構,但在執行查詢時就知道它們將返回大量數據。上世紀八、九十年代的公司企業仍主要由批處理驅動。此外,OLAP系統為開發和分析人員提供了將數據想象成n維數據集并加以存儲的能力。如果你設想二維數組和基于兩個索引的查詢,以便基本上與恒定時間一樣高效,但是隨后在此基礎上添加另一個維度,以便可以執行實質上是3個或更多因素(比如供應、需求和競爭對手數量)的查詢,你就可以更高效地分析和預測。然而,構建這些元素是一項費力又高度面向批處理的工作。

  圖形數據庫幾乎與橫向擴展型NoSQL同一時間面市。許多事物本身不是“關系型”,或者不是基于集合論和關系代數,而是基于父子關系或朋友的朋友關系。一個典例是模型中的產品系列-產品品牌-款型-部件。如果你想知道“我的筆記本電腦搭載什么主板?”,會發現制造商的采購來源很復雜,光有品牌或型號可能不夠。如果你想知道某產品系列中使用的所有主板,在經典(非CTE即通用表表達式)SQL中,你必須遍歷表,并且分多個步驟進行查詢。最初,大多數圖形數據庫根本就不分片。實際上,無需將數據實際存儲為圖形,就能完成許多類型的圖形分析。

  兌現和未兌現的NoSQL承諾

  NoSQL數據庫的擴展性確實比Oracle數據庫、DB2或SQL Server(它們都基于40年前的一種設計)好得多。然而,每種NoSQL數據庫都存在新的限制:

  鍵值存儲:沒有比db.get(鍵)更簡單的查詢了。然而,世界上許多數據和使用場景無法以這種方式來設計結構。此外,我們其實在談論緩存策略。在任何數據庫中,主鍵查詢速度很快。重要的只是內存中的數據。在理想情況下,它們像哈希圖一樣擴展。然而,如果要跑30趟數據庫才能將數據放回去或進行任何類型的復雜查詢,這行不通。這些系統現在更常作為緩存實施在其他數據庫的前面。(例子:Redis。)

  文檔數據庫:這種數據庫之所以流行起來,是由于它們使用JSON,對象又易于序列化成JSON。這種數據庫的第一個版本沒有連接,將整個“實體”放到一個龐大的文檔中有其自身的缺點。沒有事務保證,你還會遇到數據完整性問題。今天,一些文檔數據庫支持一種不太可靠的事務,但它不是大多數人習慣的同一種保護級別。而且,即使對簡單查詢而言,這種數據庫在延遲方面常常速度很慢,盡管它們就吞吐量而言擴展性更好。(例子:MongoDB和Amazon DocumentDB。)

  列存儲:這種數據庫的查詢速度與鍵值存儲一樣快,它們可以存儲更復雜的數據結構。然而,如果執行像跨3個表(RDBMS術語)或3個集合(MongoDB術語)連接這樣的操作,會讓人痛苦不堪。這種數據庫確實適合時間序列數據(請給我在下午1點至2點出現的所有事務)。

  還有其他更深奧的NoSQL數據庫。然而,所有這些數據庫的共同點是不支持通用數據庫慣用語,而且往往專注于“特殊用途”。一些流行的NoSQL數據庫(比如MongoDB)編寫了出色的數據庫前端和生態系統工具,因而開發人員很容易采用它們,但存儲引擎存在嚴重的限制,更不用說彈性和可擴展性方面的限制了。

  數據庫標準仍然很重要

  關系數據庫占主導地位的原因之一是,它們有一個通用的工具生態系統。首先有SQL。雖然數據庫方言可能不一樣——如果你是開發或分析人員,想從SQL Server 6.5升級到Oracle 7,可能不得不修復查詢,并使用“(+)”用于外部連接,但是簡單的切實可行,復雜的很容易轉換。

  其次,你有ODBC以及后來的JDBC等。幾乎任何可以連接到一個RDBMS的工具(除非為了管理該RDBMS而專門設計)都可以連接到其他任何RDBMS。有許多人每天連接到RDBMS,并將數據倒入到Excel以便分析。我不是指Tableau或其他數百種工具,而是指“鼻祖”Excel。

  NoSQL擯棄了標準。MongoDB不使用SQL作為主要語言。MongoDB的勁敵Couchbase尋找一種查詢語言來取代基于Java的mapreduce框架時,更是創建了一套自己的SQL方言。

  標準很重要,無論是為了支持工具生態系統,還是由于許多查詢數據庫的人不是開發人員——他們都知道SQL。

  GraphQL和狀態管理的興起

  你知道誰總是翹著兩個大拇指想搭車,就想讓他的應用進入到數據庫里,但卻不關心如何實現嗎?事實證明,整整一代的開發人員都想這么做。而GraphQL(與圖形數據庫無關)可將對象圖形存儲在底層數據存儲系統中。這樣一來,開發人員就不必擔心這個問題了。

  這方面的早期嘗試是對象關系映射(ORM)工具,比如Hibernate。它們拿來一個對象后,基于對象到表的映射設置,基本上將對象變成了SQL。這種工具的許多前幾代產品很難配置。此外,我們面臨學習過程。

  大多數GraphQL實現方法與Sequelize或TypeORM之類的對象關系映射工具兼容。結構良好的GraphQL實現方法和API不會在你的全部代碼中泄露狀態管理問題,而是在對象圖形發生變化時寫入并返回相關數據。誰會在應用層面真正關心數據是如何存儲的?

  面向對象數據庫和NoSQL數據庫的基礎之一是,應用開發人員要意識到數據在數據庫中如何存儲方面的復雜情況。當然,這對于開發人員來說很難用較新穎的技術來駕馭,但現在不再困難了,因為GraphQL完全消除了這個問題。

  NewSQL或分布式SQL閃亮登場

  谷歌遇到了數據庫問題,寫了一篇論文,然后編寫了一種名為“Spanner”的實現方法,描述了全局分布式關系數據庫如何行得通。Spanner引發關系數據庫技術領域迎來了新一波創新。你實際上可以有一個關系數據庫,不僅讓它能擴展,還能在需要時進行全球范圍擴展。我們所談論的是現代意義上的大規模,而不是經常令人失望且日趨復雜的RAC/Streams/GoldenGate方法。

  所以,關系系統中“存儲對象”的前提是錯誤的。如果關系數據庫的主要問題是后端而不是前端,將會怎么樣?這就是所謂的“NewSQL”或名稱更恰當的“分布式SQL”數據庫背后的想法。其想法就是將NoSQL存儲知識和谷歌的Spanner概念與一種成熟的開源RDBMS前端(比如PostgreSQL或MySQL/MariaDB)結合起來。

  這意味著什么?這意味著魚和熊掌可以兼得。這意味著你可以有多個節點,并橫向擴展——包括跨云可用區擴展。這意味著你可以有多個數據中心或云地理區域——僅用一個數據庫。這意味著作為用戶,你可以擁有真正的可靠性和永遠不會崩潰的數據庫集群。

  與此同時,整個SQL生態系統仍有用!你無需重新構建整個IT基礎架構就能做到這點。雖然你可能不敢“丟棄并更換”傳統的RDBMS,但大多數企業并不打算使用更多的Oracle。最棒的是,你仍可以使用在云端和全球各地的SQL及所有工具。

作者:本文作者Andrew C. Oliver是開源分布式SQL數據庫技術提供商Yugabyte的產品營銷高級主管。
編譯:沈建苗
原文網址:https://www.infoworld.com/article/3564543/beyond-nosql-the-case-for-distributed-sql.html

責任編輯:??伸?/span>

棋牌游戏为什么提现不出来 贵州11选5前三直推荐 天津11选五开奖走势 福利彩票综合分布图 甘肃11任选五最大遗漏 重庆快乐十分奖金 安徽体彩十一选五基本走势图 股票指数投资策略主要包括完全复制法 2020精选六肖中特 辽宁11选五前三组走势图 天津体育彩票十一选五