我們先看左邊這個圖，我們以幾個典型的產品為例，比如MorgoDB Alats,他們云上的收入是云下收入普通3倍以上。其實在2022年前三季度,其云下收入已經(jīng)占了整體收入的2/3，是遠高于私有化部署的。從MorgoDB視角來看，它的云上已經(jīng)是它的絕對的中心，占比占2/3，增速又是云下的56倍。這樣就能看到云上面的發(fā)展趨勢。
我們再看關于數(shù)據(jù)庫，右邊的圖，我們能看到云上收入增速是非?？斓?，據(jù)統(tǒng)計來看，它是云下增速的2倍以上, 2021年幾乎達到私有化部署收入的額度，在95%左右。預計2022年會超過私有化部署，這是全球的情況。國內發(fā)展趨勢也是一樣的，云上增速也是云下增速的兩倍。預計國內在2025年左右，云上、云下收入應該會持平。
云對數(shù)據(jù)庫廠商來說是一個放大器，是觸達用戶最短的并且最高效的路徑，是直接溝通的一個平臺,可以實現(xiàn)快速交付、反饋和迭代。從趨勢和效率上來看，數(shù)據(jù)庫廠商不上云很難活下來的。
2022年對于PingCAP的TiDB數(shù)據(jù)庫來說，是一個大力投入云服務的一年，是TiDB云的元年。PingCAP在今年開始，已經(jīng)在云上為用戶提供正式數(shù)據(jù)庫服務。
在2015年的時候，基本上沒有提云原生數(shù)據(jù)庫。但2019年的時候，最主要的議題就是云原生數(shù)據(jù)庫。當然也包括數(shù)據(jù)分析決策，這也是云原生數(shù)據(jù)庫排在第一位的需求，所占篇幅最大。
首先看看云原生是什么？
按照云原生計算基金會(CNCF)的定義，云原生就是“云計算+自動化管理+微服務”，但是對數(shù)據(jù)庫來說，就不是那么好理解了。PingCAP認為云原生最主要的就是實現(xiàn)資源的池化，實現(xiàn)數(shù)據(jù)計算、存儲、內存的池化，可以實現(xiàn)動態(tài)擴展、彈性擴展這些。
路徑是什么？
我們認為它是利用云生的服務進行架構的設計，達到私有化部署無法達到的優(yōu)勢。如果說一個數(shù)據(jù)庫設計的時候是基于私有環(huán)境進行設計的,它只是放到云上面，那它就不是一個云原生數(shù)據(jù)庫。
我們再從用戶的視角看看什么是云原生數(shù)據(jù)庫？
PingCAP認為最主要的是彈性伸縮。用戶按照自己的需求，計算不足的時候擴計算，自動的進行縮容。根據(jù)用戶的實際需要擴展計算和存儲，實現(xiàn)彈性伸縮的能力。再有就是高性價比，云上總體的成本要低于云下部署的成本，最好能實現(xiàn)按需付費。
最后是安全合規(guī)，因為數(shù)據(jù)庫存儲的數(shù)據(jù)是公司的核心數(shù)據(jù)，如果安全合規(guī)做不到，那一切都是空談。
還有運維托管和點擊即用。在云上要提供非常便利的平臺，支持用戶各種自助操作，其實就是我們說DevOps以及AIOps，提升用戶運維管理的效率，在云上的時候，不需要預先準備資源。相反在云下，就需要先申請，還要走采購流程，走審批采購資源，這整個鏈路是非常長的。資源到位之后，也需要進行裝機、部署、上線、交付，這些都是以“天”作為維度，最快可能也就是幾個小時。但是在云上，可能就是點擊一下，可能秒級就實現(xiàn)了，用戶體驗會非常好。
前面我們介紹了云原生數(shù)據(jù)庫。下面我們介紹一下TiDB的云上托管平臺。
我們先介紹TiDB，TiDB長期在國內和全球獲得了認可，長期位于國內摩天輪數(shù)據(jù)庫排行榜的首位。在國際的DB-Engine排名里面，是中國唯一進入Top 100以及關鍵數(shù)據(jù)庫Top 50的榜單。并且我們在Ping CAP入選2022 Gartner云數(shù)據(jù)庫“客戶之聲”的獎項，獲得了用戶的認可，這是中國唯一入選的分布式運數(shù)據(jù)庫服務商。
TiDB分三塊。第一塊是計算集群，它是一個無狀態(tài)的，可實現(xiàn)彈性水平伸縮能力的組件，主要用來接收用戶請求，然后解析，然后下發(fā)到存儲層，給用戶進行反饋。
下面的TiKV和TiFlash是我們的存儲層。TiKV是行存，TiFlash是內存。兩者之間在物理上是隔離的，互不影響。TiKV用來實現(xiàn)線上高頻交易，也就是OLTP的負載，TiFlash主要用來做OLAP類查詢，這就是TiDB數(shù)據(jù)庫的主要能力。
右邊PD節(jié)點是用來管理我們的云數(shù)據(jù)的。簡單理解，它主要有兩個功能，一個是管理我們的數(shù)據(jù)，我們會把它的水平拆分成一個最小的管理節(jié)點。PD里面就是存儲這些信息，可以理解為它是一個路由信息，給TiDB提供路由的服務，TiDB就知道我的記錄會存儲在哪個里面，從而到相應的存儲里面去進行相關的操作。
從這個架構來看，它其實就是一個存儲、計算、分離的架構。可以實現(xiàn)水平擴展，并且是一個分布式HTAP數(shù)據(jù)庫。數(shù)據(jù)可以實現(xiàn)一致性，因為TiKV之間一般是3復本或者5復本這種一致性，可以實現(xiàn)數(shù)據(jù)的一致性，保證數(shù)據(jù)寫入之后，這個數(shù)據(jù)一定是不會丟失的，并且是兼容MySQL協(xié)議，降低用戶接入的成本。本質上就是一個云原生分布式數(shù)據(jù)庫。
下面我們再介紹一下TiDB的云上托管平臺，我們叫做TiDB Cloud。
它是云上的托管平臺，支持一鍵部署，擴容和縮容，以及相應的管理。并且它是一個多云池，是一個云中立的產品。在國外支持AWS，國內支持阿里云、京東云等。
業(yè)務的聯(lián)線是通過自動備份、多可用區(qū)復制來實現(xiàn)的自動備份是數(shù)據(jù)庫基本的功能。多可用區(qū)復制，TiDB作為一個分布式的數(shù)據(jù)庫，既然就是高可用的，自帶高可用，自動的實現(xiàn)容災。比如說在3個機房部署，在任何一個機房宕機都不會造成影響。
安全合規(guī)是云廠商的必修課，如果說安全合規(guī)做不到，客戶就不會放心把自己最核心的資產去使用的。如果數(shù)據(jù)泄露就會非常麻煩。TiDB獲得了多個國際的安全認證。
技術支持這塊，我們提供多種方式的支持，快速、高效的支撐體系。計費是最基本的要求，我們可以實現(xiàn)用戶按需使用，按需付費。
TiDB Cloud總體的架構大概是這樣子的，主要是基于云廠商提供的AWS服務，有統(tǒng)一的管控面。內部我們會提供單獨的VBC然后進行部署，然后通過Pooling的方式和用戶的應用進行打通，然后來進行數(shù)據(jù)庫服務的接入。
上云之后，可能只是開始。云原生是要基于云上基礎設施，然后來去不斷的優(yōu)化、迭代架構。所以下一步就有必要對云上服務商進行共生適配，來解決云下無法解決的一些痛點。
在云下，PingCAP已經(jīng)是一個存算分離的架構了。云原生，我們認為不管是實現(xiàn)資源池化，其實最重要的一點就是要實現(xiàn)存算分離，這個基本上是許多云上優(yōu)勢的前提。如果實現(xiàn)了存算分離，就可以實現(xiàn)更靈活的資源伸縮、彈性縮容，并且實現(xiàn)Serverless，這是一個基礎。
所以不管我們做成什么程度的Serverless，其實都是需要不斷的優(yōu)化的,就TiDB自身來看，它已經(jīng)是一個存儲計算分離的架構。Tikv作為存儲，TiDB作為計算，兩者都是一個集群模式，可以單獨的進行擴展。
在云下，我們的數(shù)據(jù)是拆分在不同的TiKV。
如果說TiKV，比如這個機器宕機了 ，那可能就要擴容一個機器，比如說3個復本，丟了1個復本，我們就要把另外1個復本補齊，這個成本其實相對來說是比較高的。在云上，比如說基于云上的云盤，比如EBS這種高性能的云盤。云上的話就不需要搬，可以省略這個過程了。就是因為機器宕機之后，EBS還是可用的。這樣的話我們申請另外一個機器，直接把EBS盤放上去就可以了，避免了云下需要補數(shù)據(jù)的過程，降低對用戶的影響，并且也降低宕機缺失復本的一個狀態(tài)。
當然這些夠了嗎？其實也不夠，因為云上還有更多的存儲的服務，比如說S3，它非常的廉價。后續(xù)我會介紹一下怎么和S3進行結合，來實現(xiàn)更徹底的存算分離。
TiFlash這個組件其實是存在耦合的，現(xiàn)在為了實現(xiàn)OLAP的實時性，也實現(xiàn)了MPP（并行處理）的能力。其實大量的計算都是在TiFlash上進行計算的，它就包括了數(shù)據(jù)的存儲，又包括數(shù)據(jù)計算，實際是一個存算耦合的狀態(tài)。這其實在云上，它不是一個非常理想的狀態(tài)，沒法按照需求，比如計算擴容或者存儲擴容。所以下一步我們要基于云上的EBS+S3對于TiFlash進行存算耦合。
TiKV進一步存算分離，下一步主要是想利用S3。簡單概括來說就是，將所有的全量數(shù)據(jù)全部下到S3。作為TiKV服務，如果在OLTP上面，它是低延時、高吞吐的附載,不適合放在S3上面，因為S3的延遲非常高，延遲可能是200～300毫秒以上了，并且沒法應對大并發(fā)，和OLTP服務看起來是完全不相干的，完全無法支持。
那么怎么解決呢？
我們也會把TiKV本地磁盤利用起來，會將TiKV上面的數(shù)據(jù)在本地緩存一份，這樣的話我們可以利用本地磁盤實現(xiàn)高吞吐、低延遲的OLTP請求。然后我們寫入，因為底層都分布的，如果需要合并的時候，只需要在TiKV主機端進行合并，合并完了之后通過S3發(fā)落到各個節(jié)點，然后實現(xiàn)這么一個過程。
可能有質疑會說：既然本地磁盤也存儲了TiKV上面的緩存數(shù)據(jù)，那成本會不會比較高呢？這個擔心也是有道理的，我們強調3復本，本地也會緩存數(shù)據(jù)。我們的考慮是，一是S3的成本非常低，它的成本可能是1/5～1/6。此前，3復本宕了1個復本之后，數(shù)據(jù)就要進行恢復和補齊，這個時間會非常長，如果這個過程中再宕1復本，將導致整個數(shù)據(jù)都不可用了。
但是基于S3的話，如果說宕了1個復本之后，它會快速的從S3里面把數(shù)據(jù)弄上來，這個時間可能補數(shù)據(jù)時間的1/10甚至幾十分之一。也就是說我們彈性的能力提升了幾十倍的增加，那我們可能不需要3個復本了，我們可能需要2個復本加一個S3的方式就可以了，這樣的話整體上也會降低成本，也節(jié)約了用戶的使用成本。
這就是TiKV進一步的存算分離。
下面我們也會把TiDB的各種服務進行拆分，只有充分的進行拆分，才能對各個功能進行擴展，然后選用合適的資源來承載，降低用戶的使用成本。
TiFlash存算分離，它的思路有些類似。后面更多服務解耦，不管是TiDB上面的DDL，DDL服務是一個非常重的服務，有可能會影響所在的TiDB節(jié)點的穩(wěn)定性。我們拆出來之后，根據(jù)需要來擴展它的能力。比如說Lock服務，以及授時服務、調度服務，我們都可以把它拆出來放在在云上。
最后是云端生態(tài)集成。我們在上游要和各個RDS、SQL Server兼容。在下游的話我們需要和大數(shù)據(jù)這一套結合，這些我們都在做的，以及和云廠商不斷的進行兼容，這一塊也是持續(xù)建設的一個過程。
下面我們看看典型的用戶案例。
第一個是日本某頭部移動支付公司的案例。他們是2018年成立的，之后因為用戶的快速擴展，用戶從1500萬增長到4000多萬的過程中，整個架構之前是基于java、Springboot架構來實現(xiàn)的。寫入這塊會出現(xiàn)明顯的瓶頸。并且如果要記錄的話只能分庫分表。這樣對用戶的業(yè)務上來說，快速發(fā)展，首先時間不允許，其次對業(yè)務的沖擊會比較大。業(yè)務需要進行分庫分表的改造，這個周期會非常長，投入大，產出其實也是比較有限的，嚴重阻礙了用戶的發(fā)展。所以用戶進行選型選到了PingCAP，服務主要是錢包服務業(yè)務，所有的線上服務都會通過錢包來服務。實現(xiàn)了60TB，高吞吐量，提升了5倍以上，滿足了用戶擴展性的需求。并且提供低延遲，整個延時比Aurofa要低30%，高吞吐。
對于用戶來說還有一個比較意外的收獲是，之前是基于高可用性，之前東京出現(xiàn)異常，當時TiDB什么也沒有做，在秒鐘內進行了恢復。之前用Aurofa用戶受影響就比較大，用戶有數(shù)據(jù)的丟失。但是TiDB只影響了15條信息的失敗，確保了跟用戶的粘性，這個對用戶來說體驗非常好，當時給我們這邊反饋說是一個非常意外的收獲。
第二個案例是網(wǎng)易游戲用戶畫像，主要是處理網(wǎng)易100多款游戲登陸支付數(shù)據(jù)。根據(jù)登陸日志統(tǒng)計用戶的活躍度，用戶畫像的服務。有各種指標，根據(jù)這些數(shù)據(jù)輸出實時的信息，比如總消費、時長、曲線、用戶的VIP等級等等。有這些數(shù)據(jù)之后就可以交給市場和營銷部門來進行精準的廣告推送，并且也會給用戶提供針對性的充值優(yōu)惠，以及推送各種新游戲。這樣的話將整個游戲的運營水平提升上來。用戶畫像其實是一個游戲運營中最核心的系統(tǒng)，他們之前是在MySQL上做的，之前可能一款游戲就是一套，之間都是割離的數(shù)據(jù)孤島，并且也無法滿足實時的查詢。
最后通過使用一套TiDB集群，將整個100多套游戲的數(shù)據(jù)全部存儲起來，然后為一線提供服務。主要是將多元數(shù)據(jù)進行匯聚，然后進行實時的查詢，實時的數(shù)據(jù)分析。同時為用戶畫像、報表監(jiān)控以及運營整個提供數(shù)據(jù)服務，整個是超過萬級別的。
并且也會提供計算層的，和大數(shù)據(jù)進行連通。這樣的話可以打通在線和大數(shù)據(jù)這塊，打破不同的技術戰(zhàn)的壁壘，為用戶實現(xiàn)價值最大化。
整體來說，對用戶的價值來說，架構比較簡單，一套TOB就能實現(xiàn)OLTP的查詢，又實現(xiàn)OLAP的數(shù)據(jù)分析，降低用戶的運營和使用成本。并且降低了整個鏈路，大數(shù)據(jù)鏈路，降低出風險的概率，提高可能性。同時，提供了準實時的數(shù)據(jù)分析能力。還有降低用戶的使用成本，整個資源投入產出比達到MySQL同等QPS的1.5倍。當前網(wǎng)易有90多套集群都已經(jīng)在使用TiDB了，總數(shù)量可能達到500多TP吧。
我今天的分享就到這里，謝謝大家！
（ 本文基于速記整理而成，未經(jīng)過本人審閱 ）
