我們先看左邊這個(gè)圖，我們以幾個(gè)典型的產(chǎn)品為例，比如MorgoDB Alats,他們?cè)粕系氖杖胧窃葡率杖肫胀?倍以上。其實(shí)在2022年前三季度,其云下收入已經(jīng)占了整體收入的2/3，是遠(yuǎn)高于私有化部署的。從MorgoDB視角來(lái)看，它的云上已經(jīng)是它的絕對(duì)的中心，占比占2/3，增速又是云下的56倍。這樣就能看到云上面的發(fā)展趨勢(shì)。

    我們?cè)倏搓P(guān)于數(shù)據(jù)庫(kù)，右邊的圖，我們能看到云上收入增速是非?？斓模瑩?jù)統(tǒng)計(jì)來(lái)看，它是云下增速的2倍以上, 2021年幾乎達(dá)到私有化部署收入的額度，在95%左右。預(yù)計(jì)2022年會(huì)超過(guò)私有化部署，這是全球的情況。國(guó)內(nèi)發(fā)展趨勢(shì)也是一樣的，云上增速也是云下增速的兩倍。預(yù)計(jì)國(guó)內(nèi)在2025年左右，云上、云下收入應(yīng)該會(huì)持平。

    云對(duì)數(shù)據(jù)庫(kù)廠商來(lái)說(shuō)是一個(gè)放大器，是觸達(dá)用戶最短的并且最高效的路徑，是直接溝通的一個(gè)平臺(tái),可以實(shí)現(xiàn)快速交付、反饋和迭代。從趨勢(shì)和效率上來(lái)看，數(shù)據(jù)庫(kù)廠商不上云很難活下來(lái)的。

    2022年對(duì)于PingCAP的TiDB數(shù)據(jù)庫(kù)來(lái)說(shuō)，是一個(gè)大力投入云服務(wù)的一年，是TiDB云的元年。PingCAP在今年開(kāi)始，已經(jīng)在云上為用戶提供正式數(shù)據(jù)庫(kù)服務(wù)。

    在2015年的時(shí)候，基本上沒(méi)有提云原生數(shù)據(jù)庫(kù)。但2019年的時(shí)候，最主要的議題就是云原生數(shù)據(jù)庫(kù)。當(dāng)然也包括數(shù)據(jù)分析決策，這也是云原生數(shù)據(jù)庫(kù)排在第一位的需求，所占篇幅最大。

首先看看云原生是什么？

按照云原生計(jì)算基金會(huì)(CNCF)的定義，云原生就是“云計(jì)算+自動(dòng)化管理+微服務(wù)”，但是對(duì)數(shù)據(jù)庫(kù)來(lái)說(shuō)，就不是那么好理解了。PingCAP認(rèn)為云原生最主要的就是實(shí)現(xiàn)資源的池化，實(shí)現(xiàn)數(shù)據(jù)計(jì)算、存儲(chǔ)、內(nèi)存的池化，可以實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)展、彈性擴(kuò)展這些。

路徑是什么？

我們認(rèn)為它是利用云生的服務(wù)進(jìn)行架構(gòu)的設(shè)計(jì)，達(dá)到私有化部署無(wú)法達(dá)到的優(yōu)勢(shì)。如果說(shuō)一個(gè)數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候是基于私有環(huán)境進(jìn)行設(shè)計(jì)的,它只是放到云上面，那它就不是一個(gè)云原生數(shù)據(jù)庫(kù)。

我們?cè)購(gòu)挠脩舻囊暯强纯词裁词窃圃鷶?shù)據(jù)庫(kù)？

