如何看待Google的Cloud Spanner?

01-13

Google把傳說中的資料庫Spanner變成了Google Cloud上面的一個雲服務：https://cloud.google.com/spanner/（雖然不翻牆我tm打不開)

首先 Spanner 會對 Google Cloud 加分不少，其他的 Cloud 也需要有自己的解決方案，不過這個東西有技術門檻，不是一朝一夕能搞定。資料庫要開始軍備競賽了。

另外有幾個問題需要考慮：

F1 並沒有開放出來，一些 OLAP 的業務不知道能不能 hold 住
對於資料庫，小客戶可能只需要單機資料庫，大客戶又傾向於私有部署，比如銀行、證券公司這種很難把數據放在別人那裡，所以 Spanner 的客戶定位可能有點尷尬
看了一下價格，不算便宜
現有的業務以及數據如何遷移上去

最後廣告一下：

本周六我司 CEO 出台與大家共同深入討論 Google Spanner，對比 TiDB 和 Google Spanner 的技術實現的差異，以及背後的原因。

COISF Meetup 第 7 期——《深度解讀 Google Spanner 》

我從市場和商業的角度，簡單回答一下這個問題。

在on-primise時代，商業資料庫市場主要由Oracle IBM 微軟3大巨頭把持，而進入互聯網時代後，先是Mysql，Postgre等開源關係型資料庫開始迅速發展，然後MongoDB，Elasticserch，Redis，Hbase等開源Nosql資料庫也雨後春筍般的發展起來，資料庫市場呈現百花齊放的局面。然後是Cloud時代，各大雲服務提供商，都開始提供基於各種關係型資料庫和nosql資料庫的雲服務。

我先以AWS為例談談資料庫市場，AWS15年時，據說就已經賣出了10億美元的資料庫服務，在當時佔了AWS幾乎20%的銷售額，可見整個資料庫市場在雲服務商收入比例非常高，我估計是除了虛擬機和存儲，帶寬外最大的銷售來源。但是AWS賣出的這10億美元中，有多少是需要付給Oracle和Microsoft的資料庫License費？我不得而知，但我根據某個消息來源（不方便透露具體），猜測這筆License費用應該也是幾億美元這個級別的，而License費的大頭是付給Oracle的。

從上述角度分析，在AWS上大量企業用戶依然在使用商用的關係型資料庫，可以看出，目前在企業關鍵應用方面，很多用戶依然並不信任Mysql和Postgre資料庫，這裡有開源資料庫性能和穩定性的原因，當然也有遺留應用移植的問題。AWS自己當然很清楚這個情況，以AWS的個性，怎麼可能為他人打工？於是AWS推出了兼容Mysql的Aurora資料庫服務，Aurora在性能，擴展性，可靠性方面均遠遠好於基於複製技術的Mysql服務。

我認為AWS此舉的目的，就是吸引更多的企業關鍵性應用遷移到AWS自己的資料庫服務上來，實質上Aurora衝擊的不是Mysql原有的市場，而是直接衝擊在AWS之上的Oralce Sqlserver這些商業資料庫市場。當然這個舉動也徹底激怒了Oracle，在16年的Oracle Openworld，Larry Ellison已經把AWS當做頭號敵人，並在最近宣布了在AWS上部署的Oracle 資料庫license價格翻倍，這個事件可以認為是這兩家公司徹底決裂的標誌，而決裂的根本原因是：AWS悍然侵入了Oracle的核心腹地，而整個關係型資料庫是每年幾百億美元的大市場，並且給Oracle帶來非常豐厚的利潤（佔據Oracle公司利潤的50%以上）。

那麼微軟呢？微軟當然很明白關係型資料庫市場的價值，因此始終堅持在資料庫方向上的投入，進入cloud時代後，微軟也率先推出Azure PaaS，更加大了cloud 之上的資料庫研發，Azure在最近的成功也證實了微軟的眼光和努力。

現在回到Google Spanner的話題吧。目前Google在cloud方面還遠遠落後於AWS和Azure，如果Google僅僅模仿AWS和Azure，沒有自己技術的先進性和創新，估計永遠也無法追趕上前兩名，由於Google在企業級IT市場的理解和經驗上也遠遠不如前兩者（這些是真需要時間的），Google在CLoud方面唯一的機會可能就是在技術上的優勢了。

