對話阿里雲智能數據庫事業部總負責人李飛飛：雲數據庫戰爭已經進入下半場

李飛飛，現任阿里巴巴集團副總裁、高級研究員，阿里雲智能數據庫事業部總負責人。加入阿里巴巴以前爲美國猶他大學計算機系終身教授。研究成果屢次得到了IEEE ICDE、ACM SIGMOD最佳論文獎等重要學術獎項。

2018年，李飛飛加入阿里巴巴達摩院，帶領團隊投入到具備自主知識產權的研究當中。目前，帶領的阿里雲智能數據庫事業部所研發的新一代分佈式數據庫系統，支撐了阿里巴巴集團的複雜業務、海量數據和雙11交易洪峯的挑戰，已經被應用於多個城市的智能城市交通網絡管理，並服務了金融、零售、物流、製造等行業企業。

2018年，阿里雲數據庫成功進入Gartner數據庫魔力象限，這是該榜單首次出現中國公司，近日，阿里雲數據庫再次入選Forrester數據庫評估報告，成爲國內首個得到兩大頂級機構承認的科技公司。

2019年5月10日，DTCC 2019(第十屆中國數據庫技術大會)在北京舉辦，李飛飛來到現場發表了精彩的主題演講，並在大會期間接受了IT168&ITPUB執行總編老魚的深度專訪，衆多獨特觀點精彩紛呈。

透露兩條信息：

一、PolarDB從去年10月開始商業化到目前，已經成爲阿里雲上增加最快的數據庫產品；

二、AnalyticDB已經經過TPC-DS打榜，作到了世界第一，性價比第一，數據在TPC-DS官網上已發佈；

部分精彩觀點摘錄：

一、目前市面上全部的自研雲原生數據庫並非真正意義上的分佈式數據庫，只能稱之爲分佈式存儲的數據庫，所以，在下半場這或許會是一個突破點；

二、NoSQL和傳統關係型數據庫的邊界會愈來愈模糊；

三、有不少廠商說本身的數據庫是NewSQL，嚴格來說，其實只是在某些維度實現了一到兩個點，並無完美解決NewSQL全部的技術挑戰；

四、MongoDB協議修改得很是巧妙，其目的是爲了獲取雲廠商的託管平臺去作本身的雲託管服務。

五、上半場各雲廠商核心的競爭力實際上是底層的託管平臺，所以，雲廠商絕對不可能去託管修改協議後的最新版開源數據庫，讓自身管控平臺開源；

六、下半場兩個發力重點：一個是不斷地提高託管平臺競爭力，二是必定要有本身自研的數據庫內核，這是爲何你們都在自研數據庫的緣由，由於，僅僅靠託管平臺的競爭力是拉不開身位差距的；

……………………………………………………

如下是專訪原文，爲了便於閱讀，在不影響原意的前提下，略作修改。

問：請從阿里雲數據庫產品線重要的產品節點和突破，來談一談阿里雲在數據庫領域的競爭力？

答：衆所周知，數據庫市場主要分爲了如下幾個板塊，一個是傳統的OLTP，即所謂的RDBMS線上交易系統。最經典的商業的有Oracle、SQL Server，開源的有MySQL、Postgresql，OLTP是阿里雲很大的一個板塊。

第二個板塊是OLAP在線分析，如Teradata，AWS Redshift都屬於這個板塊。

第三個板塊是非結構化、半結構化數據處理需求帶來的NoSQL數據庫，如Hbase, Cassandra以及如今很是火的MongoDB、Redis都是屬於這個板塊。

最後一個版塊是工具類生態的產品、數據傳輸、數據備份以及數據管理板塊。四大板塊下面，又有運維管控平臺，也就是俗稱的雲數據庫託管平臺，這幾個模塊就構成了雲數據庫體系和架構。

以上是數據庫市場較大的板塊，下面來說講阿里雲在每一個模塊裏最核心的一些產品和技術積累。首先，是最重要的OLTP板塊，能夠細分紅兩類：

一類是託管產品，即第三方的商業數據庫和開源數據庫，好比像SQL Server、MySQL、Postgresql等，主要是爲了給客戶提供豐富的選擇，使客戶能夠無縫地把線下數據庫遷移上雲。