PingCAP認(rèn)為最主要的是彈性伸縮。用戶按照自己的需求，計(jì)算不足的時(shí)候擴(kuò)計(jì)算，自動(dòng)的進(jìn)行縮容。根據(jù)用戶的實(shí)際需要擴(kuò)展計(jì)算和存儲(chǔ)，實(shí)現(xiàn)彈性伸縮的能力。再有就是高性價(jià)比，云上總體的成本要低于云下部署的成本，最好能實(shí)現(xiàn)按需付費(fèi)。

    最后是安全合規(guī)，因?yàn)閿?shù)據(jù)庫(kù)存儲(chǔ)的數(shù)據(jù)是公司的核心數(shù)據(jù)，如果安全合規(guī)做不到，那一切都是空談。

    還有運(yùn)維托管和點(diǎn)擊即用。在云上要提供非常便利的平臺(tái)，支持用戶各種自助操作，其實(shí)就是我們說(shuō)DevOps以及AIOps，提升用戶運(yùn)維管理的效率，在云上的時(shí)候，不需要預(yù)先準(zhǔn)備資源。相反在云下，就需要先申請(qǐng)，還要走采購(gòu)流程，走審批采購(gòu)資源，這整個(gè)鏈路是非常長(zhǎng)的。資源到位之后，也需要進(jìn)行裝機(jī)、部署、上線、交付，這些都是以“天”作為維度，最快可能也就是幾個(gè)小時(shí)。但是在云上，可能就是點(diǎn)擊一下，可能秒級(jí)就實(shí)現(xiàn)了，用戶體驗(yàn)會(huì)非常好。

前面我們介紹了云原生數(shù)據(jù)庫(kù)。下面我們介紹一下TiDB的云上托管平臺(tái)。

我們先介紹TiDB，TiDB長(zhǎng)期在國(guó)內(nèi)和全球獲得了認(rèn)可，長(zhǎng)期位于國(guó)內(nèi)摩天輪數(shù)據(jù)庫(kù)排行榜的首位。在國(guó)際的DB-Engine排名里面，是中國(guó)唯一進(jìn)入Top 100以及關(guān)鍵數(shù)據(jù)庫(kù)Top 50的榜單。并且我們?cè)赑ing CAP入選2022 Gartner云數(shù)據(jù)庫(kù)“客戶之聲”的獎(jiǎng)項(xiàng)，獲得了用戶的認(rèn)可，這是中國(guó)唯一入選的分布式運(yùn)數(shù)據(jù)庫(kù)服務(wù)商。

TiDB分三塊。第一塊是計(jì)算集群，它是一個(gè)無(wú)狀態(tài)的，可實(shí)現(xiàn)彈性水平伸縮能力的組件，主要用來(lái)接收用戶請(qǐng)求，然后解析，然后下發(fā)到存儲(chǔ)層，給用戶進(jìn)行反饋。

    下面的TiKV和TiFlash是我們的存儲(chǔ)層。TiKV是行存，TiFlash是內(nèi)存。兩者之間在物理上是隔離的，互不影響。TiKV用來(lái)實(shí)現(xiàn)線上高頻交易，也就是OLTP的負(fù)載，TiFlash主要用來(lái)做OLAP類查詢，這就是TiDB數(shù)據(jù)庫(kù)的主要能力。

    右邊PD節(jié)點(diǎn)是用來(lái)管理我們的云數(shù)據(jù)的。簡(jiǎn)單理解，它主要有兩個(gè)功能，一個(gè)是管理我們的數(shù)據(jù)，我們會(huì)把它的水平拆分成一個(gè)最小的管理節(jié)點(diǎn)。PD里面就是存儲(chǔ)這些信息，可以理解為它是一個(gè)路由信息，給TiDB提供路由的服務(wù)，TiDB就知道我的記錄會(huì)存儲(chǔ)在哪個(gè)里面，從而到相應(yīng)的存儲(chǔ)里面去進(jìn)行相關(guān)的操作。