正因為追趕競爭對手，Google不能再把自己的黑科技藏著掖著了，於是大家看到了Kubernetes（Borg）的開源，Tensorflow（Google Brain machine leaning 框架）的開源，Google Dataflow的開源。這麼看，Spanner服務的上線也就順理成章了，畢竟Google Spanner是世界上唯一一款既支持大規模Scale out，又支持ACID，並在線上穩定運行了多年的關係型資料庫，如果Google Spanner能夠支持便捷的傳統資料庫的遷移，肯定會成為Google Cloud的加分項，同時也能給Google Cloud帶來豐厚的利潤，因為很多用戶已經習慣了Oracle資料庫的昂貴价格。

最後談談資料庫市場的競爭格局，在Cloud時代，資料庫的競爭變得更複雜了，因為每個Cloud都是一個封閉的生態，每家大型CLoud服務商都傾向於在自家的Cloud上提供自家的技術，而並不情願使用開放或開源更別說是競爭對手的技術，原因是他們都在儘可能的Lock in客戶。包括國內的阿里雲，也在推出自己研發的Oceanbase資料庫服務。在這種情況下，獨立的資料庫生產商的生存會更為艱難，即便是Oracle這樣的巨鱷，也不得不加強IaaS和PaaS整體的建設，因為如果沒有整個生態的支持，單獨的資料庫將無力抵禦競爭對手的侵襲。可以說，未來在It基礎架構技術領域的競爭，將會演變為少數巨頭間的生態競爭，獨立的小型的技術供應商的處境會異常艱難，Maybe未來我們將會看到更多的併購......

瞎說了半天，下班回家........

Google Cloud Spanner簡析