第二類是自研雲原生數據庫，這裏面最主要的重量級產品就是PolarDB。PolarDB是一個基於分佈式共享存儲的雲原生數據庫，利用分佈式共享存儲，帶來的好處是存儲和計算進行了分離、解耦，解耦之後能夠在存儲和計算分別進行彈性擴容，作到極致的彈性，對雲上客戶極具吸引力。由於，雲上客戶需求一個很關鍵的點就是按需按量使用，同時進行按需按量計費。

除此以外，PolarDB還有不少技術，好比高可用，利用三副本及分佈式數據一致性協議，Parallel-Raft作到金融級高可用的性能，使客戶不用擔憂RPO、RTO的問題。另外一個就是在分佈式存儲以及上面一寫多讀的多計算節點再上層又作了一個智能化的代理層，能夠作到智能、自動的Low balance，計算節點之間的負載均衡分配技術等。這些結合起來，使得PolarDB在雲原生上的OLTP數據庫處理上具備很大的優點。

好比說，PolarDB能夠作到分鐘級的彈性縮擴容，從2個Core彈到32個Core只須要大概五分鐘，從2個節點彈到4個節點也只須要幾分鐘，縮擴容從幾個TB支持到一百個TB都沒問題，能夠支持單機點百萬QPS處理性能，對雲上客戶、對彈性、高可用、負載均衡等等都有很是好的解決的方案。在雲上的應用是很是有競爭力的，相對於傳統On- Premise數據庫的架構，PolarDB有很是大的競爭力。

我能夠很是自信地說，在阿里雲上的PolarDB，不管是從性能、技術上，都已經達到甚至在某些地方超越了AWS Aurora。阿里雲也在國際頂級的技術分享會議如SIGMOD、VLDB發表了論文介紹阿里的技術。

從商業上來說，從去年10月開始商業化到目前，PolarDB已是阿里雲上增加最快的數據庫產品，實際使用PolarDB的客戶重新零售到金融，再到傳統的製造業，各個行業都有，很是多的企業開始將數據庫應用遷移到PolarDB上面，這是OLTP板塊的狀況。

在OLAP板塊，咱們同樣也會分紅託管產品和自研產品。託管好比說像傳統的BI工具Tableau等，自研最主要的產品是AnalyticDB分析型分佈式數據庫，其主要特色是行列混存，可以作到多表複雜的中文查詢，在秒級甚至毫秒級進行響應。

技術細節不展開講，講兩個具體的例子，一個是最近作的TPC-DS打榜，TPC-DS你們知道是業界公認的對分析型數據庫很是重要的一個Benchmark，咱們有一個好消息，AnalyticDB已經經過TPC-DS層層考驗，作到了世界第一，性價比第一，這個數據在TPC-DS官網上已經發布。另外，介紹整個AnalyticDB系統的論文，也會在今年的VLDB上宣講，這兩方面均可以從技術上來證實它的先進性。

從業務上來說，AnalyticDB支持了從稅務、城市大腦到公有云，從金融到地產等一系列各行業對海量數據高併發秒級在線分析的訴求，與PolarDB造成了一個自然的互補，從OLTP到OLAP造成了完整的數據鏈路。

最後,阿里雲在NoSQL和工具類方面也有很強的技術佈局，主要是經過集團的應用多年鍛打出來的一些核心產品。好比，在工具方面咱們有DTS數據傳輸，在不一樣的庫之間，雲上雲下以及雲上不一樣實例之間進行實時的數據增量一致性備份傳輸等等，這樣可使得客戶快速的進行數據庫的遷移，還有數據備份DBS服務。這一系列的產品都是從客戶的角度出發，客戶須要什麼？客戶的痛點是什麼？咱們拿到客戶的需求來反推咱們技術上要作哪些東西，作到了今天這樣一個狀態。

問：PolarDB對標的是Aurora，AnalyticDB對標的是Redshift，那麼，阿里雲數據庫研發是有着本身既定的研發策略，仍是採起的跟隨策略？