從這個(gè)架構(gòu)來(lái)看，它其實(shí)就是一個(gè)存儲(chǔ)、計(jì)算、分離的架構(gòu)?？梢詫?shí)現(xiàn)水平擴(kuò)展，并且是一個(gè)分布式HTAP數(shù)據(jù)庫(kù)。數(shù)據(jù)可以實(shí)現(xiàn)一致性，因?yàn)門iKV之間一般是3復(fù)本或者5復(fù)本這種一致性，可以實(shí)現(xiàn)數(shù)據(jù)的一致性，保證數(shù)據(jù)寫入之后，這個(gè)數(shù)據(jù)一定是不會(huì)丟失的，并且是兼容MySQL協(xié)議，降低用戶接入的成本。本質(zhì)上就是一個(gè)云原生分布式數(shù)據(jù)庫(kù)。

下面我們?cè)俳榻B一下TiDB的云上托管平臺(tái)，我們叫做TiDB Cloud。

它是云上的托管平臺(tái)，支持一鍵部署，擴(kuò)容和縮容，以及相應(yīng)的管理。并且它是一個(gè)多云池，是一個(gè)云中立的產(chǎn)品。在國(guó)外支持AWS，國(guó)內(nèi)支持阿里云、京東云等。

    業(yè)務(wù)的聯(lián)線是通過(guò)自動(dòng)備份、多可用區(qū)復(fù)制來(lái)實(shí)現(xiàn)的自動(dòng)備份是數(shù)據(jù)庫(kù)基本的功能。多可用區(qū)復(fù)制，TiDB作為一個(gè)分布式的數(shù)據(jù)庫(kù)，既然就是高可用的，自帶高可用，自動(dòng)的實(shí)現(xiàn)容災(zāi)。比如說(shuō)在3個(gè)機(jī)房部署，在任何一個(gè)機(jī)房宕機(jī)都不會(huì)造成影響。

    安全合規(guī)是云廠商的必修課，如果說(shuō)安全合規(guī)做不到，客戶就不會(huì)放心把自己最核心的資產(chǎn)去使用的。如果數(shù)據(jù)泄露就會(huì)非常麻煩。TiDB獲得了多個(gè)國(guó)際的安全認(rèn)證。

    技術(shù)支持這塊，我們提供多種方式的支持，快速、高效的支撐體系。計(jì)費(fèi)是最基本的要求，我們可以實(shí)現(xiàn)用戶按需使用，按需付費(fèi)。

    TiDB Cloud總體的架構(gòu)大概是這樣子的，主要是基于云廠商提供的AWS服務(wù)，有統(tǒng)一的管控面。內(nèi)部我們會(huì)提供單獨(dú)的VBC然后進(jìn)行部署，然后通過(guò)Pooling的方式和用戶的應(yīng)用進(jìn)行打通，然后來(lái)進(jìn)行數(shù)據(jù)庫(kù)服務(wù)的接入。

    上云之后，可能只是開(kāi)始。云原生是要基于云上基礎(chǔ)設(shè)施，然后來(lái)去不斷的優(yōu)化、迭代架構(gòu)。所以下一步就有必要對(duì)云上服務(wù)商進(jìn)行共生適配，來(lái)解決云下無(wú)法解決的一些痛點(diǎn)。

在云下，PingCAP已經(jīng)是一個(gè)存算分離的架構(gòu)了。云原生，我們認(rèn)為不管是實(shí)現(xiàn)資源池化，其實(shí)最重要的一點(diǎn)就是要實(shí)現(xiàn)存算分離，這個(gè)基本上是許多云上優(yōu)勢(shì)的前提。如果實(shí)現(xiàn)了存算分離，就可以實(shí)現(xiàn)更靈活的資源伸縮、彈性縮容，并且實(shí)現(xiàn)Serverless，這是一個(gè)基礎(chǔ)。

    所以不管我們做成什么程度的Serverless，其實(shí)都是需要不斷的優(yōu)化的,就TiDB自身來(lái)看，它已經(jīng)是一個(gè)存儲(chǔ)計(jì)算分離的架構(gòu)。Tikv作為存儲(chǔ)，TiDB作為計(jì)算，兩者都是一個(gè)集群模式，可以單獨(dú)的進(jìn)行擴(kuò)展。

