數(shù)據(jù)庫(kù)壓縮技術(shù)在百度網(wǎng)盤的應(yīng)用

1、數(shù)據(jù)庫(kù)壓縮技術(shù)在百度網(wǎng)盤的應(yīng)用技術(shù)創(chuàng)新 變革未來大綱百度網(wǎng)盤簡(jiǎn)介問題與挑戰(zhàn)階段一：InnoDB壓縮（100G壓縮到60G）（20142015）階段二：TokuDB壓縮（100G壓縮到35G）（20162018）階段三：下一步（MyRocks & 冷熱分離）（20182019）快速發(fā)展期萌芽探索期成熟理性期瓶頸洗牌期2012201620172005, GmailDrive，各廠商紛紛進(jìn)入個(gè)行業(yè)政策監(jiān)管趨嚴(yán)，2017年，行業(yè)洗牌逐漸網(wǎng)易郵箱個(gè)人文件夾人云盤領(lǐng)域，競(jìng)爭(zhēng)個(gè)人云盤盈利困難，完成，商業(yè)模式形成。功能成為云盤的雛形；日趨白熱化。包括360等多家服務(wù)百度網(wǎng)盤（6億用戶）、2009年，Dropb

2、ox百度網(wǎng)盤發(fā)布。商關(guān)停網(wǎng)盤服務(wù)。DropBox（5億用戶）。用戶數(shù)突破百萬(wàn)，華 為網(wǎng)盤、115網(wǎng)盤等 產(chǎn)品出現(xiàn)。百度云堅(jiān)持下來， 大量用戶轉(zhuǎn)到百度 云。百度網(wǎng)盤發(fā)展歷史萌芽探索期2005百度網(wǎng)盤架構(gòu)介紹APP ServerPCSPOMSOBJECT-StorePCS：管理用戶和文件POMS： 管理文件和塊的關(guān)系OBJECT：分布式KV存儲(chǔ)，存儲(chǔ)最終的文件 塊。MySQL：1.存儲(chǔ)用戶目錄信息（用戶與文件的MAP信息）2.存儲(chǔ)文件拆分后的索引信息（按照4MB拆分的小 文件）為什么要用MySQL？需要SQL接口大量order by，group by,distinct等MySQL產(chǎn)品用戶與文件關(guān)系

3、文件與塊的關(guān)系KV存儲(chǔ)MySQL問題和挑戰(zhàn)問題與挑戰(zhàn)：數(shù)據(jù)量大整個(gè)網(wǎng)盤估算：10G*6億 = 10G * 600,000,000 = 6ZB?MySQL數(shù)據(jù)庫(kù)PB級(jí)別MySQL集群規(guī)模大千級(jí)別機(jī)器和實(shí)例MySQL磁盤利用率高達(dá)到60%左右不斷快速增長(zhǎng)！大綱百度網(wǎng)盤簡(jiǎn)介問題與挑戰(zhàn)階段一：InnoDB壓縮（100G壓縮到60G）（20142015）階段二：TokuDB壓縮（100G壓縮到35G）（20162018）階段三：下一步（MyRocks & 冷熱分離）（20182019）階段一：InnoDB壓縮社區(qū)版壓縮功能不能直接使用。問題1：壓縮后寫性能是未開啟壓縮性能的1/3，業(yè)務(wù)無(wú)法接受。問題2：

4、壓縮后讀性能沒有提升。寫性能差原因1：同步壓縮寫性能差原因2：壓縮失敗頁(yè)分裂解決方案：提前分裂問題：提升讀性能原因：ssd上讀取速度和innodb zlib解壓速度相當(dāng)。節(jié)省的io被解壓操作抵消了。解決方案：替換壓縮算法LZ4算法壓縮率壓縮速度解壓速度zlib0.21172429.060595236.911942lzo0.306656387.374542711.443909snappy0.314193241.024979859.810669lz40.297518385.1755371618.197998問題：提升讀性能LZ4基于塊壓縮，ZLIB基于流式壓縮需要將流式記錄壓縮轉(zhuǎn)化為塊壓縮優(yōu)化成果