答：從客觀上來說，在雲上，不只是數據庫板塊，從IaaS到PaaS，AWS絕對是先行者。他們的先進經驗以及他們避免走過的彎路，咱們沒有必要必定要走徹底跟他們不一樣的道路，我我的認爲仍是要集百家之長，要有一種開放的心態。

因此，回答您剛纔的問題，我以爲咱們一開始是一個Follower（跟隨者），這個沒什麼很差意思認可的。可是咱們要從Follower作到超越者，作到leader。經過幾年的努力，咱們如今已經作到了可以走出一條不一樣的路，作到了leader位置。那是怎樣從Follower變成Leader的？核心訴求是從客戶的需求出發。

阿里雲有什麼優點？阿里雲的優點是能接觸到中國廣大的客戶需求。AWS主要的市場在美國，美國客戶需求和中國的客戶需求有相同的地方，但也有不一樣的地方，好比說，不少大中型國有企業，美國沒有這種組織架構，其需求和美國的商業公司確定有不一樣。這是一個很具體的例子，會對咱們的技術演進之路提出一些新的思考、新的挑戰，也就會使咱們最終會走出一條不一樣於Aurora的技術之路。

另外，咱們背靠阿里巴巴集團，身處複雜的生態環境，從電商到線下的新零售，像盒馬以及線上娛樂如優酷等等，不只對咱們的技術提出了很是大的挑戰，也提供了極爲豐富的練兵場。這是咱們可以持續走下去並不斷衍生出新技術的一個核心保障。

問：到目前爲止，阿里雲數據庫產品線服務總計有多少個？

答：咱們如今從託管產品到自研產品，加起來在16個產品左右。這些產品分紅四大個板塊：OLTP、OLAP 加NoSQL加工具，最後還有一個用戶看不到的底層託管平臺。底層託管產品不是獨立的產品，它就是一個隱形存在。

從數據庫產品數量上講，你們其實大同小異，基本上都是在同一數量級，沒有太大的差異。核心的差異是在OLTP和OLAP 板塊。

阿里雲已經從Follower作到基本與AWS持平，甚至在技術上某些領域作到了領先。好比說剛纔講的OLAP ， AnalyticDB的性能已經在TPC-DS上打榜，並排到了第一。經過和AWS官方Redshift對比（在AWS上去買Redshift跑一樣的Workload），在TPC-DS的不少的Query，AnalyticDB的性能都是要優於Redshift。

另外，在某些領域，咱們也作到了人無我有，即AWS不必定有，阿里雲有。好比，在分佈式數據庫板塊，由於集團的「雙11」場景需求，咱們須要作share-nothing的架構。所以，咱們在PolarDB基礎上作了PolarDB-X。這樣一個share-nothing的分佈式架構來支持「雙11」海量高併發數據的應用場景支撐。

從AWS的角度看，沒有和咱們對標的產品。因此，如今雲數據庫時代是百花齊放、百家爭鳴的狀態，全球各個廠商，包括阿里，AWS、 Azure和Google你們在某些領域都有各自領先的地方，但在其餘領域可能另一個廠商又有領先的地方。客觀來講，阿里雲的數據庫在國內不管是從市場、技術仍是產品方面，都絕對處於領先地位，在國際上也徹底是跟AWS拉齊的水平。但願後續競爭到下半場，咱們可以在某些領域真正的作到領先者地位。

問：咱們知道，像MongoDB等好幾家開源數據庫廠商都修改了許可協議，主要針對的就是雲計算廠商，您以爲，將來二者之間會是一個怎樣的關係？這是不是雲廠商紛紛發佈自研雲原生數據庫背後的推力之一？

答：這是個很是好的問題，我把這個問題延伸一下，不只是開源數據庫廠商會有動力和壓力去作雲原生方向的轉變，傳統的巨頭如Oracle也絕對是竭盡全力的要去往雲原生雲數據庫這個方向去發展。

雲原生數據庫有不少技術點，最重要的是彈性、存儲計算分離、隔離、多租戶還有很重要的一點，要有本身的雲託管平臺。像Oracle或MongoDB要在雲上提供服務，就必需要依賴於雲廠商的管控平臺，這也是爲何去年MongoDB修改協議的緣由。