在云下，我們的數(shù)據(jù)是拆分在不同的TiKV。

如果說(shuō)TiKV，比如這個(gè)機(jī)器宕機(jī)了 ，那可能就要擴(kuò)容一個(gè)機(jī)器，比如說(shuō)3個(gè)復(fù)本，丟了1個(gè)復(fù)本，我們就要把另外1個(gè)復(fù)本補(bǔ)齊，這個(gè)成本其實(shí)相對(duì)來(lái)說(shuō)是比較高的。在云上，比如說(shuō)基于云上的云盤，比如EBS這種高性能的云盤。云上的話就不需要搬，可以省略這個(gè)過(guò)程了。就是因?yàn)闄C(jī)器宕機(jī)之后，EBS還是可用的。這樣的話我們申請(qǐng)另外一個(gè)機(jī)器，直接把EBS盤放上去就可以了，避免了云下需要補(bǔ)數(shù)據(jù)的過(guò)程，降低對(duì)用戶的影響，并且也降低宕機(jī)缺失復(fù)本的一個(gè)狀態(tài)。

當(dāng)然這些夠了嗎？其實(shí)也不夠，因?yàn)樵粕线€有更多的存儲(chǔ)的服務(wù)，比如說(shuō)S3，它非常的廉價(jià)。后續(xù)我會(huì)介紹一下怎么和S3進(jìn)行結(jié)合，來(lái)實(shí)現(xiàn)更徹底的存算分離。

TiFlash這個(gè)組件其實(shí)是存在耦合的，現(xiàn)在為了實(shí)現(xiàn)OLAP的實(shí)時(shí)性，也實(shí)現(xiàn)了MPP（并行處理）的能力。其實(shí)大量的計(jì)算都是在TiFlash上進(jìn)行計(jì)算的，它就包括了數(shù)據(jù)的存儲(chǔ)，又包括數(shù)據(jù)計(jì)算，實(shí)際是一個(gè)存算耦合的狀態(tài)。這其實(shí)在云上，它不是一個(gè)非常理想的狀態(tài)，沒(méi)法按照需求，比如計(jì)算擴(kuò)容或者存儲(chǔ)擴(kuò)容。所以下一步我們要基于云上的EBS+S3對(duì)于TiFlash進(jìn)行存算耦合。

TiKV進(jìn)一步存算分離，下一步主要是想利用S3。簡(jiǎn)單概括來(lái)說(shuō)就是，將所有的全量數(shù)據(jù)全部下到S3。作為TiKV服務(wù)，如果在OLTP上面，它是低延時(shí)、高吞吐的附載,不適合放在S3上面，因?yàn)镾3的延遲非常高，延遲可能是200～300毫秒以上了，并且沒(méi)法應(yīng)對(duì)大并發(fā)，和OLTP服務(wù)看起來(lái)是完全不相干的，完全無(wú)法支持。

那么怎么解決呢？

我們也會(huì)把TiKV本地磁盤利用起來(lái)，會(huì)將TiKV上面的數(shù)據(jù)在本地緩存一份，這樣的話我們可以利用本地磁盤實(shí)現(xiàn)高吞吐、低延遲的OLTP請(qǐng)求。然后我們寫入，因?yàn)榈讓佣挤植嫉模绻枰喜⒌臅r(shí)候，只需要在TiKV主機(jī)端進(jìn)行合并，合并完了之后通過(guò)S3發(fā)落到各個(gè)節(jié)點(diǎn)，然后實(shí)現(xiàn)這么一個(gè)過(guò)程。

