起初有文件，后來(lái)有基于結(jié)構(gòu)化文件的導(dǎo)航數(shù)據(jù)庫(kù)，然后出現(xiàn)了IMS和CODASYL。大概40年前，出現(xiàn)了首批關(guān)系數(shù)據(jù)庫(kù)。在20世紀(jì)八、九十年代的大部分時(shí)間，“數(shù)據(jù)庫(kù)”嚴(yán)格意義上指“關(guān)系數(shù)據(jù)庫(kù)”——SQL（標(biāo)準(zhǔn)查詢語(yǔ)言）占主導(dǎo)地位。

后來(lái)隨著面向?qū)ο?a href="http://m.1cnz.cn/v/tag/1315/" target="_blank">編程語(yǔ)言日益流行，一些人認(rèn)為，解決面向?qū)ο笳Z(yǔ)言和關(guān)系數(shù)據(jù)庫(kù)“阻抗不匹配”的辦法是在數(shù)據(jù)庫(kù)中映射對(duì)象。因此，我們最后迎來(lái)了“面向?qū)ο蟮臄?shù)據(jù)庫(kù)”。對(duì)象數(shù)據(jù)庫(kù)方面有意思的地方是，在許多情況下，它們基本上是內(nèi)置對(duì)象映射器的普通數(shù)據(jù)庫(kù)。這種數(shù)據(jù)庫(kù)后來(lái)漸漸失寵，下一個(gè)真正的主流嘗試是2010年代的“NoSQL”。

1. 攻擊SQL

NoSQL以同樣的方式攻擊關(guān)系數(shù)據(jù)庫(kù)和SQL。這回的主要問(wèn)題是，互聯(lián)網(wǎng)顛覆了具有40年歷史關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)（RDBMS）架構(gòu)的基本前提。這種數(shù)據(jù)庫(kù)旨在節(jié)省寶貴的磁盤(pán)空間，并可縱向擴(kuò)展。然而現(xiàn)在有太多的用戶和太多的任務(wù)，一臺(tái)胖服務(wù)器處理不了。NoSQL數(shù)據(jù)庫(kù)則宣稱，如果數(shù)據(jù)庫(kù)沒(méi)有連接（join），沒(méi)有標(biāo)準(zhǔn)查詢語(yǔ)言（因?yàn)閷?shí)現(xiàn)SQL需要花費(fèi)時(shí)間），也沒(méi)有數(shù)據(jù)完整性，那么就可以橫向擴(kuò)展以處理眾多用戶。這解決了縱向擴(kuò)展的問(wèn)題，但也帶來(lái)了新問(wèn)題。

與這些聯(lián)機(jī)交易處理系統(tǒng)（OLTP）并行開(kāi)發(fā)的是另一種關(guān)系數(shù)據(jù)庫(kù)，名為聯(lián)機(jī)分析處理系統(tǒng)（OLAP）。這種數(shù)據(jù)庫(kù)支持關(guān)系結(jié)構(gòu)，但在執(zhí)行查詢時(shí)就知道它們將返回大量數(shù)據(jù)。上世紀(jì)八、九十年代的公司企業(yè)仍主要由批處理驅(qū)動(dòng)。此外，OLAP系統(tǒng)為開(kāi)發(fā)和分析人員提供了將數(shù)據(jù)想象成n維數(shù)據(jù)集并加以存儲(chǔ)的能力。如果你設(shè)想二維數(shù)組和基于兩個(gè)索引的查詢，以便基本上與恒定時(shí)間一樣高效，但是隨后在此基礎(chǔ)上添加另一個(gè)維度，以便可以執(zhí)行實(shí)質(zhì)上是3個(gè)或更多因素（比如供應(yīng)、需求和競(jìng)爭(zhēng)對(duì)手?jǐn)?shù)量）的查詢，你就可以更高效地分析和預(yù)測(cè)。然而，構(gòu)建這些元素是一項(xiàng)費(fèi)力又高度面向批處理的工作。

圖形數(shù)據(jù)庫(kù)幾乎與橫向擴(kuò)展型NoSQL同一時(shí)間面市。許多事物本身不是“關(guān)系型”，或者不是基于集合論和關(guān)系代數(shù)，而是基于父子關(guān)系或朋友的朋友關(guān)系。一個(gè)典例是模型中的產(chǎn)品系列-產(chǎn)品品牌-款型-部件。如果你想知道“我的筆記本電腦搭載什么主板？”，會(huì)發(fā)現(xiàn)制造商的采購(gòu)來(lái)源很復(fù)雜，光有品牌或型號(hào)可能不夠。如果你想知道某產(chǎn)品系列中使用的所有主板，在經(jīng)典（非CTE即通用表表達(dá)式）SQL中，你必須遍歷表，并且分多個(gè)步驟進(jìn)行查詢。最初，大多數(shù)圖形數(shù)據(jù)庫(kù)根本就不分片。實(shí)際上，無(wú)需將數(shù)據(jù)實(shí)際存儲(chǔ)為圖形，就能完成許多類型的圖形分析。