其實，MongoDB的協議修改得很是巧妙。它容許對MongoDB開源版本進行託管服務，可是若是要基於之後的版本繼續提供服務，那麼，下面的託管平臺就必需要開源。也就是說，若是AWS或者阿里雲要繼續託管MongoDB的最新版本，底下的管控平臺就要開源，開源之後MongoDB能夠拿去作本身的雲託管服務。事實上MongoDB也是這麼作的，研發了本身的Atlas。從MongoDB最新的財報就能看到，其Atlas的增加已經達到了40%多，市場份額從去年年初只有百分之十幾，到去年年末，Atlas雲託管服務已經增加到MongoD整個營收的30%多。

MongoDB的思路很簡單，比起讓雲廠商提供託管服務並基於MongoDB開源版來佔領市場份額，它更但願本身作託管服務，加上本身的內核，來把蛋糕整個切下來，把雲廠商定位成只是作IaaS（Infrastructure as a Service)的一層。MongoDB是一種策略，其餘的開源數據庫廠商包括商業數據庫Oracle、SAP， Oracle作Oracle cloud，SAP也作本身的SAP Cloud，它們背後的思路和邏輯都是一模一樣。

雲廠商的應對策略也很簡單，繼續託管產品，但只託管之前版本的產品，即對託管平臺沒有要求的開源版本，絕對不可能去託管最新版讓自身的管控平臺開源。雲數據庫之戰上半場各個雲廠商核心的競爭力在哪裏？其實就是在底下的託管平臺。由於，在上半場你們主要仍是靠MySQL、PG以及商業的SQL Server這些數據庫，來拉動線下的on- premise數據庫市場往雲上遷移，這是最核心的競爭力。

用戶上雲有兩種選擇，要麼用託管的MySQL和PG或者SQL Server，或者就是在虛擬機裏面自建。

這兩個選擇對客戶來說，雲廠商的價值就是在託管平臺來體現的。由於在內核上跟自建徹底沒區別。託管平臺最核心的就是SLA的保證，Service-Level Agreement、RTO、RPO可以作到比自建要好不少或者說和自建SLA同樣，可是成本要比它低。

對用戶而言，可能須要強大的DBA團隊，才能作到與託管平臺同樣的SLA保證。這能夠極大減小運維的投入，這是上半場的態勢。

下半場若是MongoDB等廠商作了本身的雲託管服務，就會倒逼原來上了雲託管服務的客戶，回到虛擬機裏面自建，把雲廠商完全地定位成IaaS。由於,如今對客戶而言，好比說客戶用MongoDB的Atlas，那至關於拿到了AWS或者阿里雲託管平臺提供的SLA的能力，但又不須要給雲廠商直接付費，成本上有優點，可能就會去選擇自建。

那雲廠商怎麼應對呢？有兩點：第一是不斷地提高託管平臺競爭力。好比說咱們阿里雲上有一個叫SDDP的自動駕駛雲託管平臺，它是利用機器學習人工智能的技術，來對雲託管平臺上的數據庫實例進行自動運維、自動優化等等，來確保託管平臺的競爭力。第二個從內核的角度來講，爲何亞馬遜、阿里和Google，都在本身作本身的雲原生數據庫？由於你們意識到，僅僅靠託管平臺的競爭力是拉不開升位差距的，因此必定要有本身的自主可控的內核，並且這個內核可以和傳統的on- premise DB有性能上的差別。針對雲原生的一些特色，可以吸引客戶從MySQL、PG、Aurora和MongoDB等遷移到自主開發的雲原生數據庫上來。

AWS是最典型的，率先推出了Aurora。在NoSQL領域又推出了DynamoDB，在分析領域推出了Redshift。MongoDB修改協議之後，它又推出了本身的DocumentDB。這一系列動做背後的邏輯，和前面講的是同樣的。我我的認爲，這場比賽已經進入了下半場。總結來說，做爲雲廠商，咱們須要在兩方面發力，一個是管控平臺，經過智能化的手段，提升它的運維能力和效率，另一個要提高它的安全可靠、可驗證。AWS去年推出了QLDB、Quantum Ledger Database，利用區塊鏈裏面的Merkle tree技術，對數據庫的運維日誌進行驗證。這樣客戶上雲之後能夠來驗證運維日誌，來確保作到了SLA的保障，這些是從管控平臺要作的一些差別化。另外是從內核的角度，不斷地去投入內核的研發，以可以和傳統的數據庫或者新生的像MongoDB數據庫內核，進行差別化的競爭。以上是我認爲的雲數據庫戰場下半場的一些比較精彩的看點。