可能有質(zhì)疑會(huì)說(shuō)：既然本地磁盤也存儲(chǔ)了TiKV上面的緩存數(shù)據(jù)，那成本會(huì)不會(huì)比較高呢？這個(gè)擔(dān)心也是有道理的，我們強(qiáng)調(diào)3復(fù)本，本地也會(huì)緩存數(shù)據(jù)。我們的考慮是，一是S3的成本非常低，它的成本可能是1/5～1/6。此前，3復(fù)本宕了1個(gè)復(fù)本之后，數(shù)據(jù)就要進(jìn)行恢復(fù)和補(bǔ)齊，這個(gè)時(shí)間會(huì)非常長(zhǎng)，如果這個(gè)過(guò)程中再宕1復(fù)本，將導(dǎo)致整個(gè)數(shù)據(jù)都不可用了。

但是基于S3的話，如果說(shuō)宕了1個(gè)復(fù)本之后，它會(huì)快速的從S3里面把數(shù)據(jù)弄上來(lái)，這個(gè)時(shí)間可能補(bǔ)數(shù)據(jù)時(shí)間的1/10甚至幾十分之一。也就是說(shuō)我們彈性的能力提升了幾十倍的增加，那我們可能不需要3個(gè)復(fù)本了，我們可能需要2個(gè)復(fù)本加一個(gè)S3的方式就可以了，這樣的話整體上也會(huì)降低成本，也節(jié)約了用戶的使用成本。

這就是TiKV進(jìn)一步的存算分離。

下面我們也會(huì)把TiDB的各種服務(wù)進(jìn)行拆分，只有充分的進(jìn)行拆分，才能對(duì)各個(gè)功能進(jìn)行擴(kuò)展，然后選用合適的資源來(lái)承載，降低用戶的使用成本。

 TiFlash存算分離，它的思路有些類似。后面更多服務(wù)解耦，不管是TiDB上面的DDL，DDL服務(wù)是一個(gè)非常重的服務(wù)，有可能會(huì)影響所在的TiDB節(jié)點(diǎn)的穩(wěn)定性。我們拆出來(lái)之后，根據(jù)需要來(lái)擴(kuò)展它的能力。比如說(shuō)Lock服務(wù)，以及授時(shí)服務(wù)、調(diào)度服務(wù)，我們都可以把它拆出來(lái)放在在云上。

最后是云端生態(tài)集成。我們?cè)谏嫌我透鱾€(gè)RDS、SQL Server兼容。在下游的話我們需要和大數(shù)據(jù)這一套結(jié)合，這些我們都在做的，以及和云廠商不斷的進(jìn)行兼容，這一塊也是持續(xù)建設(shè)的一個(gè)過(guò)程。

下面我們看看典型的用戶案例。

第一個(gè)是日本某頭部移動(dòng)支付公司的案例。他們是2018年成立的，之后因?yàn)橛脩舻目焖贁U(kuò)展，用戶從1500萬(wàn)增長(zhǎng)到4000多萬(wàn)的過(guò)程中，整個(gè)架構(gòu)之前是基于java、Springboot架構(gòu)來(lái)實(shí)現(xiàn)的。寫入這塊會(huì)出現(xiàn)明顯的瓶頸。并且如果要記錄的話只能分庫(kù)分表。這樣對(duì)用戶的業(yè)務(wù)上來(lái)說(shuō)，快速發(fā)展，首先時(shí)間不允許，其次對(duì)業(yè)務(wù)的沖擊會(huì)比較大。業(yè)務(wù)需要進(jìn)行分庫(kù)分表的改造，這個(gè)周期會(huì)非常長(zhǎng)，投入大，產(chǎn)出其實(shí)也是比較有限的，嚴(yán)重阻礙了用戶的發(fā)展。所以用戶進(jìn)行選型選到了PingCAP，服務(wù)主要是錢包服務(wù)業(yè)務(wù)，所有的線上服務(wù)都會(huì)通過(guò)錢包來(lái)服務(wù)。實(shí)現(xiàn)了60TB，高吞吐量，提升了5倍以上，滿足了用戶擴(kuò)展性的需求。并且提供低延遲，整個(gè)延時(shí)比Aurofa要低30%，高吞吐。

