面向大規(guī)模商業(yè)系統(tǒng)的數(shù)據(jù)庫(kù)設(shè)計(jì)和實(shí)踐
時(shí)間：2021-09-10 16:33:31
手機(jī)看文章
掃描二維碼
隨時(shí)隨地手機(jī)看文章
[導(dǎo)讀]導(dǎo)讀：目前關(guān)系型數(shù)據(jù)庫(kù)從上世紀(jì)70年代誕生以來(lái)得到了廣泛應(yīng)用，各種數(shù)字化的信息系統(tǒng)都能見(jiàn)到關(guān)系型數(shù)據(jù)庫(kù)的身影。在真實(shí)的場(chǎng)景里面，業(yè)務(wù)系統(tǒng)對(duì)關(guān)系型數(shù)據(jù)庫(kù)這種基礎(chǔ)軟件的要求非常簡(jiǎn)單，那就是高可靠和高性能，同時(shí)希望盡可能借助復(fù)雜的SQL語(yǔ)義來(lái)簡(jiǎn)化業(yè)務(wù)層功能的實(shí)現(xiàn)。傳統(tǒng)數(shù)據(jù)庫(kù)產(chǎn)品例如Or...
導(dǎo)讀：目前關(guān)系型數(shù)據(jù)庫(kù)從上世紀(jì)70年代誕生以來(lái)得到了廣泛應(yīng)用，各種數(shù)字化的信息系統(tǒng)都能見(jiàn)到關(guān)系型數(shù)據(jù)庫(kù)的身影。在真實(shí)的場(chǎng)景里面，業(yè)務(wù)系統(tǒng)對(duì)關(guān)系型數(shù)據(jù)庫(kù)這種基礎(chǔ)軟件的要求非常簡(jiǎn)單，那就是高可靠和高性能，同時(shí)希望盡可能借助復(fù)雜的SQL語(yǔ)義來(lái)簡(jiǎn)化業(yè)務(wù)層功能的實(shí)現(xiàn)。傳統(tǒng)數(shù)據(jù)庫(kù)產(chǎn)品例如Oracle、SQLServer、MySQL、PostgreSQL等都發(fā)展趨于成熟，新一代的云原生數(shù)據(jù)庫(kù)產(chǎn)品例如Aurora、PolarDB、TiDB、OceanBase等又開(kāi)始引發(fā)更廣泛的關(guān)注，那么什么樣的數(shù)據(jù)庫(kù)產(chǎn)品才能更好地適應(yīng)業(yè)務(wù)發(fā)展？數(shù)據(jù)庫(kù)這種比較古老的軟件產(chǎn)品的未來(lái)又是什么？本文主要從商業(yè)產(chǎn)品系統(tǒng)的需求出發(fā)探討數(shù)據(jù)庫(kù)技術(shù)的實(shí)踐和思考。全文11241字，預(yù)計(jì)閱讀時(shí)間 18分鐘。
一、商業(yè)產(chǎn)品系統(tǒng)對(duì)數(shù)據(jù)存儲(chǔ)設(shè)施需求的特點(diǎn)
百度商業(yè)產(chǎn)品矩陣主要包括效果廣告（搜索廣告、信息流廣告）和展示廣告（品牌廣告、開(kāi)屏聚屏廣告）兩大類(lèi)廣告產(chǎn)品，以及基木魚(yú)和觀(guān)星盤(pán)等營(yíng)銷(xiāo)工具，商業(yè)產(chǎn)品系統(tǒng)是連接百度客戶(hù)和廣告檢索系統(tǒng)的橋梁，幫助客戶(hù)表達(dá)營(yíng)銷(xiāo)訴求，達(dá)成營(yíng)銷(xiāo)目標(biāo)。
商業(yè)產(chǎn)品系統(tǒng)本質(zhì)就是一個(gè)復(fù)雜、龐大的廣告信息管理系統(tǒng)，有toB、toC的多種場(chǎng)景，需求多樣豐富且迭代頻繁。
這些業(yè)務(wù)需求聚焦到數(shù)據(jù)存儲(chǔ)層面，主要有：
- 投放，交易場(chǎng)景的事務(wù)型需求（OLTP，On-Line Transaction Processing）；
- 廣告效果分析場(chǎng)景的分析型需求（OLAP，Online analytical processing）
- 特定場(chǎng)景的高QPS查詢(xún)，例如賬戶(hù)結(jié)構(gòu)，權(quán)限關(guān)系等；
- 字面場(chǎng)景的正反KV查詢(xún)，例如關(guān)鍵詞字面和id互查等；
- 物料列表場(chǎng)景的模糊查詢(xún)；
為了應(yīng)對(duì)商業(yè)場(chǎng)景下如此多樣且迥異的數(shù)據(jù)存儲(chǔ)需求，如果使用傳統(tǒng)的存儲(chǔ)技術(shù)，至少需要使用關(guān)系型數(shù)據(jù)庫(kù)（例如MySQL）、KV存儲(chǔ)（例如Redis）、OLAP 數(shù)倉(cāng)（例如Palo）、全文檢索（例如ElasticSearch）以及自定義內(nèi)存結(jié)構(gòu)的存儲(chǔ)等。
那么業(yè)務(wù)系統(tǒng)對(duì)數(shù)據(jù)存儲(chǔ)設(shè)施的要求是什么呢？
- 首先是穩(wěn)定可靠，不可用就意味著客戶(hù)體驗(yàn)受損乃至直接的經(jīng)濟(jì)損失；
- 其次數(shù)據(jù)盡可能一致，如果客戶(hù)在不同環(huán)節(jié)看的數(shù)據(jù)有差異則會(huì)產(chǎn)生誤解甚至引發(fā)錯(cuò)誤的廣告投放操作；
- 再次盡可能低成本的應(yīng)對(duì)數(shù)據(jù)規(guī)模持續(xù)增長(zhǎng)，不需要預(yù)先購(gòu)置大量硬件，后期擴(kuò)展時(shí)也盡可能簡(jiǎn)單；
- 最后綜合讀寫(xiě)性能好，盡量毫秒級(jí)響應(yīng)，不影響客戶(hù)的操作體驗(yàn)。
對(duì)于業(yè)務(wù)研發(fā)的同學(xué)來(lái)說(shuō)，他們希望用到的數(shù)據(jù)存儲(chǔ)產(chǎn)品是什么樣呢?
- 接口的使用方式單一，學(xué)習(xí)和遷移成本低，不同的數(shù)據(jù)存儲(chǔ)也盡量采用相同的接口形式；
- 數(shù)據(jù)變更行為可理解，不出現(xiàn)數(shù)據(jù)丟失或者覆蓋，不因并發(fā)引入異常數(shù)據(jù)；
- 擴(kuò)展性高，能夠適應(yīng)數(shù)據(jù)規(guī)模和流量從1到N的變化，業(yè)務(wù)最好無(wú)感知；
- 高可用，內(nèi)建高度容錯(cuò)能力，業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)異常最好無(wú)感知；
- Schema變更成本低廉；
- 對(duì)各種讀寫(xiě)模式都能提供很好的性能。
總結(jié)起來(lái)最好什么都可以干，什么負(fù)載都可以扛，什么運(yùn)維都不用管！
二、BaikalDB 的發(fā)展歷程
商業(yè)系統(tǒng)最核心的存儲(chǔ)需求就是廣告庫(kù)，廣告庫(kù)存儲(chǔ)了所有的廣告物料信息，用于完成整個(gè)廣告生命周期的管理，幫助客戶(hù)完成全部廣告投放功能，獲取轉(zhuǎn)化。伴隨百度鳳巢系統(tǒng)的發(fā)展，廣告庫(kù)的存儲(chǔ)設(shè)施經(jīng)歷了兩個(gè)重要的階段：
1. 單庫(kù)到分庫(kù)分表的MySQL集群
2. MySQL主存儲(chǔ)集群 鏡像輔助存儲(chǔ)構(gòu)成的異構(gòu)復(fù)合存儲(chǔ)集群
2.1 分庫(kù)分表的 MySQL 集群
最早的鳳巢廣告庫(kù)采用單機(jī)MySQL，部署在獨(dú)立的盤(pán)柜（高性能磁盤(pán)陣列）上，這種架構(gòu)受限于當(dāng)時(shí)的硬件條件現(xiàn)在看來(lái)比較古老，但這個(gè)跟現(xiàn)在流行的存儲(chǔ)計(jì)算分離的云原生架構(gòu)從思想上是完全一致的，AWS的Aurora或者阿里云的PolarDB就是把MySQL、PostgreSQL等單機(jī)數(shù)據(jù)庫(kù)部署到一個(gè)由EBS磁盤(pán)或者RDMA高速網(wǎng)絡(luò)連接的分布式文件系統(tǒng)上，實(shí)現(xiàn)100%的SQL兼容。
隨著業(yè)務(wù)發(fā)展，單機(jī)部署的MySQL無(wú)法支撐數(shù)據(jù)量和讀寫(xiě)量的膨脹，分庫(kù)分表就成了當(dāng)時(shí)乃至現(xiàn)在最優(yōu)的選擇，通過(guò)分庫(kù)分表，MySQL可以實(shí)現(xiàn)容量和性能的高擴(kuò)展性。
從2010年開(kāi)始，鳳巢廣告庫(kù)就依次經(jīng)歷了1拆4、4拆8、8拆16、16拆32的分庫(kù)過(guò)程，從一套單機(jī)集群發(fā)展成了有33分庫(kù)（多拆出來(lái)的一個(gè)分庫(kù)是為了解決個(gè)別大客戶(hù)購(gòu)買(mǎi)巨量關(guān)鍵詞的場(chǎng)景），每分庫(kù)1主11從的多分庫(kù)集群，存儲(chǔ)了數(shù)十TB的廣告物料信息，讀寫(xiě)PV達(dá)到每日數(shù)十億。拆庫(kù)的服務(wù)停頓時(shí)間從一天到6個(gè)小時(shí)，再到分鐘級(jí)別。
2.2 異構(gòu)復(fù)合存儲(chǔ)集群
鳳巢廣告庫(kù)的業(yè)務(wù)場(chǎng)景是讀多寫(xiě)少，查詢(xún)場(chǎng)景多樣，多分庫(kù)MySQL集群在滿(mǎn)足一些查詢(xún)場(chǎng)景較為吃力，比如在賬戶(hù)-計(jì)劃-單元-關(guān)鍵詞層級(jí)結(jié)構(gòu)里，獲取賬戶(hù)下關(guān)鍵詞數(shù)，計(jì)劃下的關(guān)鍵詞數(shù)等涉及全表掃的count，關(guān)鍵詞字面高qps查詢(xún)，創(chuàng)意模糊搜索，物料列表分篩排等，這些需求使用MySQL都難以滿(mǎn)足。
為解決這個(gè)問(wèn)題，我們通過(guò)數(shù)據(jù)流，把MySQL的數(shù)據(jù)實(shí)時(shí)同步到一個(gè)鏡像的內(nèi)存存儲(chǔ)，這些鏡像存儲(chǔ)采用針對(duì)特定查詢(xún)場(chǎng)景的內(nèi)存結(jié)構(gòu)，來(lái)滿(mǎn)足業(yè)務(wù)性能。同時(shí)為了業(yè)務(wù)應(yīng)用的開(kāi)發(fā)便利，還專(zhuān)門(mén)開(kāi)發(fā)了SQL代理層，按照一定規(guī)則在SQL不改變的情況路由到鏡像索引，并轉(zhuǎn)化為鏡像存儲(chǔ)所需要的請(qǐng)求參數(shù)，這樣雖然我們使用了不同的數(shù)據(jù)源，但是業(yè)務(wù)應(yīng)用仍然認(rèn)為是一個(gè) MySQL協(xié)議的數(shù)據(jù)庫(kù)在提供服務(wù)，且無(wú)需要關(guān)注應(yīng)該查詢(xún)哪種數(shù)據(jù)源，由此形成一個(gè)異構(gòu)的復(fù)合存儲(chǔ)形態(tài)。架構(gòu)如下圖所示：
這是一種常見(jiàn)的架構(gòu)設(shè)計(jì)，在另一些業(yè)務(wù)場(chǎng)景中會(huì)把OLTP數(shù)據(jù)庫(kù)的數(shù)據(jù)同步到OLAP數(shù)據(jù)倉(cāng)庫(kù)，隔離離線(xiàn)分析場(chǎng)景，它的優(yōu)勢(shì)在于多套同種數(shù)據(jù)不同存儲(chǔ)引擎的系統(tǒng)通過(guò)分而治之來(lái)解決復(fù)雜的查詢(xún)場(chǎng)景，并具有一定業(yè)務(wù)隔離性。
依靠SQL代理層能夠有效提升業(yè)務(wù)應(yīng)用的使用體驗(yàn)，并且可以把應(yīng)用層分庫(kù)分表邏輯也下沉到這個(gè)代理層，拆庫(kù)時(shí)業(yè)務(wù)應(yīng)用也無(wú)需感知。對(duì)于業(yè)務(wù)應(yīng)用來(lái)說(shuō)，看到的是一個(gè)單機(jī)的MySQL系統(tǒng)，不再需要考慮任何性能和容量的問(wèn)題。
但是這種架構(gòu)也有明顯的缺點(diǎn)：運(yùn)維更為復(fù)雜：除了關(guān)注 MySQL 本身，還需要運(yùn)維數(shù)據(jù)實(shí)時(shí)同步流，SQL代理層，鏡像索引這些系統(tǒng)。數(shù)據(jù)實(shí)時(shí)同步容易出現(xiàn)故障或者延遲：客戶(hù)可能感知到明顯的不一致，從鏡像索引查詢(xún)到的數(shù)據(jù)跟從MySQL查詢(xún)有差異。為了降低這種差異的影響，SQL代理層還需要設(shè)計(jì)一定的降級(jí)能力（發(fā)現(xiàn)延遲時(shí)盡可能切換到MySQL查詢(xún)）。還需要有快速修正鏡像索引數(shù)據(jù)的設(shè)施。資源冗余浪費(fèi)：鏡像索引實(shí)際是數(shù)據(jù)的復(fù)制， MySQL為扛住讀性能和同步需求需要大量的從庫(kù)。
2.3 2017年的選擇
時(shí)間來(lái)到2017年，鳳巢廣告庫(kù)已經(jīng)有33分庫(kù)，磁盤(pán)也用上了NVME SSD，對(duì)于限定場(chǎng)景的讀寫(xiě)性能可以滿(mǎn)足業(yè)務(wù)需求，但是如果再進(jìn)行一次拆庫(kù)，無(wú)論是資源消耗還是運(yùn)維成本都更為巨大。
到這個(gè)階段，我們開(kāi)始思考是否存在一種成本更低的解決方案。新的信息流廣告業(yè)務(wù)也在快速發(fā)展，如果再形成一套鳳巢廣告類(lèi)似的存儲(chǔ)架構(gòu)，實(shí)際成本會(huì)非?？捎^(guān)。雖然4年后的今天，鳳巢廣告庫(kù)依靠硬件升級(jí)，包括CPU和內(nèi)存升級(jí)、NVME SSD升級(jí)到單盤(pán)3T，依然維持在33分庫(kù)的部署架構(gòu)，但性能瓶頸已經(jīng)開(kāi)始突顯，如果廣告物料繼續(xù)高速增長(zhǎng)，預(yù)計(jì)2022年底就需要進(jìn)行新的拆庫(kù)。
當(dāng)時(shí)廣告系統(tǒng)的業(yè)界標(biāo)桿Google AdWords的核心存儲(chǔ)是F1/Spanner，采用全球部署可以跨遠(yuǎn)距離的數(shù)據(jù)中心多活，配備原子鐘用于實(shí)現(xiàn)分布式強(qiáng)一致事務(wù)，具備極高的可用性和自動(dòng)增容的擴(kuò)展性。參考Google存儲(chǔ)系統(tǒng)的設(shè)計(jì)理念，廣告存儲(chǔ)系統(tǒng)設(shè)計(jì)也有可見(jiàn)的兩種路線(xiàn)：
2.3.1 基于MySQL深度定制
MySQL是一種單機(jī)的架構(gòu)，代碼規(guī)模達(dá)到百萬(wàn)行級(jí)別，掌控和修改的難度都特別高。如果要把MySQL從內(nèi)部改造成一種類(lèi)似F1/Spanner能力的系統(tǒng)基本不大可能。
這時(shí)一般有兩種解決思路，都是從外部來(lái)尋求突破：類(lèi)似Aurora和PolarDB，在文件系統(tǒng)上進(jìn)行突破，使用EBS或者構(gòu)建一種RDMA高速連接的分布式文件系統(tǒng)，這并不是研發(fā)新的數(shù)據(jù)庫(kù)系統(tǒng)。但是為獲取更好的性能，依然需要深入 MySQL的存儲(chǔ)引擎和主從同步機(jī)制進(jìn)行一些定制和深度優(yōu)化。即便如此，總?cè)萘亢托阅芤膊荒軣o(wú)限擴(kuò)展，例如Aurora最高可達(dá)128TB，性能是MySQL的5倍，PolarDB最高可達(dá)100TB，性能是MySQL的6倍。
類(lèi)似鳳巢廣告存儲(chǔ)的設(shè)計(jì)思路，通過(guò)數(shù)據(jù)同步并借助擴(kuò)展的鏡像索引提升查詢(xún)性能，但冗余成本高，數(shù)據(jù)一致性差。
2.3.2 使用滿(mǎn)足分布式 云原生 多樣化索引架構(gòu) 強(qiáng)一致等條件的新數(shù)據(jù)庫(kù)系統(tǒng)
2017年的時(shí)候，無(wú)論是Google的F1/Spanner還是OceanBase都是閉源系統(tǒng)，跟內(nèi)部設(shè)施耦合很大。開(kāi)源系統(tǒng)主要有兩個(gè)流派，一類(lèi)是支持SQL的OLAP系統(tǒng)，例如百度的Palo（現(xiàn)開(kāi)源名為Doris）、Impala（無(wú)存儲(chǔ)引擎）、ClickHouse等，一類(lèi)是參考F1/Spanner思想的CockroachDB和TiDB。OLAP系統(tǒng)肯定不太滿(mǎn)足我們TP（在線(xiàn)事務(wù)）場(chǎng)景的主需求，當(dāng)時(shí)CockroachDB和 TiDB也處于起步階段，生產(chǎn)場(chǎng)景的使用基本沒(méi)有。
這時(shí)放眼望去，實(shí)際并沒(méi)有特別成熟的解決方案，基于MySQL的方案也走到了一個(gè)瓶頸，那么我們能否自研一個(gè)新的分布式數(shù)據(jù)庫(kù)系統(tǒng)？當(dāng)時(shí)的決策依據(jù)是看團(tuán)隊(duì)是否具備能力從零研發(fā)出一個(gè)高可用、高性能、低成本的OLTP為主兼顧OLAP的數(shù)據(jù)庫(kù)（也就是HTAP,Hybrid Transaction and Analytical Process,混合事務(wù)和分析處理）。
團(tuán)隊(duì)的條件：已有的存儲(chǔ)方向團(tuán)隊(duì)（4人）是C 技術(shù)棧，研發(fā)過(guò)SQL代理層和定制化存儲(chǔ)，熟悉MySQL協(xié)議，有實(shí)戰(zhàn)的工程經(jīng)驗(yàn)。技術(shù)的條件：1、分布式系統(tǒng)需要有效的通信框架，百度的brpc框架當(dāng)時(shí)已經(jīng)非常成熟，是工業(yè)級(jí)的RPC實(shí)現(xiàn)，有超大規(guī)模的應(yīng)用。2、保障數(shù)據(jù)一致性當(dāng)時(shí)主流的方案就是Paxos和Raft，百度braft框架是基于brpc的Raft協(xié)議實(shí)現(xiàn)，發(fā)展也很迅速，有內(nèi)部支持。3、單機(jī)存儲(chǔ)節(jié)點(diǎn)需要一個(gè)可靠的KV存儲(chǔ)，F(xiàn)acebook
下載文檔
