大數(shù)據(jù)分析處理的原始數(shù)據(jù)有相當(dāng)一部分來自關(guān)系數(shù)據(jù)庫，處理結(jié)果也存儲在關(guān)系數(shù)據(jù)庫中。原因是超過99%的軟件系統(tǒng)使用傳統(tǒng)的關(guān)系數(shù)據(jù)庫，大家都很熟悉，也很容易使用。

在我們正式的大數(shù)據(jù)團(tuán)隊中，幾個倉庫(data warehouse Hive+HBase)的數(shù)據(jù)采集也來自于Oracle或者M(jìn)ySql。雖然處理后的統(tǒng)計結(jié)果和明細(xì)保存在Hive中，但定期推送至Oracle/MySql供前臺系統(tǒng)讀取顯示并生成各種報表。

在這種場景下，數(shù)據(jù)庫的讀寫性能尤為重要！

一、數(shù)據(jù)庫定位

有大神說，你給我足夠的數(shù)據(jù)庫硬件，一個GroupBy就能滿足各種統(tǒng)計分析場景。

沒錯，我們數(shù)百萬的金融級Oracle一體機(jī)證明了GroupBy可以很強(qiáng)大，也證明了它有一個上限，就是數(shù)據(jù)大了還是要趴下！

所以需要有設(shè)計原則和優(yōu)化技巧。

核心原理:數(shù)據(jù)庫只是數(shù)據(jù)存儲的載體，在大數(shù)據(jù)中很難使用它的計算能力！

有了這個原則，就意味著數(shù)據(jù)庫將被“純粹地”使用:

數(shù)據(jù)表獨立性很強(qiáng)，大表間很少join（這讓我想起有同學(xué)在Hive里對兩張大表做笛卡爾乘積產(chǎn)生270T數(shù)據(jù)）數(shù)據(jù)表很大，單表幾十億行很常見索引很少，一般按主鍵查單行或者按時間查一段 二、分區(qū)存儲

在這里，數(shù)據(jù)庫是存儲數(shù)據(jù)的倉庫，海量數(shù)據(jù)需要拆分存儲，不可能全部壓縮在一起。

根據(jù)業(yè)務(wù)不同，一般有兩種拆分方式:

單表分區(qū)。常見于Oracle，每月做一個分區(qū)，數(shù)據(jù)連續(xù)方便業(yè)務(wù)處理，但要求單機(jī)性能強(qiáng)勁。分表分庫。常見于MySql，分個128張表乃至4096張表也都是很平常的事情，可以用很多性能較差的機(jī)器組建集群，但因數(shù)據(jù)不連續(xù)不便于業(yè)務(wù)處理。

具體的拆分方法由使用場景決定。

如果以后要提取整個數(shù)據(jù)進(jìn)行統(tǒng)計分析，比如原始數(shù)據(jù)和中間數(shù)據(jù)，那么分區(qū)優(yōu)先。便于歷史數(shù)據(jù)的連續(xù)提取和每月刪除，對于海量數(shù)據(jù)刪除是痛苦的。子分區(qū)和分區(qū)內(nèi)索引也可以在分區(qū)內(nèi)建立。

如果用于業(yè)務(wù)數(shù)據(jù)或最終統(tǒng)計結(jié)果，則考慮在數(shù)據(jù)庫劃分后再劃分表，數(shù)據(jù)按照業(yè)務(wù)維度“統(tǒng)一”存儲在不同的表上。比如對單個數(shù)取CRC，然后對數(shù)據(jù)表個數(shù)取模。

有很多數(shù)據(jù)，屬于時間序列數(shù)據(jù)的性質(zhì)，或者日志類型，都是只插入，很少或者根本沒有Update，幾乎沒有Delete。

這類數(shù)據(jù)有一個關(guān)鍵時間字段來決定數(shù)據(jù)什么時候到達(dá)，比如input date/CreateTime/UpdateTime，可以通過觸發(fā)器的方式填充當(dāng)前時間。

基于時間維度提取時間序列數(shù)據(jù)進(jìn)行分析時，必須保證所有數(shù)據(jù)都能按時間域升序找到，不會遺漏或重復(fù)搜索某些行。

第三，高效查詢

對于海量數(shù)據(jù)查詢，命中指數(shù)必須100%確定。code=xxx或updatetime >: =:start和updatetime<。:結(jié)束.

按主鍵查詢命中單行或少量數(shù)據(jù)；

根據(jù)時間查詢，一定要合理選擇時間間隔(開始、結(jié)束)，最好將查詢結(jié)果控制在10000~20000行左右。

比如考慮到高峰時段，我們一般以5秒的間隔進(jìn)行查詢，一般會得到10000 ~ 40000行。

使用數(shù)據(jù)時，可能會有很多查詢條件，但最重要的是時間間隔。

由于數(shù)據(jù)量大，DBMS本身的統(tǒng)計信息收集可能非常不及時，導(dǎo)致執(zhí)行計劃中選擇了錯誤的索引方案。在這種情況下，需要手動收集信息，甚至在查詢語句中強(qiáng)制指定索引。

第四，批量寫作

借助內(nèi)存計算，我們經(jīng)?？梢栽诙虝r間內(nèi)計算出幾十萬甚至上百萬的數(shù)據(jù)，這些數(shù)據(jù)需要寫入數(shù)據(jù)庫。

一般數(shù)據(jù)庫的Insert/Update性能只有3000 ~ 5000tps，很難在有索引負(fù)擔(dān)的情況下快速將數(shù)據(jù)寫入其中。

以甲骨文為例。它的OracleCommand有一個超級函數(shù)ArrayBindCount，可以為一個參數(shù)化的寫操作綁定多個組(例如，5000組/行)。

這種方法可以使其獲得最高的寫入性能，實際服務(wù)使用量可以達(dá)到30000tps左右。

MySql和SQLite都有自己獨特的批量寫功能，支持netcore。

SqlServer也有批量寫功能，但還不支持netcore。

MySql解決方案寫在另一篇文章里。

動詞 （verb的縮寫）總結(jié)

關(guān)系數(shù)據(jù)庫存儲大數(shù)據(jù)的關(guān)鍵點是:簡單存儲、分區(qū)和表劃分、高效索引和批量寫入！

原地址:https://www.cnblogs.com/nnhy/p/DbForBigData.html