對(duì)于用戶來(lái)說(shuō)還有一個(gè)比較意外的收獲是，之前是基于高可用性，之前東京出現(xiàn)異常，當(dāng)時(shí)TiDB什么也沒(méi)有做，在秒鐘內(nèi)進(jìn)行了恢復(fù)。之前用Aurofa用戶受影響就比較大，用戶有數(shù)據(jù)的丟失。但是TiDB只影響了15條信息的失敗，確保了跟用戶的粘性，這個(gè)對(duì)用戶來(lái)說(shuō)體驗(yàn)非常好，當(dāng)時(shí)給我們這邊反饋說(shuō)是一個(gè)非常意外的收獲。

第二個(gè)案例是網(wǎng)易游戲用戶畫像，主要是處理網(wǎng)易100多款游戲登陸支付數(shù)據(jù)。根據(jù)登陸日志統(tǒng)計(jì)用戶的活躍度，用戶畫像的服務(wù)。有各種指標(biāo)，根據(jù)這些數(shù)據(jù)輸出實(shí)時(shí)的信息，比如總消費(fèi)、時(shí)長(zhǎng)、曲線、用戶的VIP等級(jí)等等。有這些數(shù)據(jù)之后就可以交給市場(chǎng)和營(yíng)銷部門來(lái)進(jìn)行精準(zhǔn)的廣告推送，并且也會(huì)給用戶提供針對(duì)性的充值優(yōu)惠，以及推送各種新游戲。這樣的話將整個(gè)游戲的運(yùn)營(yíng)水平提升上來(lái)。用戶畫像其實(shí)是一個(gè)游戲運(yùn)營(yíng)中最核心的系統(tǒng)，他們之前是在MySQL上做的，之前可能一款游戲就是一套，之間都是割離的數(shù)據(jù)孤島，并且也無(wú)法滿足實(shí)時(shí)的查詢。

最后通過(guò)使用一套TiDB集群，將整個(gè)100多套游戲的數(shù)據(jù)全部存儲(chǔ)起來(lái)，然后為一線提供服務(wù)。主要是將多元數(shù)據(jù)進(jìn)行匯聚，然后進(jìn)行實(shí)時(shí)的查詢，實(shí)時(shí)的數(shù)據(jù)分析。同時(shí)為用戶畫像、報(bào)表監(jiān)控以及運(yùn)營(yíng)整個(gè)提供數(shù)據(jù)服務(wù)，整個(gè)是超過(guò)萬(wàn)級(jí)別的。

并且也會(huì)提供計(jì)算層的，和大數(shù)據(jù)進(jìn)行連通。這樣的話可以打通在線和大數(shù)據(jù)這塊，打破不同的技術(shù)戰(zhàn)的壁壘，為用戶實(shí)現(xiàn)價(jià)值最大化。

整體來(lái)說(shuō)，對(duì)用戶的價(jià)值來(lái)說(shuō)，架構(gòu)比較簡(jiǎn)單，一套TOB就能實(shí)現(xiàn)OLTP的查詢，又實(shí)現(xiàn)OLAP的數(shù)據(jù)分析，降低用戶的運(yùn)營(yíng)和使用成本。并且降低了整個(gè)鏈路，大數(shù)據(jù)鏈路，降低出風(fēng)險(xiǎn)的概率，提高可能性。同時(shí)，提供了準(zhǔn)實(shí)時(shí)的數(shù)據(jù)分析能力。還有降低用戶的使用成本，整個(gè)資源投入產(chǎn)出比達(dá)到MySQL同等QPS的1.5倍。當(dāng)前網(wǎng)易有90多套集群都已經(jīng)在使用TiDB了，總數(shù)量可能達(dá)到500多TP吧。

    我今天的分享就到這里，謝謝大家！

（ 本文基于速記整理而成，未經(jīng)過(guò)本人審閱 ）

songjy