問：您提到了雲原生數據庫，我最近也老是聽到幾個詞，雲原生分佈式數據庫，分佈式中間件等。如何去鑑別真正的雲原生和僞雲原生？

答：這個問題很好，傳統的數據庫架構是什麼？是一種share-everything的架構，好比說一個本地磁盤上面可能有比較大的內存，能夠插多個內存條，有比較大的內存池。再上面是計算，有共享的計算狀態，有多個 Core。可是很關鍵的一點是transaction，或者有不少個 query進來，這些transaction和query在整個數據庫從存儲到內存，再到 Core都是共享狀態的，這個就叫share-everything架構，也是傳統的數據庫架構，像Oracle、SQL Sever都是這種架構。

這種架構有它的優點，是共享狀態因此Coordination比較容易作。但缺點是Scalebility（擴展性）會受很大的限制，因此就衍生出了分佈式這個概念，分佈式最核心的挑戰就是要提供Scale Out以及Scale Up的能力。

Scale Out怎麼作呢？比較經典的像Google Spanner的作法，是作一個share-nothing，而後作分庫分表，作partition，作sharding。在shard之間若是有跨shard的查詢和事務，就須要作分佈式的查詢和分佈式的事務處理。這個就是分庫分表、Spanner的架構，也是PolarDB-X的架構。這是一種，在share-nothing上面有兩個分支，一個是原生的分佈式架構。也就是說，實際上在底下是作了sharding和partition的，但客戶不須要去感知。對客戶來說，業務邏輯不須要改，若是有分佈式的事務處理，分佈式查詢就會自動搞定。客戶不須要去擔憂怎麼去分庫分表，去拆分業務邏輯，這是一種。

還有一種就是您剛纔問題裏面提到的，利用中間件的形式作一個分庫分表的解決方案，這個對業務邏輯是有侵害的。這須要數據庫的服務商，或者是客戶本身要對業務邏輯有很清晰的認識。好比說庫存、訂單，這兩個庫是分開的，平時也不會有交集。因此，在業務邏輯上，把它拆分紅兩個庫，這兩個庫存在不一樣的節點，這就是一種中間件的解決方式，業界有不少這樣的解決方案。

這種方案的好處是比較簡單，劣勢就是它沒有像原生分佈式數據庫那樣，對客戶的業務邏輯有侵入式的改造。另外就是，它對事務分佈式查詢的支持，沒法作到像原生的分佈式數據庫那麼好。以上是關於share-noting分佈式數據庫。

如今，你們講的所謂叫雲原生分佈式數據庫。我認爲這是一個僞命題、僞概念。實際上，如今全部的廠商在雲數據庫上尚未一個真正的分佈式的架構，大部分都是利用分佈式存儲作共享存儲，而後在上面作一寫多讀。好比PolarDB， Aurora都是這樣的架構。它其實是分佈式的共享存儲，上面作一寫多讀存儲計算分離，這個是我認爲如今所謂的雲原生數據庫或雲原生分佈式數據庫最典型的一個架構，分佈式利用RDMA快速網絡作一個分佈式共享存儲。它看起來像一塊盤，實際上它是一個分佈式的磁盤，但對上層的kernel來說，它看起來像一塊本地盤。它帶來的好處就是物理數據只有一份，它避免了像MySQL、PG這種傳統的主備，須要在主庫和備庫之間作這種物理數據的備份的挑戰。主庫、備庫寫的節點和讀的節點是一份物理數據，這樣就帶來不少不少好處。但嚴格來說，它是一個分佈式存儲的數據庫，不能把它叫一個分佈式數據庫。這和咱們經典定義的分佈式數據庫仍是有一些區別的，可是如今你們把這個叫雲原生數據庫或雲原生分佈式數據庫。