5、Sysbench壓測(cè)Read，讀性能提升2030%Write，寫性能下降10%以內(nèi)大綱百度網(wǎng)盤簡(jiǎn)介問題與挑戰(zhàn)階段一：InnoDB壓縮（100G壓縮到60G）（20142015）階段二：TokuDB壓縮（100G壓縮到35G）（20162018）階段三：下一步（MyRocks & 冷熱分離）（20182019）階段二：tokudb壓縮特點(diǎn)：Fractal TreeB+ tree + Message BufferBig nodes（4MB vs. 16KB ）性能：優(yōu)化了寫入行為，同步改異步。讀性能下降，每次查詢請(qǐng)求都 需要對(duì)同條鏈路上的異步消息緩 存消息進(jìn)行下推。Root NodeNon-lea

6、f NodeLeaf Node主要的工作壓縮比和性能測(cè)試ZSTD新壓縮算法引入海量數(shù)據(jù)遷移穩(wěn)定性工作1.壓縮比和性能測(cè)試壓縮算法數(shù)據(jù)庫(kù)版本壓縮率并發(fā)數(shù)TPS讀寫請(qǐng)求平均耗時(shí)LZ4(InnoDB)MySQL5.658.5%10243/s4474/s41.3ms20485/s8481/s41.6ms501156/s20813/s43.6msQUICKLZ(TokuDB)Percona5.634.5%10785/s15141/s11.6ms201239/s22309/s16.2ms501248/s22470/s40.1ms壓縮測(cè)試：模擬線上環(huán)境，采用的是網(wǎng)盤PCS表的數(shù)據(jù)性能測(cè)試：sysbench壓

7、測(cè)，表個(gè)數(shù)是10張，每張表1000W行記錄，OLTP環(huán)境Tokudb引擎優(yōu)勢(shì)Innodb的壓縮受到頁(yè)對(duì)齊影響，理論上線不會(huì)超過50%。innodb引擎的壓縮率接近58.5%，tokudb引擎壓縮率可達(dá)到34.5%，空間 節(jié)省70%。Tokudb在低并發(fā)（=20）場(chǎng)景下性能有明顯優(yōu)勢(shì)。2.ZSTD壓縮算法引入壓縮名稱壓縮比例壓縮速度解壓速度ZSTD 1.3.4-12.877470MB/S1380MB/SZLIB 1.2.11-12.743110MB/S400MB/SQUICKLZ 1.5.02.238550MB/S710MB/SLZ4 1.8.12.101750MB/S3700MB/SSNAPP

8、U 1.1.42.091530MB/S1800MB/SLZF 3.6-12.077400MB/S860MB/S綜合權(quán)衡壓縮率和性能，ZSTD最優(yōu)。ZSTD和tokudb默認(rèn)QUICKLZ算法相比，壓 縮率提升20%左右，性能提升7%左右。ZSTD 支持多個(gè)壓縮級(jí)別，從level=1到level=22。level值越大，壓縮效果越好，但 占用的資源和壓縮時(shí)間也就越長(zhǎng)。Level=6ZSTD效果壓縮算法存儲(chǔ)容量并發(fā)數(shù)QPS讀SQL平均相 應(yīng)CPUIDLEIOUTILQUICKLZ561GB105670/s1.18ms64%9%209000/s1.42ms36%10.2%3011800/s1.64m

9、s28%18.3%ZSTD_level_1478GB105640/s1.15ms67%11.2%209400/s1.31ms39%13.2%3011500/s1.52ms30%15.1%ZSTD_level_6463GB105710/s1.26ms66%7.2%209200/s1.35ms33%9%3012000/s1.53ms26%16.4%ZSTD效果引擎名稱壓縮算法存儲(chǔ)容 量并發(fā)數(shù)TPS讀寫請(qǐng)求平均耗時(shí)LZ4(InnoDB)MySQL5.658.5%10243/s4474/s41.3ms20485/s8481/s41.6ms301156/s20813/s43.6msQUICKLZ(Tok

10、uDB)Percona5.634.5%10785/s15141/s11.6ms201239/s22309/s16.2ms501248/s22470/s40.1msZSTD(TokuDB)MySQL5.628.5%20比QuickLZ提 升7%比QuickLZ提 升7%3.數(shù)據(jù)遷移每個(gè)分片保存異構(gòu) 的存儲(chǔ)引擎批量主從切換程序 開發(fā)調(diào)整讀請(qǐng)求流量權(quán)重定時(shí)統(tǒng)計(jì)請(qǐng)求耗時(shí)集群分片級(jí)拓?fù)?信息dbproxy加載信 息一致性臨時(shí)關(guān)閉集群配置下發(fā) 進(jìn)程實(shí)例上下線通過程序批 量操作實(shí)例角集群健色變更康檢查快速回 滾方案上線 預(yù)熱減少業(yè)務(wù)斷鏈穩(wěn)定請(qǐng)求耗時(shí)避免請(qǐng)求異常降低業(yè)務(wù)損失4.穩(wěn)定性相關(guān)Bug修復(fù)一致性約束失

