現(xiàn)在互聯(lián)網(wǎng)公司業(yè)務(wù)發(fā)展都是非常飛速，當(dāng)業(yè)務(wù)發(fā)展到一定規(guī)模妄辩，就得考慮如何去做服務(wù)治理山上，大家的重心一般放在微服務(wù)的應(yīng)用架構(gòu)設(shè)計層面佩憾，往往比較容易忽略關(guān)系數(shù)據(jù)庫的設(shè)計規(guī)劃干花。無論上層服務(wù)治理的如何澈吨，其實(shí)關(guān)系數(shù)據(jù)庫還是各個系統(tǒng)的基礎(chǔ)和核心谅辣，系統(tǒng)的穩(wěn)定性，高可用性桑阶，高性能是和數(shù)據(jù)庫有最直接的關(guān)系，所以我覺得服務(wù)治理的同時也需要同時考慮數(shù)據(jù)方面的相關(guān)規(guī)劃和實(shí)現(xiàn)蚣录，但是只有基礎(chǔ)扎實(shí)了萎河，上層服務(wù)才能更加穩(wěn)固，也才能飛的更高更快玛歌。本人最近在公司做些數(shù)據(jù)相關(guān)的工作擎椰，以下是我總結(jié)的數(shù)據(jù)治理一些關(guān)注點(diǎn)，希望能給開發(fā)童鞋一點(diǎn)幫助值朋，盡量少挖坑：

1.設(shè)計規(guī)范

對于數(shù)據(jù)庫巩搏，表塔猾，字段，索引等的命名需要統(tǒng)一規(guī)范丈甸，方便dba的管理睦擂，提升開發(fā)團(tuán)隊(duì)之間的溝通成本，最好是提供數(shù)據(jù)庫change log平臺來統(tǒng)一上線管理淘正，這樣可以進(jìn)行審核和規(guī)范落地

數(shù)據(jù)庫索引設(shè)計，數(shù)據(jù)庫的穩(wěn)定性囤采，高可用性惩淳，高性能都和索引息息相關(guān)思犁，按照最左前綴原則來設(shè)計，沒有把握時激蹲，可以找dba進(jìn)行求助

一定要給每個表設(shè)計主鍵学辱，創(chuàng)建時間，修改時間字段策泣，可以對數(shù)據(jù)修改的紀(jì)錄進(jìn)行跟蹤着降，也可以方便數(shù)據(jù)倉庫進(jìn)行增量數(shù)據(jù)拉取拗军，創(chuàng)建時間／修改時間可以通過封裝DAO組件默認(rèn)設(shè)置值

對于互聯(lián)網(wǎng)應(yīng)用发侵，盡量遵守范式設(shè)計規(guī)范，但是冗余字段的設(shè)計也應(yīng)該適時考慮盅弛，如果兩個以上業(yè)務(wù)功能點(diǎn)需要同時join某3個表叔锐，建議設(shè)計冗余字段來解決

數(shù)據(jù)庫設(shè)計的規(guī)范還有很多，就不一一例舉讨盒，最主要還是如何保證規(guī)范的施行步责。數(shù)據(jù)庫設(shè)計的規(guī)范很多公司都有返顺，但是并沒有很好的實(shí)施禀苦，導(dǎo)致數(shù)據(jù)庫看起來還是非常混亂遂鹊，很多情況是缺少流程的管理和工具的輔助振乏，一些硬性的規(guī)范就可以通過工具來控制，對于線上應(yīng)用的DDL發(fā)版都需要DBA進(jìn)行審核才能進(jìn)行秉扑。對于高頻或者數(shù)據(jù)量大的DML語句同樣需要DBA進(jìn)行審核才能發(fā)布更新慧邮。

2.數(shù)據(jù)分域

當(dāng)業(yè)務(wù)經(jīng)過野蠻增長，單一系統(tǒng)無法支撐業(yè)務(wù)時邻储，就需要進(jìn)行業(yè)務(wù)拆分赋咽，同樣也應(yīng)該進(jìn)行數(shù)據(jù)拆分吨娜，業(yè)務(wù)應(yīng)用和schema需要做到一一對應(yīng)脓匿，并且進(jìn)行權(quán)限隔離，一個schema只能被一個應(yīng)用所有宦赠，所有對這個schema的數(shù)據(jù)的查詢陪毡，新建，修改只能通過這個系統(tǒng)的接口來調(diào)用

公共數(shù)據(jù)服務(wù)統(tǒng)一管理勾扭，比如國家毡琉，城市，交易日歷妙色，不能會產(chǎn)生有大量相同數(shù)據(jù)的表桅滋，造成數(shù)據(jù)重復(fù)隱患，這些數(shù)據(jù)保存時也盡量原子化身辨，避免事后拆分

