摘要：經(jīng)?；燠E于技術(shù)社區(qū)，頻繁看到這個(gè)題目，今天干脆在自己博客重復(fù)一遍解決辦法針對(duì)，等關(guān)系型數(shù)據(jù)庫單表數(shù)據(jù)過大的處理方式如果不是阿里云的分布式數(shù)據(jù)庫那種多機(jī)器集群方案的話先考慮表分區(qū)然后考慮分表然后考慮分庫。

經(jīng)常混跡于技術(shù)社區(qū)，頻繁看到這個(gè)題目，今天干脆在自己博客重復(fù)一遍解決辦法：

針對(duì)mysql，sqlserver等關(guān)系型數(shù)據(jù)庫單表數(shù)據(jù)過大的處理方式

如果不是阿里云的分布式數(shù)據(jù)庫 DRDS?那種多機(jī)器集群方案的話：?先考慮表分區(qū) ；然后考慮分表 ；然后考慮分庫。

這個(gè)題目是我所經(jīng)歷過的，我做的是GPS應(yīng)用，早期版本就是選用的關(guān)系型數(shù)據(jù)庫Sql Server。當(dāng)時(shí)我選取的方案就是第一種：表分區(qū)。 表分區(qū)的優(yōu)勢(shì)是，如果表結(jié)構(gòu)合理，可以不涉及到程序修改。也就是說，對(duì)程序來講依然是單表讀寫的效果！

所有軌跡數(shù)據(jù)存入到一個(gè)巨大的表里。有多大呢？

最大存儲(chǔ)量超過10億行。具體數(shù)值應(yīng)該是12億多點(diǎn)，由于系統(tǒng)設(shè)計(jì)為只存儲(chǔ)30天軌跡，所以線上期間最大存儲(chǔ)只到這個(gè)數(shù)，再后來采用云架構(gòu)，上云替換成非關(guān)系性數(shù)據(jù)庫，獲得了更高的寫入性能和存儲(chǔ)壓縮能力。??

每日寫入量就超過1500萬行。上下班交通高峰時(shí)候每秒寫入量平均超過500行。也就是500iops，距離系統(tǒng)設(shè)計(jì)的壓測(cè)指標(biāo)3000還有一大截

這張大型單表設(shè)計(jì)要點(diǎn)：（一個(gè)聚集索引用于寫入，一個(gè)聯(lián)合索引用于查詢，沒有主鍵，使用表分區(qū)）

明確主鍵用途：

真的需要查詢單行數(shù)據(jù)時(shí)候才需要主鍵！

我采用無主鍵設(shè)計(jì)，用于避免寫入時(shí)候浪費(fèi)維護(hù)插入數(shù)據(jù)的性能。最早使用聚集的類似自增的id主鍵，壓測(cè)寫入超過5億行的時(shí)候，寫入性能縮減一半

準(zhǔn)確適用聚集：

寫入的數(shù)據(jù)在硬盤物理順序上是追加，而不是插入！

我把時(shí)間戳字段設(shè)置為聚集索引，用于聚集寫入目的設(shè)計(jì)。保證硬盤上的物理寫入順序，不浪費(fèi)性能用于插入數(shù)據(jù)

職責(zé)足夠單一：?

用于精準(zhǔn)索引！

使用時(shí)間+設(shè)備聯(lián)合索引，保證這張表只有一個(gè)查詢用途。保證系統(tǒng)只有一種查詢目的：按照設(shè)備號(hào)，查詢一個(gè)時(shí)間段的數(shù)據(jù)。

精確的表分區(qū)：

要求查詢時(shí)候限定最大量或者最大取值范圍！

按天進(jìn)行表分區(qū)，實(shí)現(xiàn)大數(shù)據(jù)量下的高效查詢。這里是本文重點(diǎn)，按照聚集索引進(jìn)行，可以讓目標(biāo)數(shù)據(jù)局限在更小的范圍進(jìn)行，雖然單表數(shù)據(jù)上億，但是查詢基本上只在某一天的的幾千萬里進(jìn)行索引查詢

每張表會(huì)有各自的特點(diǎn)，不可生搬硬套，總結(jié)下我這張表的特點(diǎn)：

只增，不刪，不改！

關(guān)于不刪除中：每天使用作業(yè)刪除超過30天的那個(gè)分區(qū)數(shù)據(jù)除外，因?yàn)橐蹇张f的表分區(qū)，騰出新的表分區(qū)！

只有一個(gè)業(yè)務(wù)查詢：只按照設(shè)備編碼查詢某個(gè)時(shí)間段

只有一個(gè)運(yùn)維刪除：刪除舊的分區(qū)數(shù)據(jù)

這張表，是我技術(shù)生涯中進(jìn)步的一個(gè)大階梯，讓我我體會(huì)到了系統(tǒng)架構(gòu)的意義。

雖然我的這張舉行表看似只有4個(gè)關(guān)鍵點(diǎn)，但是這四個(gè)非常精準(zhǔn)的關(guān)鍵點(diǎn)設(shè)計(jì)，耗費(fèi)了我一個(gè)月之久！正是這么足夠精準(zhǔn)的表結(jié)構(gòu)設(shè)計(jì)，才撐起了后來壓測(cè)并發(fā)量超過3000的并發(fā)寫入量！壓測(cè)的指標(biāo)跟數(shù)據(jù)庫所在的硬盤有直接關(guān)系，當(dāng)時(shí)選取的硬盤是4塊10000轉(zhuǎn)的SAS盤做了Raid10的環(huán)境

關(guān)于后來為什么沒有更高的實(shí)際應(yīng)用數(shù)值，是因?yàn)橄到y(tǒng)后來改版為云架構(gòu)，使用了阿里云，更改為寫入性能更高的非關(guān)系型數(shù)據(jù)庫MongoDB存儲(chǔ)軌跡數(shù)據(jù)。所以雖然距離壓測(cè)指標(biāo)還差很遠(yuǎn)，但是也沒有實(shí)際跑到這個(gè)數(shù)據(jù)！單機(jī)應(yīng)用再怎么改造，每次升級(jí)都是一件麻煩事，所以應(yīng)當(dāng)盡可能將瓶頸點(diǎn)提高，甚至消除，云架構(gòu)的意義就在于彈性擴(kuò)展，雖然我在數(shù)據(jù)庫方面還沒有這方面的成功案例可分享，但是這種架構(gòu)的意義很明白：將來面對(duì)更大的壓力，只需要增加服務(wù)器數(shù)量！? ??

最后提一句， 很多人覺得SSD就足夠高的性能了，但是對(duì)于云服務(wù)器，ssd的性能才跟傳統(tǒng)物理機(jī)的iops相持平，這是由于虛擬化層面的損失導(dǎo)致的！

原文地址：?https://www.opengps.cn/Blog/View.aspx?id=284?文章的更新編輯依此鏈接為準(zhǔn)。歡迎關(guān)注源站原創(chuàng)文章！