5月29日， DataFunSummit——多維分析架構(gòu)峰會“HTAP 引擎論壇”如約而至，本論壇由騰訊云數(shù)據(jù)庫技術(shù)總監(jiān)李躍森老師出品。同時，論壇上，騰訊云數(shù)據(jù)庫高級工程師陳再妮帶來了主題為“TDSQL在HTAP領(lǐng)的探索與實踐”的演講分享，以下為分享回顧。
隨著信息技術(shù)的不斷發(fā)展，同時驅(qū)動催生許多新的業(yè)務(wù)場景，數(shù)據(jù)庫領(lǐng)域也不例外。在當(dāng)前大數(shù)據(jù)、云計算等信息化技術(shù)推動下，數(shù)據(jù)庫誕生許多類型。關(guān)于數(shù)據(jù)庫的分類，第一種分類方式是，可以按照數(shù)據(jù)庫的業(yè)務(wù)場景劃分。一般我們在談?wù)摂?shù)據(jù)庫的時候，首先會問數(shù)據(jù)庫是OLAP還是OLTP？OLAP，即在線分析型處理。OLAP的第一個特點是數(shù)據(jù)量比較大，一般會要求PB級或者更大的數(shù)據(jù)量，數(shù)據(jù)量大了以后，對存儲的成本會比較敏感，對數(shù)據(jù)壓縮也會有一定的要求。OLAP業(yè)務(wù)系統(tǒng)的并發(fā)量不會特別的高，但OLAP場景下查詢一般都會比較復(fù)雜，每個查詢需要消耗大量的資源，會要求多個用戶之間的查詢要減少相互之間的影響，進(jìn)行資源隔離。類似產(chǎn)品還是比較多的，比如:TeraData、SybaseIQ、GreenPlum、HP Vetica、AWS Redshift，以及現(xiàn)在比較流行的ClickHouse等。OLTP，即在線事務(wù)型處理。在線事務(wù)處理數(shù)據(jù)量相對較小，普遍時延要求高并發(fā)低時延。OLTP業(yè)務(wù)系統(tǒng)都是我們核心的業(yè)務(wù)系統(tǒng)，包括銀行、保險、電信這樣的實時在線的業(yè)務(wù)，業(yè)務(wù)特點決定對容災(zāi)能力有一些突出的要求，一般來講要求99.999%以上的可用性。傳統(tǒng)上來講，我們一般講數(shù)據(jù)庫都是指：Oracle、IBM DB2、Informix、MySQL，以及PostgreSQL這樣的一些數(shù)據(jù)庫。這兩年還興起一個數(shù)據(jù)庫概念叫做HTAP，即混合事務(wù)處理和在線分析型數(shù)據(jù)庫。基本的思路是能夠在單集群內(nèi)部同時處理OLAP和OLTP兩類業(yè)務(wù)。
數(shù)據(jù)庫的架構(gòu)經(jīng)過多年的演進(jìn)，大概有三種架構(gòu)。第一種是單體數(shù)據(jù)庫，所謂單體數(shù)據(jù)庫就像之前我們經(jīng)常提到的Oracle、PostgreSQL、MySQL這種單機(jī)的數(shù)據(jù)庫，單個實例能夠提供獨立的服務(wù)，主備機(jī)通過流復(fù)制來做HA，這是傳統(tǒng)的架構(gòu)。第二種是共享存儲架構(gòu)，多個數(shù)據(jù)庫實例同時訪問一份存儲，數(shù)據(jù)是存儲在專門的存儲設(shè)備中，這里的存儲設(shè)備一般是指磁盤陣列或者類似于這樣專用的存儲設(shè)備，Oracle RAC是典型這樣的架構(gòu)。第三種是無共享，也就是我們常說的MPP。每個DN節(jié)點存儲一個數(shù)據(jù)分片，在DN節(jié)點之上會有另外一層節(jié)點，這層節(jié)點在不同的數(shù)據(jù)庫中有不同的名字，但是它的作用其實是一樣的，都是接收業(yè)務(wù)請求，然后分發(fā)，同時對業(yè)務(wù)請求進(jìn)行返回。TeraData、GreenPlum、TDSQL都是屬于這種架構(gòu)。
MPP的架構(gòu)在實現(xiàn)上又可以分為有共享master和無共享master 2類：有共享master的架構(gòu)，應(yīng)用程序連接master進(jìn)行訪問，典型的代表產(chǎn)品有Greenplum、Netezza。無共享master的都會有多個對等的訪問入口節(jié)點供前端應(yīng)用程序連接訪問，典型的代表產(chǎn)品有teradata,hp vertica, TDSQL也是屬于無master架構(gòu)。相對于共享Master架構(gòu)來說，無共享Master結(jié)構(gòu)有幾個特點：- 可通過任意節(jié)點查詢或者加載數(shù)據(jù)
MPP架構(gòu)的數(shù)據(jù)庫與以hadoop/SPARK為代表的大數(shù)據(jù)系統(tǒng)的區(qū)別在于：大數(shù)據(jù)技術(shù)主要解決的是處理大數(shù)據(jù)容量，一般可到PB級甚至EB級的數(shù)據(jù)量，其絕大多數(shù)是非結(jié)構(gòu)化/半結(jié)構(gòu)化類型的數(shù)據(jù)，機(jī)器規(guī)模可達(dá)到上千上萬臺，在批處理、流處理方面有優(yōu)勢。但在關(guān)聯(lián)分析領(lǐng)域仍有不足，市場上鮮少有可集成的分析軟件。而MPP解決的主要是結(jié)構(gòu)化數(shù)據(jù)，在穩(wěn)定性、事務(wù)ACID嚴(yán)格性、復(fù)雜數(shù)據(jù)處理、關(guān)聯(lián)分析、響應(yīng)速度等方面具有傳統(tǒng)優(yōu)勢，其靈活的數(shù)據(jù)分析能力，方便與各種分析軟件集成。MPP架構(gòu)的數(shù)據(jù)庫，使用主要是SQL，因此對使用人員培訓(xùn)簡單，擁有成熟的人才市場。而相對來說大數(shù)據(jù)技術(shù)對使用人員技能要求較高，學(xué)習(xí)成本也會更高。企業(yè)用戶可結(jié)合自己的業(yè)務(wù)特點選擇適合自己的技術(shù)。
1
一、分布式數(shù)據(jù)庫TDSQL-PG簡介
TDSQL-PG 是騰訊基于開源PostgreSQL自主研發(fā)的新一代分布式企業(yè)級HTAP數(shù)據(jù)庫引擎，全面兼容 PostgreSQL，高度兼容 Oracle 語法。產(chǎn)品采用無共享架構(gòu)，支持行列混合存儲，在提供大型數(shù)據(jù)倉庫處理能力的同時還能完整支持分布式事務(wù)ACID能力。
TDSQL-PG經(jīng)歷10余年打磨，可以分為如下幾個階段：單機(jī)時代，作為騰訊大數(shù)據(jù)平臺TDW的一個補(bǔ)充，彌補(bǔ)了小數(shù)據(jù)分析能力的不足；隨著業(yè)務(wù)的發(fā)展，單機(jī)PostgreSQL的瓶頸逐步凸顯，促使團(tuán)隊推出具有良好擴(kuò)展性和SQL兼容能力的V1版本，并在2015年春節(jié)上線微信支付商戶系統(tǒng)。后來，TDSQL-PG面向企業(yè)市場開放，在V2版本內(nèi)核支持三權(quán)分立，加密脫敏等多項安全特性，在2018年實現(xiàn)數(shù)字廣東等多個標(biāo)桿客戶應(yīng)用；TDSQL-PG V3版本定位HTAP，并在2019年上線PICC集團(tuán)核心業(yè)務(wù)。去年發(fā)布的V5版本內(nèi)核具備Oracle兼容和讀寫分功能，并投產(chǎn)上線運(yùn)營商系統(tǒng)。
- 第一個是業(yè)務(wù)特征，如果業(yè)務(wù)滿足這些特征，那TDSQL-PG是非常適合的——在數(shù)據(jù)量上，OLTP超過1T，OLAP場景數(shù)據(jù)量超過5T；并發(fā)連接數(shù)超過2000，峰值業(yè)務(wù)100w/s；需要在線水平擴(kuò)展能力；此外還需要同事兼顧OLTP以及OLAP的HTAP場景；并且需要嚴(yán)格的分布式事務(wù)保證；
- 第二個是業(yè)務(wù)的場景，TDSQL-PG在HTAP場景、地理信息系統(tǒng)，以及實時高并發(fā)、數(shù)據(jù)庫國產(chǎn)化等場景也是很好的選擇。
TDSQL-PG采用share nothing的MPP架構(gòu)，具備良好的擴(kuò)展性和性能。其整體物理架構(gòu)分三個部分：圖中的左側(cè)上層GTM是事務(wù)管理器，它主要是提供全局事務(wù)的信息，同時管理全局對象。另外圖中右側(cè)上層Coordinator（協(xié)調(diào)節(jié)點CN），它主要提供業(yè)務(wù)訪問入口。協(xié)調(diào)節(jié)點中每個節(jié)點之間是對等的，也就是說業(yè)務(wù)訪問這三個節(jié)點里面的任何一個，它得到的結(jié)果都會是相同的，而且訪問這個節(jié)點，事務(wù)的一致性能夠得到保證。圖中間的數(shù)據(jù)交互總線將整個分布式集群的各個節(jié)點的數(shù)據(jù)有機(jī)的聯(lián)合起來，負(fù)責(zé)整個集群中所有節(jié)點數(shù)據(jù)的交互。圖中下層是數(shù)據(jù)節(jié)點，數(shù)據(jù)節(jié)點有些是我們實際存儲數(shù)據(jù)的地方；每個數(shù)據(jù)節(jié)點會存儲一份本地的Local元數(shù)據(jù)，同時還有本地的數(shù)據(jù)分片，所有數(shù)據(jù)分片組合起來形成完整的用戶數(shù)據(jù)集。最左邊和最下層主要是管控系統(tǒng)的功能，負(fù)責(zé)對集群節(jié)點資源分配，監(jiān)控告警、運(yùn)維管理等。
分布式數(shù)據(jù)庫關(guān)心的一個很重要的問題就是查詢問題，在MPP架構(gòu)下每個DN的數(shù)據(jù)都是不完整的。為了完成一個完整的分布式查詢，需要對策略進(jìn)行選擇。
這里策略主要有兩種：一種是PUSH QUERY，通過把它的查詢下推到DN節(jié)點上去， SQL在DN上執(zhí)行，把數(shù)據(jù)返回給CN。另外一種方式就是PULL DATA，也就是通過把DN節(jié)點上的數(shù)據(jù)拉取到CN上通過CN來完成所有的計算。數(shù)據(jù)量較大的時候， PUSH QUERY效率會高很多，PULL DATA在一些數(shù)據(jù)量比較小的時候，效率會比較好。TDSQL-PG里面兩種方式都會有，真正執(zhí)行時會根據(jù)優(yōu)化器來選擇PUSH QUERY或者PULL DATA。
在業(yè)務(wù)分析場景下，通常會有 2 個或者多個表關(guān)聯(lián)(join)的邏輯，這個在單機(jī)實例 中，是一個簡單的操作，但是在集群模式下，由于數(shù)據(jù)分布在 1 個或者多個物理節(jié)點中，處理起來也會相對復(fù)雜。在很多分布式解決方案中，join 會把數(shù)據(jù)拉取到一個節(jié)點，進(jìn)行關(guān)聯(lián)計算，這樣不僅耗費了大量的網(wǎng)絡(luò)資源，而且語句的耗時會很高。TDSQL-PG通過多種方式來對 分布式 join 進(jìn)行高效的計算。下面我們來簡單介紹一下 TDSQL-PG分布式 join 的實現(xiàn)原理。
為了介紹原理，我們通過兩張表舉例子。其中 TBL_A 有兩列 f1，f2，其中 f1 為分布 key， TBL_B 也有兩列 f1，f2，其中 f1 也為其分布 key。
join 可下推到數(shù)據(jù)節(jié)點的情況，可分為如下兩類情況：參與 join 的兩張表的 join key 與表的分布 key 相同時，join 可以下推到數(shù)據(jù)節(jié)點進(jìn)行，例如示例的 SQL 參與 join 的 key 為 TBL_A.f1 以及 TBL_B.f1，這兩個 key 也分別為 TBL_A、TBL_B 的分布 key，由于不同的表的數(shù)據(jù)分布算法是一致的，那么同一 id 的數(shù)據(jù)位于同一個節(jié)點中，那么每個節(jié)點單獨完成 join 過程，將結(jié)果進(jìn)行匯總即可。分布表與復(fù)制表的關(guān)聯(lián)，我們假設(shè) TBL_A 很大，但是 TBL_B 表為一張小表，那么也可以用到 TDSQL-PG的復(fù)制表特性，將 TBL_B 定義為復(fù)制表，那么 TBL_B 在每個數(shù)據(jù)節(jié)點都有一個完整的副本，join 也是可以下推到每個數(shù)據(jù)節(jié)點自行進(jìn)行 join 計算， TDSQL-PG的協(xié)調(diào)節(jié)點完成結(jié)果的匯總。 接下來討論最復(fù)雜，也就是 join 不可下推的場景：兩張表 TBL_A，TBL_B 數(shù) 據(jù)量都很大，執(zhí)行的語句為:select * from TBL_A join TBL_B on TBL_A.f1 = TBL_B.f2;該語句不滿足前面提到的可下推的兩種情況，也即B表 join key 與 分布 key 不一致，也不存在一張小表。前文提到了很多分布式解決方案會把數(shù)據(jù)拉取到一個節(jié)點，進(jìn)行關(guān)聯(lián)計算，TDSQL-PG并沒有采用這種耗費資源且性能不高的方法。那么 TDSQL-PG是如何處理這種情況的呢?在介紹處理方式之前，先介紹一下 TDSQL-PG的分布式執(zhí)行原理。首先在執(zhí)行方式上， 協(xié)調(diào)節(jié)點接收到用戶的 SQL 請求，會根據(jù)收集到的集群的統(tǒng)計信息，生成最優(yōu)的集群級的分布式查詢計劃，并下發(fā)到參與計算的數(shù)據(jù)節(jié)點上進(jìn)行執(zhí)行，也就是說協(xié)調(diào)節(jié)點下發(fā)的是執(zhí)行計劃，數(shù)據(jù)節(jié)點負(fù)責(zé)執(zhí)行該計劃。在數(shù)據(jù)交互上，數(shù)據(jù)節(jié)點之間建立了高效數(shù)據(jù)交換通道，數(shù)據(jù)節(jié)點之間可以高效的進(jìn)行交換數(shù)據(jù)，這個數(shù)據(jù)交換的過程在 TDSQL-PG里 稱之數(shù)據(jù)重分布(data redistribution)。有了高效的全局查詢計劃以及數(shù)據(jù)重分布的技術(shù)支撐，TDSQL-PG就能很容易的發(fā)揮并行計算的優(yōu)勢，高效的完成 join 的過程。而在這個例子里面是按照B表的f2字段來進(jìn)行重分布，來完成整個查詢的。為了在一套集群里同時實現(xiàn) OLTP 以及 OLAP 的融合，那么我們需要做到以下幾點：- OLAP 以及 OLTP 業(yè)務(wù)訪問的是同一份數(shù)據(jù)；
- 資源隔離，保證 OLAP 業(yè)務(wù)不影響 OLTP 業(yè)務(wù)的性能；
- 可以針對 OLTP 以及 OLAP 業(yè)務(wù)做不同的優(yōu)化。
TDSQL-PG為了實現(xiàn) OLAP 及 OLTP 的融合采用了如下圖的方案，核心思想有如下幾點:
- 在集群的 coordinator 節(jié)點提供 OLTP 以及 OLAP 兩個平面視角。
- OLTP 業(yè)務(wù)運(yùn)行在 datanode 主節(jié)點上，OLAP 業(yè)務(wù)運(yùn)行在 datanode 節(jié)點的備節(jié) 點上，二者的數(shù)據(jù)同步采用流復(fù)制的方式來進(jìn)行。
- 內(nèi)核優(yōu)化器會根據(jù)查詢所在的平面選用對應(yīng)的優(yōu)化器。
- OLTP 以及 OLAP 平面針對不同的負(fù)載采用合適的存儲格式。
作為HTAP系統(tǒng)，TDSQL-PG是支持行列混合存儲的：- 按行存儲格式，數(shù)據(jù)按照邏輯順序相同的方式來來進(jìn)行文件存儲，一行中的所有列數(shù)據(jù)按照順序存儲在物理磁盤上，這種格式的好處很明顯——如果同時訪問一行中的多列數(shù)據(jù)時，一 般只需要一次磁盤 IO，比較適合 OLTP 類型的負(fù)載。
- 按列存儲格式，表中的每列數(shù)據(jù)存儲為一個獨立的磁盤文件，比如例子中，“姓名”， “部門”，“年齡”……每列中的數(shù)據(jù)都為一個獨立的數(shù)據(jù)文件，這種格式在一次需要訪問表中少數(shù)列時相比行存能夠節(jié)省大量的磁盤 IO，在聚合類場景下尤其高效，因此多用在 OLAP 類系統(tǒng)中。
行存儲是 TDSQL-PG的基本存儲格式，為了支持高效的 OLAP ，TDSQL-PG也提供了完整的列存混合儲能力，業(yè)務(wù)可以根據(jù)自己的需要對寫入數(shù)據(jù)庫中的數(shù)據(jù)選擇需要的存儲格式。第一種是輕量式壓縮。輕量式壓縮方式首先感知到數(shù)據(jù)的具體內(nèi)容，從而針對數(shù)據(jù)的特點來選用不同的壓縮辦法提高壓縮比，降低業(yè)務(wù)的成本，當(dāng)前我們支持RLE的壓縮方式。
第二種是透明壓縮。這種壓縮方式是直接使用包括zstd和gzip直接進(jìn)行壓縮，這種壓縮對數(shù)據(jù)的存儲內(nèi)容沒有明確的要求，可以對任何的信息進(jìn)行壓縮。通過數(shù)據(jù)壓縮，可以把數(shù)據(jù)的體積大幅度減少，一方面減少用戶的使用成本，另一方面可以在大量查詢分析的時候減少IO訪問量，提升我們的查詢效率。
在執(zhí)行引擎這一層，TDSQL-PG在調(diào)研了業(yè)界的技術(shù)趨勢和技術(shù)的發(fā)展方向之后，在引擎里引入了延遲物化。相對于延遲物化，就是一般常見的提前物化。提前物化就是左邊圖所示的這樣，一開始所需要的投影列和join列都掃描傳遞上去，這種尤其在選擇率非常低時會造成內(nèi)存cache和網(wǎng)絡(luò)中非常多的無效數(shù)據(jù)，增大了cache miss和降低網(wǎng)絡(luò)數(shù)據(jù)數(shù)據(jù)交換的效率。延遲物化會在下層進(jìn)行Scan的時候，將需要join的列和物理元組的位置信息傳到上層節(jié)點。只有等上層節(jié)點完成Join關(guān)聯(lián)后，在投影階段再根據(jù)滿足條件的記錄的位置信息從下層拉取需要的數(shù)據(jù)信息，進(jìn)而透到外面，從而達(dá)到構(gòu)建元組屬性最少、生成元組最少的效果，這種方式可以大幅度地減少cache miss，節(jié)省CPU的計算開銷和網(wǎng)絡(luò)IO的開銷。
對數(shù)據(jù)庫來說最關(guān)鍵的一點的無疑是高性能計算。以下介紹TDSQL PG在高速并行計算方面的工作。
第一層節(jié)點級并行：所謂節(jié)點級的并行是，系統(tǒng)拿到一個查詢之后，會把查詢分發(fā)給各個不同的DN，通過DN之間分片區(qū)的查詢來完成節(jié)點級并行；
第二是進(jìn)程級并行：執(zhí)行器拿到分配后把算子并行化，即盡量使用允許更多CPU資源來完成查詢工作，通過多CPU方式提升查詢的效率；
第三層是指令級并行：包括對于CPU的特殊指令、SMD指令等，通過簡單的算術(shù)運(yùn)算或者求值，以及通過指定值的優(yōu)化和并行來提升查詢效率。
TDSQL-PG 通過這三層并行去滿足復(fù)雜查詢、實時計算的高性能要求。
在分布式場景下，我的數(shù)據(jù)在集群里面如何分布，怎么把數(shù)據(jù)分片存在我們的分布式集群的各個節(jié)點里面去，TDSQL-PG里面叫選擇表的分布類型，當(dāng)前支持2種：第一種是復(fù)制表，在集群里面的指定節(jié)點上，每個節(jié)點都會有數(shù)據(jù)的完整副本，這樣的表特別適合一些變化比較小的小表，對于一些關(guān)聯(lián)查詢的加速查詢是比較有用的。第二種是HASH分布表，就是把數(shù)據(jù)寫入的存儲節(jié)點時進(jìn)行hash打散到不同的節(jié)點上去。
但是TDSQL-PG的hash表的數(shù)據(jù)分布和其他數(shù)據(jù)庫都不一樣：其他數(shù)據(jù)庫系統(tǒng)一般都是按照分布鍵的值hash后對DN節(jié)點hash取余后存入對應(yīng)DN節(jié)點，但是TDSQL-PG在數(shù)據(jù)路由上引入了shard map，取余分母的不是真正的DN節(jié)點數(shù)而是shard數(shù)（一般為2048或者4096，遠(yuǎn)大于節(jié)點數(shù)），這樣計算出來的值我們叫做shardid, 每個DN節(jié)點對應(yīng)有哪些shardid，我們通過shardmap進(jìn)行存儲。比如這個例子里面的shard數(shù)是2048，有2個DN節(jié)點，DN1上存儲奇數(shù)的sharedid數(shù)據(jù)，DN2上存儲偶數(shù)的shardid數(shù)據(jù)。為什么這么做呢，因為考慮到后續(xù)的一個擴(kuò)容問題。
其他數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)分布方式，在進(jìn)行擴(kuò)容時因為新加了DN3節(jié)點，系統(tǒng)的node數(shù)量發(fā)生了變化，因此數(shù)據(jù)路由方式也會發(fā)生變化，系統(tǒng)中已有的所有數(shù)據(jù)要重新按照新路由方式進(jìn)行hash reblance,當(dāng)數(shù)據(jù)量比較大時，這個過程會比較久，而且這個過程是需要阻塞前端業(yè)務(wù)寫入的。TDSQL-PG因為引入了shard map，擴(kuò)容新加了DN3后，只需將原有DN1和DN2上的某些shardid（在這個例子中是s03 s04）數(shù)據(jù)搬遷過來就行，其他不相關(guān)的shardid不發(fā)生任何變化，這個過程前端業(yè)務(wù)可以正常寫入，shard搬遷在拷貝完s03 s04存量后可以自動追新寫入的增量數(shù)據(jù)，當(dāng)追上后刷新一下shard map的路由信息，將s03 s04的映射到新加DN3節(jié)點。后續(xù)訪問到這個shard信息時去DN3獲取。此過程對業(yè)務(wù)完全透明，不影響業(yè)務(wù)的正常寫入。通過上述的這種方式，TDSQL-PG可以方便地做到彈性擴(kuò)容、縮容、負(fù)載均衡，而且可以做到此過程完全業(yè)務(wù)無感知。
在數(shù)據(jù)治理方面，因為TDSQL PG支持range、list 、hash 、高性能等間隔分區(qū)。TDSQL-PG可通過分區(qū)表的方式，將不同子分區(qū)存儲到不同的節(jié)點組，不同節(jié)點組關(guān)聯(lián)著不同的機(jī)器。通過這樣的方案可以將熱數(shù)據(jù)存儲在配置好的機(jī)器上，冷數(shù)據(jù)存儲在稍微差點的機(jī)器上，以此來實現(xiàn)冷熱數(shù)據(jù)的分級存儲，降低用戶數(shù)據(jù)的存儲成本。
1. 微信支付
TDSQL-PG是在2015年初替換微信支付原有分庫分表集群上線，支撐微信支付從每天500萬筆到每天超過10億筆，保證業(yè)務(wù)穩(wěn)定性和連續(xù)性 ，這里就使用到了數(shù)據(jù)治理功能。圖中最上面是我們CLB，是騰訊內(nèi)部的一個負(fù)載均衡的組件。CLB下面是我們的接入節(jié)點CN。在DN數(shù)據(jù)存儲上近4個月的數(shù)據(jù)存儲在配置好的設(shè)備上主要使用的是SSD的設(shè)備，保證數(shù)據(jù)訪問性能，4個月前的數(shù)據(jù)存儲在普通設(shè)備上降低了存儲成本。此外還用了大小商戶策略，解決不同體量商戶數(shù)據(jù)傾斜問題，有效保證系統(tǒng)的穩(wěn)定運(yùn)行。通過這種方式之后，把我們整個業(yè)務(wù)成本降低到了四分之一左右，幫助業(yè)務(wù)降低四分之三的成本。
在外部我們有一個比較大的保險公司，然后上線了非常多的實例在跑保險的核心業(yè)務(wù)，這里只展示了我們的部署架構(gòu)。我們分為兩個平面，一個是讀寫平面，一個是只讀平面。讀寫平面，業(yè)務(wù)通過VIP來提供讀寫能力。我們的只讀平面通過業(yè)務(wù)VIP在多個節(jié)點做負(fù)載均衡，提供一個業(yè)務(wù)的只讀能力。TDSQL-PG的數(shù)據(jù)在生成之后，我們還需要把這個數(shù)據(jù)同步到我們其他的一些系統(tǒng)里面去，比如說ES、INFORMIX、MONGODB或者說Oracle。TDSQL-PG在往這個后面同步數(shù)據(jù)的時候，其實我們是先通過自己的邏輯解析的數(shù)據(jù)，把數(shù)據(jù)解析成了Json格式，通過Kafka同步過去。在2020年在第七次全國人口普查項目中，騰訊云數(shù)據(jù)庫TDSQL支持了十億級用戶數(shù)據(jù)，以及海量超級大表關(guān)聯(lián)高并發(fā)統(tǒng)計查詢的場景要求。從第七次全國人口普查開始第一天起，系統(tǒng)每秒查詢率（QPS）就猛增到7萬，峰值一舉達(dá)到了11萬左右。七人普項目涉及的多張超級大表關(guān)聯(lián)高并發(fā)統(tǒng)計查詢，其每張表中存放了超過20億+條記錄。如果其中一個表單用來存放平均50萬字的書籍，可以放下超過1000萬本，一個人終其一生也讀不完。在項目里TDSQL-PG承擔(dān)了非常繁重的分析任務(wù)，同時兼具實時數(shù)據(jù)寫入和海量數(shù)據(jù)計算分析的能力。