在下半場再往前發展會出現一個什麼現象？我我的認爲，下半場可能會比較有突破點的地方，就是把剛纔所說的真正的分佈式架構經過shardin架構和雲原生分佈式共享存儲的shared-storage架構（雲原生分佈式數據庫從架構上來說叫共享存儲shared-storage架構）結合起來。這個結構的好處是什麼？由於shared-storage用的是RDMA，RDMA是有限制的，好比跨AZ或者說更嚴重的狀況，要跨區的時候，它不可能無限的擴，RDMA共享存儲可能只能作到十幾個節點、幾十個節點。由於一旦跨了network swich之後，RDMA的性能損耗很是大，遠程訪問不可能作到和本地訪問同樣快，這樣shared-storage架構就有限制。

最經典的Oracle RAC作到 10個節點、20個節點就沒辦法再往上了，但若是併發高到必定程度或者數量大到必定程度，只能再往上擴，Scale Out要一直往下該怎麼辦？這時候必定要作分佈式partition、sharding這種架構，可是partition、sharding若是不用共享存儲的話，帶來什麼影響呢？每一個shard不能作太大，由於單節點就只能存這麼多數據。也就是說可能要分不少個shard，分佈式的transaction很是多，一旦有distributed commit，性能損耗是很是大的。因此這兩個若是能結合起來，有一個好處就是仍是能夠Scale Out，由於我上面有share-nothing這一層，底下是共享存儲的節點，每一個shard就能夠作得很是大。也就是說對一樣的數據來說，我只須要不多的shard就能夠來支持。不多的shard也就意味着分佈式跨shard的這種處理會大大減少，分佈式的能力會大大提高。因此這兩個結合起來，我以爲會是一個比較新、比較有意思的挑戰。

問：接下來的一些問題，其實也一直比較困擾我。剛剛您說了分佈式，其實過去還有一種分類，好比說SQL、NoSQL、NewSQL，那NewSQL和分佈式數據庫之間究竟是一個什麼關係？過去我會把它理解成SQL、NoSQL以外的就是NewSQL，分佈式數據庫和NewSQL之間是一個包含關係仍是其餘的關係？

答：這也很是好的一個問題，數據庫的同仁和朋友不少時候會有一些混淆的地方。首先NoSQL雖然叫NoSQL，但它實際上含義並非不要SQL，它是Not Only SQL的縮寫，取了個巧叫NoSQL，但它其實是指不只僅是SQL的意思。NoSQL的最先發展是怎麼來的？實際上來源於傳統的關係型數據庫，關係型數據庫裏面由於要保障強一致，也就是ACID，因此Scale Out能力是受到限制的，因此在作Atomicity、 Consistency、Avilability、Durability這些保證的Isolation的時候，和分佈式fundamentally是有衝突的，當時的硬件技術、軟件技術沒有使得傳統關係型數據庫可以無限的水平拓展。

但以Google爲表明的不少互聯網公司，在當時確實須要數據和事務處理、查詢處理可以無限的水平拓展，由於數據量太大了，天天運行的數據都要存，這是個無限增加的過程。並且這些數據還有個特色，它不必定是結構化的，它多是半結構甚至非結構數據的，因此，就衍生出NoSQL這個概念。總結來說，NoSQL最核心的理念就是把傳統的關係型數據庫裏強一致的需求弱化，好比說Isolation level,傳統關係型裏可能要snapshot isolation，如今只要作到ReadCommitted就好了，只要沒有髒讀就能夠。其它的應用，若是應用層須要更高的隔離機制，那就在應用層去寫邏輯，用external Consistence的方法來解決，在數據庫層面只需保證沒有髒讀，犧牲必定的數據一致性，換來幾乎無限的水平拓展。這類系統最經典的就是Hbase、Google的BigTable、Cassandra等等，這就是NoSQL的來源。

總結來說，就是爲了提供無限的水平拓展Scale Out的能力，犧牲必定的一致性保障，主要是在Consistency 和Isolation上作一些犧牲，換來無限的水平拓展Scale Out的能力。