數(shù)據(jù)指標(biāo)也要做到統(tǒng)一來源丐谋，如投資量，投資收益率煌珊，AUM号俐，累積收益等統(tǒng)計指標(biāo)，其他應(yīng)用應(yīng)該根據(jù)同一來源數(shù)據(jù)進(jìn)行業(yè)務(wù)邏輯處理定庵，如果有不同來源或者每個系統(tǒng)自己計算的話吏饿，不但公司內(nèi)部容易混淆，而且很容易被用戶投訴

復(fù)雜計算的業(yè)務(wù)盡量不要根據(jù)用戶的請求來做實(shí)時計算蔬浙，比如互聯(lián)網(wǎng)金融網(wǎng)站的資產(chǎn)類猪落，收益類數(shù)據(jù)，一般都需要跨越多個schema來獲取敛滋，金融產(chǎn)品形態(tài)越多许布，計算就越復(fù)雜。如果進(jìn)行實(shí)時計算的話绎晃，會很耗費(fèi)系統(tǒng)資源特別是數(shù)據(jù)庫資源蜜唾，可以考慮由每個金融產(chǎn)品系統(tǒng)自身保存這個數(shù)據(jù)杂曲，也就是每個用戶投資不同類型的產(chǎn)品，都需要為這個用戶建立虛擬帳戶袁余，這個賬戶可以維護(hù)用戶的資產(chǎn)擎勘，收益等情況。另外一個思路時定義一個標(biāo)準(zhǔn)的消息颖榜，當(dāng)用戶的資產(chǎn)棚饵，收益有變化時，發(fā)送消息掩完，由資產(chǎn)服務(wù)來統(tǒng)一處理這些消息噪漾，不過需要考慮消息的丟失，延時等情況且蓬，難度比較大欣硼。如果對數(shù)據(jù)的實(shí)時性要求不高的話，能夠線下大數(shù)據(jù)等方式來計算這些數(shù)據(jù)的話更好恶阴。

3.開發(fā)優(yōu)化

數(shù)據(jù)庫設(shè)計時不單要考慮業(yè)務(wù)的實(shí)現(xiàn)诈胜，也要同時考慮代碼的性能，更勝者還需要考慮給其他的數(shù)據(jù)使用者（數(shù)據(jù)聚合／數(shù)據(jù)分析等）提供方便

不要過度設(shè)計冯事，每個系統(tǒng)都會有些表的字段從來沒有值焦匈，可能是當(dāng)時預(yù)留字段，但是現(xiàn)在看來昵仅，很多預(yù)留字段都是浪費(fèi)的缓熟，建議還是真正需要時再添加不遲

無論是做數(shù)據(jù)結(jié)構(gòu)設(shè)計還是sql的編寫，都應(yīng)該控制復(fù)雜度摔笤，復(fù)雜的sql會導(dǎo)致數(shù)據(jù)庫load的沖高荚虚，當(dāng)PV上來時，系統(tǒng)響應(yīng)變慢籍茧，然后系統(tǒng)請求堆積，嚴(yán)重的最后會導(dǎo)致整個系統(tǒng)完全無法提供服務(wù)梯澜，所以每個開發(fā)童鞋寫sql時需要優(yōu)先考慮性能問題寞冯，讓每條sql盡量簡單，都能走到對的索引晚伙，通過應(yīng)用程序去解決復(fù)雜的sql邏輯查詢

不要把所有數(shù)據(jù)都丟到數(shù)據(jù)庫吮龄，特別是數(shù)據(jù)量大的日志型數(shù)據(jù)可以通過日志輸出，通過elk／flume+storm等方式拉取到es中進(jìn)行查詢跟蹤咆疗，如果硬是要保存到數(shù)據(jù)庫漓帚，那只需要保存異常數(shù)據(jù)即可。用戶行為數(shù)據(jù)可以發(fā)送消息出去午磁，由其他應(yīng)用來監(jiān)聽消息并且保存到Redis／MongDB中尝抖，比如登陸相關(guān)數(shù)據(jù)毡们，投資行為等數(shù)據(jù)，如果這些數(shù)據(jù)需要用來做業(yè)務(wù)流控昧辽，如現(xiàn)在登錄次數(shù)等業(yè)務(wù)場景衙熔，可以使用redis的數(shù)據(jù)過期機(jī)制來實(shí)現(xiàn)