2. 兌現(xiàn)和未兌現(xiàn)的NoSQL承諾

NoSQL數(shù)據(jù)庫(kù)的擴(kuò)展性確實(shí)比Oracle數(shù)據(jù)庫(kù)、DB2或SQL Server（它們都基于40年前的一種設(shè)計(jì)）好得多。然而，每種NoSQL數(shù)據(jù)庫(kù)都存在新的限制：

（1） 鍵值存儲(chǔ) ·

沒(méi)有比db.get（鍵）更簡(jiǎn)單的查詢了。然而，世界上許多數(shù)據(jù)和使用場(chǎng)景無(wú)法以這種方式來(lái)設(shè)計(jì)結(jié)構(gòu)。此外，我們其實(shí)在談?wù)摼彺娌呗浴Ｔ谌魏螖?shù)據(jù)庫(kù)中，主鍵查詢速度很快。重要的只是內(nèi)存中的數(shù)據(jù)。在理想情況下，它們像哈希圖一樣擴(kuò)展。然而，如果要跑30趟數(shù)據(jù)庫(kù)才能將數(shù)據(jù)放回去或進(jìn)行任何類型的復(fù)雜查詢，這行不通。這些系統(tǒng)現(xiàn)在更常作為緩存實(shí)施在其他數(shù)據(jù)庫(kù)的前面。（例子：Redis。）

（2） 文檔數(shù)據(jù)庫(kù) ·

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

（3） 列存儲(chǔ) ·

這種數(shù)據(jù)庫(kù)的查詢速度與鍵值存儲(chǔ)一樣快，它們可以存儲(chǔ)更復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。然而，如果執(zhí)行像跨3個(gè)表（RDBMS術(shù)語(yǔ)）或3個(gè)集合（MongoDB術(shù)語(yǔ)）連接這樣的操作，會(huì)讓人痛苦不堪。這種數(shù)據(jù)庫(kù)確實(shí)適合時(shí)間序列數(shù)據(jù)（請(qǐng)給我在下午1點(diǎn)至2點(diǎn)出現(xiàn)的所有事務(wù)）。

還有其他更深?yuàn)W的NoSQL數(shù)據(jù)庫(kù)。然而，所有這些數(shù)據(jù)庫(kù)的共同點(diǎn)是不支持通用數(shù)據(jù)庫(kù)慣用語(yǔ)，而且往往專注于“特殊用途”。一些流行的NoSQL數(shù)據(jù)庫(kù)（比如MongoDB）編寫(xiě)了出色的數(shù)據(jù)庫(kù)前端和生態(tài)系統(tǒng)工具，因而開(kāi)發(fā)人員很容易采用它們，但存儲(chǔ)引擎存在嚴(yán)重的限制，更不用說(shuō)彈性和可擴(kuò)展性方面的限制了。

3. 數(shù)據(jù)庫(kù)標(biāo)準(zhǔn)仍然很重要

關(guān)系數(shù)據(jù)庫(kù)占主導(dǎo)地位的原因之一是，它們有一個(gè)通用的工具生態(tài)系統(tǒng)。首先有SQL。雖然數(shù)據(jù)庫(kù)方言可能不一樣——如果你是開(kāi)發(fā)或分析人員，想從SQL Server 6.5升級(jí)到Oracle 7，可能不得不修復(fù)查詢，并使用“（+）”用于外部連接，但是簡(jiǎn)單的切實(shí)可行，復(fù)雜的很容易轉(zhuǎn)換。

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

NoSQL擯棄了標(biāo)準(zhǔn)。MongoDB不使用SQL作為主要語(yǔ)言。MongoDB的勁敵Couchbase尋找一種查詢語(yǔ)言來(lái)取代基于Java的mapreduce框架時(shí)，更是創(chuàng)建了一套自己的SQL方言。

標(biāo)準(zhǔn)很重要，無(wú)論是為了支持工具生態(tài)系統(tǒng)，還是由于許多查詢數(shù)據(jù)庫(kù)的人不是開(kāi)發(fā)人員——他們都知道SQL。

4. GraphQL和狀態(tài)管理的興起

