來(lái)自支付寶資深數(shù)據(jù)庫(kù)架構(gòu)師童家旺給大家分享的關(guān)于數(shù)據(jù)存儲(chǔ)性能優(yōu)化的一點(diǎn)想法，他從自己的個(gè)人經(jīng)驗(yàn)中總結(jié)了關(guān)于數(shù)據(jù)庫(kù)存儲(chǔ)的性能優(yōu)化。

▲支付寶資深數(shù)據(jù)庫(kù)架構(gòu)師童家旺

首先，童家旺介紹了他認(rèn)為的什么是優(yōu)化：

***、做任何事情最快的方法就是什么也不做。

第二、不訪問(wèn)不必要的數(shù)據(jù)：使用B*Tree/hash等方法定位必要的數(shù)據(jù)。使用column Store或分表的方式將數(shù)據(jù)分開(kāi)存儲(chǔ)。使用Bloom filter算法排除空值查詢(xún)。

第三、合理的利用硬件來(lái)提升訪問(wèn)效率：使用緩存消除對(duì)數(shù)據(jù)的重復(fù)訪問(wèn)。使用批量處理來(lái)減少磁盤(pán)的Seek操作。使用批量處理來(lái)減少網(wǎng)絡(luò)的Round Trip。使用SSD來(lái)提升磁盤(pán)訪問(wèn)效率。

響應(yīng)時(shí)間和吞吐量之間的關(guān)系

1、性能。衡量完成特定任務(wù)的速度或效率。

2、響應(yīng)時(shí)間。衡量系統(tǒng)與用戶(hù)交互式多久能夠發(fā)出響應(yīng)。

3、吞吐量。衡量系統(tǒng)在單位時(shí)間里可以完成的任務(wù)量。

▲反應(yīng)時(shí)間

▲傳統(tǒng)磁盤(pán)的訪問(wèn)特性

B*Tree優(yōu)化數(shù)據(jù)訪問(wèn)介紹

▲B(niǎo)*Tree優(yōu)化數(shù)據(jù)訪問(wèn)

B*Tree優(yōu)化數(shù)據(jù)訪問(wèn)模擬場(chǎng)景

▲B(niǎo)*Tree優(yōu)化數(shù)據(jù)訪問(wèn)模擬場(chǎng)景

#p#

童家旺通過(guò)阿里巴巴的真實(shí)應(yīng)用場(chǎng)景介紹了如何用分表存儲(chǔ)來(lái)提高性能。

一、場(chǎng)景介紹：

1. 表VeryBigTable含有30個(gè)列
2. 表的記錄數(shù)為50,000,000條
3. 平均每個(gè)用戶(hù)為300條左右
4. 其中有2個(gè)列屬于詳細(xì)描述字段,平均長(zhǎng)度為2k
5. 其它的列的總長(zhǎng)度平均為250個(gè)字節(jié)
6. 此表上的查詢(xún)有兩種模式
7. 列出表中的主要信息(每次20條,不包含詳細(xì)信息,90%的查詢(xún))
8. 查看記錄的詳細(xì)信息(10%的查詢(xún))
9. 保存與Oracle數(shù)據(jù)庫(kù),默認(rèn)block_size(8k)

二、要求：

1. 對(duì)此業(yè)務(wù)進(jìn)行優(yōu)化
2. 分析數(shù)據(jù),說(shuō)服開(kāi)發(fā)部門(mén)實(shí)施此優(yōu)化

三、性能分析

1、每塊記錄數(shù)

8192 * 0.80(1) / 250 = 25.5 (主表)

8192 * 0.80 / 2000 = 3.27(詳情表)

8192 * 0.80 / ( 2000 + 250 ) = 2.91

2、訪問(wèn)的邏輯IO(內(nèi)存塊訪問(wèn))

List的查詢(xún)代價(jià)

改進(jìn)后=( 300/25.5 ) * y + 4 + x = 4 + x + 11.8y = 4(2) + 7(3) + 11.8 * 1.5(4) = 28.7

改進(jìn)前=( 300/2.91 ) * y + 4 + x = 4 + x + 103.y = 4 + 7 + 103 * 1.5 = 165.5

3、訪問(wèn)涉及到的物理讀(磁盤(pán)塊訪問(wèn))

List的查詢(xún)代價(jià)(邏輯IO * ( 1 – 命中率 ))

改進(jìn)后=28.7 * ( 1 – 0.85(5)) = 4.305

改進(jìn)前=165.5 * ( 1 – 0.85 ) = 24.825

4、訪問(wèn)時(shí)間(ms)

改進(jìn)前=邏輯IO時(shí)間+物理IO時(shí)間= 28.7 * 0.01(6) + 4.305 * 7(7) = 30.422ms

改進(jìn)后=邏輯IO時(shí)間+物理IO時(shí)間= 165.5 * 0.01 + 24.825 * 7 = 175.43ms

場(chǎng)景

1. Read Intensive (R/W 20倍以上)
2. 業(yè)務(wù)可接受部分延遲(Delay)
3. 每天訪問(wèn)量上億次
4. 系統(tǒng)IO壓力巨大(本地內(nèi)存無(wú)法容納活躍數(shù)據(jù))

要求

1. 優(yōu)化業(yè)務(wù)

方案

1. 使用緩存來(lái)減少應(yīng)用對(duì)后端的訪問(wèn)

注意事項(xiàng)

1. 考慮緩存的刷新策略
2. 考慮緩存的數(shù)據(jù)延遲對(duì)業(yè)務(wù)的影響
3. 考慮緩存失效時(shí),系統(tǒng)的支撐能力

參考緩存工具

MemCached, Tair, Redis

【編輯推薦】

1. 主數(shù)據(jù)管理（MDM）的七個(gè)***實(shí)踐
2. SQL server的高可用性 SQL Mirror HA
3. 淺談一次惱火的死鎖追蹤經(jīng)歷
4. DataReader鏈接關(guān)閉解惑篇