2017年2月16日，Google發布了基於Spanner的資料庫服務Cloud Spanner (Beta，https://cloudplatform.googleblog.com/2017/02/introducing-Cloud-Spanner-a-global-database-service-for-mission-critical-applications.html )，發布中提及了兩個客戶JDA和Quizlet，後者發表了一篇挺長的測試報告( https://quizlet.com/blog/quizlet-cloud-spanner )。

【Cloud Spanner是什麼】

Google的廣告計費系統AdWords原本使用MySQL + sharding，但MySQL的擴展性缺失和可靠性欠缺促使Google從2008年底開始研製了F1及Spanner系統（Google確實很有遠見，那個時候就看到了MySQL的上述問題並擬進行淘汰）：

Resharding this revenue-critical database as it grew in the number of customers and their data was extremely costly. The last resharding took over two years of intense effort, and involved coordination and testing across dozens of teams to minimize risk.

(摘自Google的Spanner論文，強調部分為本文所加)

F1本來是Google的AdWords重構項目，Spanner則是其中的分散式資料庫。Spanner最關鍵的特性是事務(ACID)、跨數據中心同步等，其中TrueTime對於事務的實現十分關鍵。F1基於Spanner，其關鍵特性包括SQL（可能並非國際標準的SQL，而是Google自己的SQL標準）、二級索引支持等。除了最早的AdWords外，據說Google還有一些其他應用基於F1。

Cloud Spanner是Google基於Spanner提供的、可用於關鍵業務的雲資料庫服務。

【Quizlet測試報告】

Quizlet是一家提供便捷在線學習及工具的美國公司，「通過搜索數百萬學習集或創建自己的學習集，通過用單詞卡、遊戲和其他功能提高學習成績」。Quizlet把其業務系統從MySQL遷移到Cloud Spanner的原因與Google把AdWords從MySQL遷移到Spanner/F1類似：MySQL的擴展性缺失。

總體上，Quizlet的測試報告對Cloud Spanner給出了相當正面的評價：

Cloud Spanner的擴展性非常好，幾乎跟其節點（不是物理接點，而是一種虛擬接點）個數成線性正比；
儘管跟Google內部的Spanner有一些差別，但Cloud Spanner依然有很高的可用性；
Cloud Spanner有兩個非常有用的管理數據局部性的功能（data locality），一個類似於table group，即把經常同時訪問的表放置在一起，提升IO性能；另一個是stored index（有人譯文存儲索引），即把通過二級索引經常要訪問的數據直接存儲在二級索引中，這樣就省去了回表；
Cloud Spanner支持一個比一般傳統關係資料庫支持的SQL小、自己定義的類似於SQL:2011標準的SQL，支持的功能包括join、create table、二級索引等；
Cloud Spanner支持7種數據類型：bool, int64, float64, string, bytes, date, timestamp。

Quizlet的測試報告也指出了Cloud Spanner的一些不足之處：

Cloud Spanner不支持insert，update等SQL DML，而是通過指定主鍵的RPC直接實現行的修改；
Cloud Spanner在正常壓力下（分析應該是同城數據中心部署），簡單事務的最小響應時間大約5ms；
Cloud Spanner的二級索引功能很強大，但寫入時導致的開銷也非常大，即使寫入的數據有很強的局部性，這可能跟二級索引更新時的鎖影響了其他需要二級索引的訪問。Quizlet的解決方法是把二級索引包含在主鍵之中；
可能是代價估算的偏差，Cloud Spanner在執行SQL時選擇索引並不是非常精確，最好的辦法是通過類似於hint手段指定索引；
Cloud Spanner非常複雜，但用戶卻無法探查事務在Cloud Spanner內部的執行狀況，這是Cloud Spanner最大的問題。Cloud Spanner沒有介面來觀察當前正在執行的查詢，也無法知道正在進行的索引構建的情況，僅僅有一些內部狀態的信息，例如CPU利用率，IO次數和數據量等，沒有一些關鍵的例如數據分片的分布情況，大查詢的狀況等。

【Spanner與OceanBase的技術方案對比】

Spanner在世界上首次在跨地域尺度上實現了ACID，並且很好地實現了水平擴展，解決了基於普通廉價PC伺服器的資料庫高可用，這是一個了不起的創新。Spanner大約從2008年底開始研發，但直到2012年其論文發表後才為外界所知。
OceanBase在2010年6月立項，並獨立發展了自己的ACID、水平擴展以及基於普通PC伺服器的資料庫高可用技術等。
Spanner沒有支持國際標準SQL及其介面（ODBC/JDBC等），也沒有採用真正的關係模型（儘管支持join等），主要原因也許是Spanner最早定位於Google內部應用。這些缺失使得Spanner能夠以較小地成本和在較短的時間投入生產運行，並且更好其契合內部應用（例如採用樹形模型代替關係模型），但這也使得遷移已有的基於關係資料庫的業務到Spanner的工作量和難度很大，對Spanner的外部應用和推廣的負面影響無法忽視。
OceanBase從第一天就強調採用標準的關係模型和支持國際標準SQL。由於工作量的原因，OceanBase對完善SQL標準和介面的支持比較晚，直到OceanBase 1.0才完全與MySQL語義語法和介面兼容，這使得OceanBase從開始研發到大量的內部應用經歷了更長的時間，但也使得OceanBase與傳統關係資料庫更相似，後續推廣應用的代價更小，比如MySQL應用可以不做任何修改地無縫遷移到OceanBase。
關於TrueTime：Spanner通過TrueTime實現了大規模、跨地域分散式資料庫系統的快照讀隔離級別（snapshot isolation），這非常了不起，但這個技術方案導致單次訪問延遲在5ms甚至更長（即使是同城部署），許多業務無法忍受如此之大的延時。
OceanBase必須保證對簡單訪問的響應時間小於1ms（正常壓力下）------類似於傳統關係資料庫，跨地域的訪問也僅僅在事務提交時才必須，因此OceanBase採用跟TrueTime迥異的機制，但也實現了跨地域的資料庫高可用。
Spanner通過F1用於Google生產系統，應該沒有直接用於生產系統，並且早先主要用於少量內部關鍵項目（例如AdWords），因此Spanner缺乏像傳統商業資料庫的各種內部狀態和事務執行過程跟蹤和分析手段，這對於Spanner的外部應用推廣也會有較大的影響。
OceanBase從一開始的目標就是像傳統關係資料庫一樣直接用於生產系統，因此內部狀態和事務執行過程的跟蹤與分析十分必要，雖然限於工作量和人力投入的原因，OceanBase直到1.0版本後才有比較完善的內部監控和事務執行跟蹤機制。

修改Spanner的TrueTime的挑戰比較大，改變其樹狀的數據模型也有一定的挑戰，假如Cloud Spanner能夠得到較大的推廣和應用，其他的缺陷應該可以逐步得到彌補和改善。

對於Google推出Cloud Spanner這個事情，談兩點看法，算是拋磚引玉。

1. Spanner不是足夠強大所以才出現在Google公有雲上，而是Spanner的成長需要Google公有雲這個環境
2016年印象最為深刻的，是這樣一句話：2C領域看社交， 2B最重要的場景是雲。 2C的項目值不值得投，要看這個產品是否有社交屬性；而在2B領域，雲是新技術落地的前提，是新技術往前發展最重要的陣地。新技術要在激烈競爭中勝出，最好依託一個雲平台。由此看Google在其公有雲上推出Cloud Spanner，就很容易理解了：這不光是Google公有雲自身發展的必要，也是Spanner這款產品發展的必要。所以，你會發現Spanner連Insert、Update等語句都不支持，就宣布對外開放了（詳情見：Quizlet Tests Cloud Spanner SQL Dialect一節）。

雲特別是公有雲發展至今，價格是越來越便宜，性能和穩定性越來越強，正在吸引越來越多的企業上雲。而由於用戶的數據和行為都沉澱在雲上，因此更能全面且深入地了解企業的需求，另外，企業對於雲這種新的平台，往往更有耐心和更強的合作意願。有了這三點，雲平台對分散式資料庫等技術來說，無疑是打磨產品的最佳陣地。

從分散式資料庫技術的發展來看， Google在其公有雲上推出Spanner，意味著企業級的分散式資料庫領域，迎來一個重量級的玩家，在今後必然極大地推動分散式資料庫技術往大型通用的方向發展。spanner雖然號稱是NewSQL的開山之作，但多年來被深藏於Google內部，對業界分散式資料庫的實踐作用有限。這會Spanner跳上公有雲這樣一個處於聚光燈下的平台來施展拳腳，必然讓台下圍觀群眾能看個仔細。研究Cloud Spanner今後在企業級服務上的實踐，了解其在產品、技術、服務各個層面的演進和發展，必然能夠有所收穫。

總的來說，於己於人，Google推出Cloud Spanner，都是一件好事。對於國內分散式資料庫開發商而言，由於牆的存在，這更是一件讓人喜聞樂見的事情。從各種宣傳材料上來看，Cloud Spanner發布的這幾天，最高興的莫過於 TIDB（ https://zhuanlan.zhihu.com/p/25266062 ）。給人一種大BOSS終於出山，小弟剛好又姓趙的感覺。理論上，作為業內兩個相互競爭的產品而言，TiDB這個表態似乎不太尋常，但也符合中國國情，誰讓Google被牆了呢。

2. 2017年是NewSQL的落地年，但要NewSQL還有很長的路要走

16年下半年開始，各種NewSQL紛紛結束潛水模式，開始浮出水面。TiDB加大了宣傳的力度，OceanBase的正祥老師跑到知乎上來發帖了（雖然每次說的內容好像都一樣），巨杉資料庫宣稱獲得1000萬美元B輪融資。從這個趨勢來看，2017年各家NewSQL廠商的動作，會更加地大。或許可以說，17年將會是NewSQL的落地年，不僅會有大規模的宣傳，而且可能會有實際的，有影響力的業務開始接入。

不過最終還是得看實際的效果。根據我們團隊（UCloud分散式資料庫UDDB）幾個月來在公有雲環境上的實踐，我們發現，客戶的業務，對資料庫和SQL會有各種使用方式，有的是你永遠想想不到的。以目前各種NewSQL的架構和實現方式，要有效支持客戶的業務，要有很長的路要走。

目前各家NewSQL的架構，本質都是 Proxy + 存儲節點，所以在計算模型上，和基於資料庫中間件構建的分散式資料庫（比如UCloud UDDB、阿里DRDS等），是一樣的。對於各種SQL的支持，難度也是一樣的，並沒有什麼捷徑。雖然NewSQL產品一上來就支持分散式事務，但是僅有這點還遠不夠。資料庫畢竟是要把用戶的每條SQL都跑通的，光是有分散式事務、多副本容災等高大上概念，但是諸多SQL不支持，用戶也不會買賬。另外，這種計算和存儲分離的架構下，複雜SQL的執行必然是分散式的，這就涉及分散式SQL調優問題。要在支持各種複雜SQL的同時，還能保證SQL的執行性能，有很長的路要走。

因此，2017年是考驗NewSQL廠商執行力的一年。不僅是考驗技術能力，還考驗服務能力。如果不能快速應對客戶需求，妥善處理用戶問題，NewSQL這幾年宣傳的各種技術小清新概念，可能會讓用戶有一種幻滅感：以為你什麼都支持，但到頭來還是我的業務做各種改造，改造之後系統可能還不穩定。

3. 關於UCloud UDDB的一些介紹

對於服務這一點，UCloud UDDB團隊是有些話要說的。從大方向看，17年的分散式資料庫領域，還沒有一個那個產品可以稱得上是大型通用標準化，都需要根據用戶業務做一些迭代，甚至客戶的業務也需要做一些改造。因此，服務，特別是售前服務，是要放在第一位的。

正如在雲計算界，提到UCloud，大家的第一反應是服務好， UDDB團隊也承諾提供優質的在線支持服務。客戶只要通過QQ即可聯繫我們，如有需要，也可以當面溝通。我們致力於通過QQ，或者當面溝通的方式，給客戶提供這樣一種服務品質：在溝通討論和解決問題過程中，客戶不會覺得我們是另外一家公司，而彷彿是自己人，好像自己公司專門的資料庫中間件團隊。這要求UDDB團隊在問題的響應速度，問題的回答質量，主動服務的能力，以及信息透明程度上，做到最好。要做到確實比較難，但目前幾個月實踐下來，我們還是有能力cover住這樣的服務品質，客戶對UDDB的服務還是滿意的。

最後，再談一下UDDB的產品和技術路線問題。在各種NewSQL產品紛紛浮出水面的2017年，作為一款基於資料庫中間件技術開發的分散式資料庫產品，UDDB看上去好像有點過時了。但我們認為，這是近兩三年內，最為客戶著想，最接地氣的方式。客戶真正需要的是能切實解決問題的產品，而不是自己的用的資料庫有多少小清新的技術理念。從UDDB的兩大基礎，資料庫中間件技術和單機雲資料庫產品UDB來看，過去十多年資料庫中間件技術解決了大量企業遇到的分散式資料庫問題，而UDB作為一個成熟的存儲產品，在穩定性上，要比NewSQL從頭開發的存儲系統強很多。

業內另一個普遍的疑問是，對於UDDB這種基於資料庫中間件而構建的產品，會不會只是一個過渡性的方案，未來終將讓位於NewSQL這樣的產品？在我們看來其實不然。UDDB和OceanBase、TIDB等NewSQL，在計算模型上是同源的（計算和存儲分離，架構中包含Proxy和存儲節點），也有著同樣的終極目標。廣義上來說，OceanBase內部的Proxy，和TiDB（即TiKV上面的proxy），也是一個資料庫中間件。狹義的中間件，如MysqlProxy、Atlas、Kingshard等，在做sql代理時只有一種手法，就是將客戶的SQL改寫然後下推到存儲節點，缺少在內部根據SQL語義，生成一個分散式執行計劃並執行的能力。但分散式執行計劃的生成、優化和執行，並不是說在資料庫中間件內部不能做，只是老的幾款中間件沒有做到而已。 UDDB的技術路線，就是一個廣義資料庫中間件的發展路線，只是把底層的MySQL節點，當做一個成熟的存儲引擎來使用，很多SQL功能，包括系統表，都是在資料庫中間件這一層來實現的。UDDB的中間件代碼結構，幾乎等同於MySQL框架層的結構，有獨立而完整的語法解析、分散式執行計劃生成、執行計劃優化和執行器模塊，因此理論上UDDB將來能夠處理任何SQL。當然目前圍繞分散式執行計劃的生成、優化和執行還是很初步的，幾乎等同於狹義中間件的轉換SQL並下推，但隨著UDDB基於UCloud公有雲平台的演進，這一塊將會越來越完善。

UDDB演進的最終效果，是底層存儲模塊可隨意替換。在初期會使用MySQL來作為存儲節點，如果需要，也可以替換成RocksDB，Hive等，後續可以開發自有的存儲模塊替換MySQL，實現分散式事務，多副本容災等效果，最終成為一個NewSQL。而這個過程，對客戶業務是無感知的。

看到了未來資料庫技術與雲服務提供商事實上綁定的趨勢。

簡直是一場噩夢。

因為google cloud就是偶們spanner團隊開的，偶們就是正常發布一個土豪金產品，以降低偶們的運維複雜度，你們咋這麼感興趣呢？

jeff dean的google+ 貼了一個blog
https://quizlet.com/blog/quizlet-cloud-spanner

老外比較spanner和mysql的

好是好，一般小公司真用不到這玩意兒

價格有點貴，而且要實現關係代數還得自己寫個f1。。。