你知道誰(shuí)總是翹著兩個(gè)大拇指想搭車(chē)，就想讓他的應(yīng)用進(jìn)入到數(shù)據(jù)庫(kù)里，但卻不關(guān)心如何實(shí)現(xiàn)嗎？事實(shí)證明，整整一代的開(kāi)發(fā)人員都想這么做。而GraphQL（與圖形數(shù)據(jù)庫(kù)無(wú)關(guān)）可將對(duì)象圖形存儲(chǔ)在底層數(shù)據(jù)存儲(chǔ)系統(tǒng)中。這樣一來(lái)，開(kāi)發(fā)人員就不必?fù)?dān)心這個(gè)問(wèn)題了。

這方面的早期嘗試是對(duì)象關(guān)系映射（ORM）工具，比如Hibernate。它們拿來(lái)一個(gè)對(duì)象后，基于對(duì)象到表的映射設(shè)置，基本上將對(duì)象變成了SQL。這種工具的許多前幾代產(chǎn)品很難配置。此外，我們面臨學(xué)習(xí)過(guò)程。

大多數(shù)GraphQL實(shí)現(xiàn)方法與Sequelize或TypeORM之類的對(duì)象關(guān)系映射工具兼容。結(jié)構(gòu)良好的GraphQL實(shí)現(xiàn)方法和API不會(huì)在你的全部代碼中泄露狀態(tài)管理問(wèn)題，而是在對(duì)象圖形發(fā)生變化時(shí)寫(xiě)入并返回相關(guān)數(shù)據(jù)。誰(shuí)會(huì)在應(yīng)用層面真正關(guān)心數(shù)據(jù)是如何存儲(chǔ)的？

面向?qū)ο髷?shù)據(jù)庫(kù)和NoSQL數(shù)據(jù)庫(kù)的基礎(chǔ)之一是，應(yīng)用開(kāi)發(fā)人員要意識(shí)到數(shù)據(jù)在數(shù)據(jù)庫(kù)中如何存儲(chǔ)方面的復(fù)雜情況。當(dāng)然，這對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)很難用較新穎的技術(shù)來(lái)駕馭，但現(xiàn)在不再困難了，因?yàn)镚raphQL完全消除了這個(gè)問(wèn)題

5. NewSQL或分布式SQL閃亮登場(chǎng)

谷歌遇到了數(shù)據(jù)庫(kù)問(wèn)題，寫(xiě)了一篇論文，然后編寫(xiě)了一種名為“Spanner”的實(shí)現(xiàn)方法，描述了全局分布式關(guān)系數(shù)據(jù)庫(kù)如何行得通。Spanner引發(fā)關(guān)系數(shù)據(jù)庫(kù)技術(shù)領(lǐng)域迎來(lái)了新一波創(chuàng)新。你實(shí)際上可以有一個(gè)關(guān)系數(shù)據(jù)庫(kù)，不僅讓它能擴(kuò)展，還能在需要時(shí)進(jìn)行全球范圍擴(kuò)展。我們所談?wù)摰氖乾F(xiàn)代意義上的大規(guī)模，而不是經(jīng)常令人失望且日趨復(fù)雜的RAC/Streams/GoldenGate方法。

所以，關(guān)系系統(tǒng)中“存儲(chǔ)對(duì)象”的前提是錯(cuò)誤的。如果關(guān)系數(shù)據(jù)庫(kù)的主要問(wèn)題是后端而不是前端，將會(huì)怎么樣？這就是所謂的“NewSQL”或名稱更恰當(dāng)?shù)摹胺植际絊QL”數(shù)據(jù)庫(kù)背后的想法。其想法就是將NoSQL存儲(chǔ)知識(shí)和谷歌的Spanner概念與一種成熟的開(kāi)源RDBMS前端（比如PostgreSQL或MySQL/MariaDB）結(jié)合起來(lái)。

這意味著什么？這意味著魚(yú)和熊掌可以兼得。這意味著你可以有多個(gè)節(jié)點(diǎn)，并橫向擴(kuò)展——包括跨云可用區(qū)擴(kuò)展。這意味著你可以有多個(gè)數(shù)據(jù)中心或云地理區(qū)域——僅用一個(gè)數(shù)據(jù)庫(kù)。這意味著作為用戶，你可以擁有真正的可靠性和永遠(yuǎn)不會(huì)崩潰的數(shù)據(jù)庫(kù)集群。

與此同時(shí)，整個(gè)SQL生態(tài)系統(tǒng)仍有用！你無(wú)需重新構(gòu)建整個(gè)IT基礎(chǔ)架構(gòu)就能做到這點(diǎn)。雖然你可能不敢“丟棄并更換”傳統(tǒng)的RDBMS，但大多數(shù)企業(yè)并不打算使用更多的Oracle。最棒的是，你仍可以使用在云端和全球各地的SQL及所有工具。
責(zé)編AJX