獨家對話李飛飛：雲資料庫戰爭已經進入下半場

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

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

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

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

透露兩條資訊：

1、 PolarDB從去年10月開始商業化到目前，已經成為阿里雲上增長最快的資料庫產品；

2、AnalyticDB已經透過TPC-DS打榜，做到了世界第一，價效比第一，資料在TPC-DS官網上已釋出；

部分精彩觀點摘錄：

1、目前市面上所有的自研雲原生資料庫並不是真正意義上的分散式資料庫，只能稱之為分散式儲存的資料庫，因此，在下半場這或許會是一個突破點；

2、NoSQL和傳統關係型資料庫的邊界會越來越模糊；

3、有很多廠商說自己的資料庫是NewSQL， 嚴格來講，其實只是在某些維度實現了一到兩個點，並沒有完美解決NewSQL所有的技術挑戰；

4、MongoDB協議修改得非常巧妙，其目的是為了獲取雲廠商的託管平臺去做自己的雲託管服務。

5、上半場各雲廠商核心的競爭力其實是底層的託管平臺，因此，雲廠商絕對不可能去託管修改協議後的最新版開源資料庫，讓自身管控平臺開源；

6、下半場兩個發力重點：一個是不斷地提升託管平臺競爭力，二是一定要有自己自研的資料庫核心，這是為什麼大家都在自研資料庫的原因，因為，僅僅靠託管平臺的競爭力是拉不開身位差距的；

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

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

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

答：眾所周知，資料庫市場主要分為了以下幾個板塊，一個是傳統的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所有的技術挑戰，所以我覺得，目前我們還是有比較長的路去探索的。