不要給用戶太大的空間進(jìn)行數(shù)據(jù)的輸入，盡量提供選擇框讓用戶選擇搅荞，防止臟數(shù)據(jù)的產(chǎn)生红氯，關(guān)鍵字段要設(shè)置為必填，否則會給數(shù)據(jù)分析時的數(shù)據(jù)清洗帶來麻煩

設(shè)計好表的UK咕痛，可以避免數(shù)據(jù)的重復(fù)痢甘，也可以給接口的冪等性提供支持

對于數(shù)據(jù)量大的業(yè)務(wù)處理建議使用異步化的方式來實(shí)現(xiàn)，通過發(fā)送消息的方式進(jìn)行數(shù)據(jù)分片茉贡，然后可以對數(shù)據(jù)進(jìn)行分布式處理塞栅，提高數(shù)據(jù)處理速度

對于大表，首先考慮數(shù)據(jù)庫的優(yōu)化块仆，然后再考慮讀寫分離构蹬，是否可以做分區(qū)表，數(shù)據(jù)歸檔來提升性能悔据，最后才去考慮進(jìn)行分表分庫的設(shè)計庄敛，分表分庫無論對于系統(tǒng)本身的設(shè)計開發(fā)很難的把握，同時對于數(shù)據(jù)的使用者也是增加了復(fù)雜度

對于緩存數(shù)據(jù)的使用科汗，盡量不要緩存用戶唯度的數(shù)據(jù)藻烤，這種類型的數(shù)據(jù)不但給緩存服務(wù)器帶來壓力，更主要是緩存的命中率低头滔，所以對于緩存的使用也是設(shè)計的關(guān)注點(diǎn)怖亭，不要因?yàn)槟硞€緩存數(shù)據(jù)的暴增而拖垮整個緩存服務(wù)器

隨著數(shù)據(jù)量的積累，有些數(shù)據(jù)過了其的生命周期坤检，也就是說這些數(shù)據(jù)變成了冷數(shù)據(jù)兴猩，沒有系統(tǒng)需要再使用它了，那么我們就要定時的去做一些數(shù)據(jù)的歸檔早歇，騰出數(shù)據(jù)庫資源給熱數(shù)據(jù)來使用

涉及數(shù)據(jù)量大的更新倾芝，如某個表新增的非空字段等，建議分批進(jìn)行更新箭跳。分批不但為了數(shù)據(jù)庫的穩(wěn)定晨另，防止引起數(shù)據(jù)庫的死鎖，同時也防止ETL工具拉取大量的更新數(shù)據(jù)谱姓，因?yàn)楹芏鄨蟊硇枰蕾嘐TL同步完成數(shù)據(jù)借尿，如果ETL同時超時的話，很多定時報表會運(yùn)行失敗，有可能需要手工再次運(yùn)行報表任務(wù)路翻，所以進(jìn)行大數(shù)據(jù)量更新時狈癞，一定要通知DBA和數(shù)據(jù)團(tuán)隊(duì)進(jìn)行跟蹤關(guān)注。

4.數(shù)據(jù)監(jiān)控

監(jiān)控是最后的守護(hù)者帚桩，可以及時的發(fā)現(xiàn)系統(tǒng)的性能問題亿驾，對于數(shù)據(jù)庫來說，

DBA可以通過數(shù)據(jù)庫的監(jiān)控工具來實(shí)時的對數(shù)據(jù)庫進(jìn)行監(jiān)控账嚎，對于核心表的數(shù)據(jù)量增長趨勢莫瞬，核心表相關(guān)的sql查詢性能都需要進(jìn)行跟蹤。但是提前發(fā)現(xiàn)sql的性能問題郭蕉，進(jìn)行合適的預(yù)防則是開發(fā)團(tuán)隊(duì)需要關(guān)注的疼邀。這就需要監(jiān)控中心對sql的運(yùn)行時間和次數(shù)等指標(biāo)進(jìn)行跟蹤和匯總,如果當(dāng)前沒有監(jiān)控中心，也可以使用DruidDatasource的statFilter功能進(jìn)行跟蹤召锈，開發(fā)團(tuán)隊(duì)需要定時的去關(guān)注sql運(yùn)行時間旁振，運(yùn)行次數(shù)等指標(biāo)，隨著業(yè)務(wù)量的增長涨岁，之前高性能的sql可能會變慢拐袜，高頻sql絕對不能出現(xiàn)在long sql的列表中，需要及時改造梢薪。還有就是緩存服務(wù)器的監(jiān)控也是需要關(guān)注的蹬铺。

以上是個人的粗淺認(rèn)識，歡迎各位童鞋拍磚秉撇。