11、效tokudb引擎統(tǒng)計(jì)信息失效關(guān)閉binlog導(dǎo)致MySQL實(shí)例crash執(zhí)行MySQL部分操作慢TokuDB中ALTER TABLE可能產(chǎn)生的線程阻塞jemalloc庫(kù)版本bugEtc.監(jiān)控項(xiàng)xtrabackup壓縮技術(shù)總體收益存儲(chǔ)容量：網(wǎng)盤數(shù)據(jù)庫(kù)數(shù)據(jù)量減少PB級(jí)別成本節(jié)?。簲?shù)據(jù)庫(kù)壓縮技術(shù)每年為網(wǎng)盤節(jié)省近千臺(tái)服務(wù)器網(wǎng)盤數(shù)據(jù)庫(kù)單GB存儲(chǔ)成本減少70%。其他收益：百度網(wǎng)盤的壓縮整體方案只是一個(gè)開始。數(shù)據(jù)庫(kù)壓縮技術(shù)已經(jīng)在百度所有的MySQL業(yè)務(wù)上推廣起來。大綱百度網(wǎng)盤簡(jiǎn)介問題與挑戰(zhàn)階段一：InnoDB壓縮（100G壓縮到60G）（20142015）階段二：TokuDB壓縮（100G壓縮到35G）（

12、20162018）階段三：下一步（MyRocks & 冷熱分離）（20182019）不同存儲(chǔ)引擎壓縮算法適配場(chǎng)景innodb（LZ4）tokudb（ZSTD）rocksdb（ZSTD）優(yōu)勢(shì)：數(shù)據(jù)壓縮效果一般請(qǐng)求類型支持廣泛事務(wù)支持完善劣勢(shì)：隨機(jī)寫性能較差實(shí)例崩潰恢復(fù)速度慢回滾段存在空間浪費(fèi)優(yōu)勢(shì)：數(shù)據(jù)壓縮效果最佳表字段以字符串為主數(shù)據(jù)碎片化少劣勢(shì)：不支持外鍵約束讀請(qǐng)求耗時(shí)稍長(zhǎng)不適合范圍查詢優(yōu)勢(shì)：數(shù)據(jù)壓縮效果較好數(shù)據(jù)類型基于KV存儲(chǔ)劣勢(shì)：事務(wù)支持不完善排序操作性能差不支持在線表變更多種引擎并存INNODB：對(duì)事務(wù)要求較 高的業(yè)務(wù)：金融類、商 業(yè)訂單類。Tokudb： 已經(jīng)成熟MyRocks: 正在

13、成熟落地MyRocks是未來方向優(yōu)勢(shì)：LSM-Tree寫性能大大優(yōu)于B+樹，F(xiàn)TL樹。RocksDB的壓縮率和TokuDB接近。社區(qū)非常活躍，各IT廠商紛紛采用。學(xué)術(shù)界不斷有各種論文和研究成果推出：讀寫性能提升，空間放大優(yōu)化。計(jì)劃：軟硬結(jié)合，下一代高性能引擎將CPU密集的操作offload到FPGA/GPU。使用Open Channel SSD深度定制針對(duì)MySQL業(yè)務(wù)特點(diǎn)的磁盤。使用NVM技術(shù)提升讀寫性能。在軟件層面，優(yōu)化LSM-Tree，進(jìn)一步提升讀寫性能。新硬件推動(dòng)了數(shù)據(jù)庫(kù)分層存儲(chǔ)模式介質(zhì)SSDDRAM（內(nèi)存）NVM（非易失性內(nèi)存）性能低高SSD NVM DRAM易失 性非易失易失非易失成本低高SSD NVM DRAM經(jīng)常被訪問的數(shù)據(jù)存儲(chǔ)在內(nèi)存、NVM中，提 供