NewSQL怎麼來的？在NoSQL大概發展了有十年左右，大概是在2008年、2009年那時候出來這個概念，到如今接近10年了。你們發現把一致性等推到應用邏輯層去寫仍是不少困難的，並且你們發現慢慢地發現對非結構化、半結構化數據也是有強一致性需求的。不是說傳統的transaction事務處理只對結構化數據有需求，對非結構化、半結構化沒這個需求。因此你們就發現NoSQL系統也得去保證ACID guarantee，所謂的eventual consistency，weak consistency guarantee在不少應用下不適用，因此仍是要去作snapshot Isolation，在NoSQL的場景下，這是從事NOSQL的朋友發現有這個需求，從事關係型數據庫的朋友發現了什麼？好比說MySQL從5.7開始，PG11.0、11.2版本都加入了對Json的支持。典型的半結構化的數據結構，也就是說傳統的關鍵性數據庫僅僅支持結構化數據也不行了，它必須也要提供非結構化、半結構化數據的支持，也就是說兩邊都開始往中間靠。一個有強一致的guarantee，可是它只支持結構化數據，Scale Out能力有限。另一個支持半結構化、非結構化數據，Scale Out能力很好，但沒有一致性保證。兩邊都犧牲了一些東西，換來本身想要的，但後來愈來愈發現犧牲的東西客戶也是須要的，不只限於本身所保留的，因此兩邊都開始補齊缺失的功能。

二者都要有，就變成了「既要......又要......」的狀態，這就變成了兩方的結合，也就是NewSQL。因此最終我我的認爲，若是NewSQL真能發展到最後變成比較常見的一個態勢，傳統的NoSQL和關係型數據庫的邊界就會愈來愈模糊。

也就是說,NewSQL它不等於分佈式數據庫，分佈式數據庫能夠是NewSQL數據庫。NewSQL裏面很重要的是Scale Out能力，它首先確定是一個分佈式存儲的架構。也就是說它不必定是分佈式共享存儲，但它確定是有shard的，有partition。像HBase、MongDB都是shard default的最多見的一個態勢。但分佈式的數據不必定是分佈式的數據庫，這要看它是否是真正作到了分佈式查詢和分佈式事務。由於有可能它作了shard，分佈式的數據，可是查詢和事務是所謂的叫perfect shardable workload。這個事務和查詢只用看第一個shard就完成了，另外一個查詢只看第二個shard。因此雖然它有不少個shard，也有不少個查詢和事務，可是具體到每個查詢和事務，都是單個shard搞定的。嚴格來說，我認爲它不是一個分佈式數據庫，只是對業務邏輯進行了比較巧的一個partition，使得它能夠就完美地去並行處理。

真正的分佈式數據庫有兩個特色：第一，數據確定是分紅了多個shard；第二，它的查詢和transaction是有可能產生cross shard這種查詢和cross shard transaction，這種叫分佈式。傳統的NoSQL只支持第一個特色或只支持第二個特色的。支持第二個特色的是犧牲了數據一致性(isolation level)，換來了它可以支持分佈式事務、分佈式查詢的能力。

關於NewSQL，我我的認爲一個真正好的NewSQL數據庫，它必須是支持結構化、半結構化、非結構化數據，這第一點。

第二點是，優秀的NewSQL數據庫要有很是好的水平拓展的能力和Scale Out能力，支持分佈式查詢、分佈式事務，同時在單節點上又有很是好的彈性和Scale Out的能力。目前來看，尚未一個數據庫能夠作到完美的解決全部問題，還有一些其它的技術點像HTAP（混合的事務和分析處理）、讀寫並存怎樣高效的去處理？還有多模multimode、多種數據形態在一個庫裏，怎樣在統一界面去查詢？若是可以完美地解決全部這些問題，我認爲它就是一個比較優秀的NewSQL數據庫。

目前來看NewSQL只是從技術概念上出現的一個東西。嚴格來說，有不少廠商說本身的數據庫是NewSQL，他可能只是在某些維度實現了一到兩個點，但並無完美解決咱們剛纔提到的NewSQL全部的技術挑戰，因此我以爲，目前咱們仍是有比較長的路去探索的。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。