來自支付寶資深數據庫架構師童家旺給大家分享的關于數據存儲性能優化的一點想法，他從自己的個人經驗中總結了關于數據庫存儲的性能優化。

▲支付寶資深數據庫架構師童家旺

首先，童家旺介紹了他認為的什么是優化：

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

第二、不訪問不必要的數據：使用B*Tree/hash等方法定位必要的數據。使用column Store或分表的方式將數據分開存儲。使用Bloom filter算法排除空值查詢。

第三、合理的利用硬件來提升訪問效率：使用緩存消除對數據的重復訪問。使用批量處理來減少磁盤的Seek操作。使用批量處理來減少網絡的Round Trip。使用SSD來提升磁盤訪問效率。

響應時間和吞吐量之間的關系

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

2、響應時間。衡量系統與用戶交互式多久能夠發出響應。

3、吞吐量。衡量系統在單位時間里可以完成的任務量。

▲反應時間

▲傳統磁盤的訪問特性

B*Tree優化數據訪問介紹

▲B*Tree優化數據訪問

B*Tree優化數據訪問模擬場景

▲B*Tree優化數據訪問模擬場景

#p#

童家旺通過阿里巴巴的真實應用場景介紹了如何用分表存儲來提高性能。

一、場景介紹：

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

二、要求：

1. 對此業務進行優化
2. 分析數據,說服開發部門實施此優化

三、性能分析

1、每塊記錄數

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

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

8192 * 0.80 / ( 2000 + 250 ) = 2.91

2、訪問的邏輯IO(內存塊訪問)

List的查詢代價

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

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

3、訪問涉及到的物理讀(磁盤塊訪問)

List的查詢代價(邏輯IO * ( 1 – 命中率 ))

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

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

4、訪問時間(ms)

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

改進后=邏輯IO時間+物理IO時間= 165.5 * 0.01 + 24.825 * 7 = 175.43ms

場景

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

要求

1. 優化業務

方案

1. 使用緩存來減少應用對后端的訪問

注意事項

1. 考慮緩存的刷新策略
2. 考慮緩存的數據延遲對業務的影響
3. 考慮緩存失效時,系統的支撐能力

參考緩存工具

MemCached, Tair, Redis

【編輯推薦】

1. 主數據管理（MDM）的七個***實踐
2. SQL server的高可用性 SQL Mirror HA
3. 淺談一次惱火的死鎖追蹤經歷
4. DataReader鏈接關閉解惑篇