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