數(shù)據(jù)架構(gòu)規(guī)劃

1、數(shù)據(jù)架構(gòu)規(guī)劃一當(dāng)前架構(gòu) 結(jié)合研發(fā)二部數(shù)據(jù)量最大的校訊通產(chǎn)品來描述，其他的產(chǎn)品在性能上出現(xiàn)瓶頸，可以向校訊通靠攏。數(shù) 據(jù)庫整體架構(gòu)：目前校訊通產(chǎn)品根據(jù)用戶量的多少以及數(shù)據(jù)庫服務(wù)資源的繁忙程度，橫向采用了歷史庫+當(dāng)前庫的分庫架構(gòu)或者單一的當(dāng)前庫架構(gòu)，其中歷史庫只作 為web平臺讀數(shù)據(jù)庫，縱向結(jié)合了applications的memcache+Sybase ASE12.5傳統(tǒng)永久磁盤化數(shù)據(jù)庫架構(gòu)。數(shù)據(jù)模型架構(gòu)：原則上采用了一事一地的數(shù)據(jù)模型（3NF范式），為了性能考慮，一些大數(shù)據(jù)量表適當(dāng)?shù)囊昧藬?shù)據(jù)冗余，根據(jù)業(yè)務(wù)再結(jié)合采用了當(dāng)前表+歷史表的數(shù)據(jù)模型。以下就用圖表來進(jìn)行當(dāng)前數(shù)據(jù)架構(gòu)的說明：橫向分庫數(shù)據(jù)庫

2、架構(gòu)圖：縱向app layer+memcache layler+disk db layer圖：其中web層指的是客戶端瀏覽器層，邏輯上：app層指的是應(yīng)用服務(wù)層，mc層指的是memcache的客戶端層，ms層指的是memcache的服務(wù)層，db層指的是目前永久磁盤化的數(shù)據(jù)庫層，當(dāng)然在物理機(jī)器上可能app層跟mc層，ms層是重疊的部署在相同服務(wù)器上。數(shù)據(jù)模型架構(gòu)圖： 其中以上數(shù)據(jù)模型中除了少數(shù)幾張表外其他的都有歷史表存在，當(dāng)然有很多表是沒在這個模型圖中的，這部分是核心數(shù)據(jù)模型。這部分模型對象中也包括了一些冗余 性的設(shè)計(jì)，比如用戶中有真實(shí)姓名，特別是不在這個模型內(nèi)，由模型核心表產(chǎn)生的一些統(tǒng)計(jì)報(bào)表，

3、為了查詢的性能冗余了合理一些學(xué)校名稱，地區(qū)名稱等方面的設(shè) 計(jì)。二劣勢現(xiàn)象1.流水表性能瓶頸 當(dāng)前架構(gòu)的性能瓶頸集中在流水表的訪問上，最大流水表的記錄量達(dá)到了超5億級別，這是由于目前外網(wǎng)在用的sybase數(shù)據(jù)庫系統(tǒng)版本，沒有采取很好的關(guān)于 分區(qū)的技術(shù)。曾經(jīng)有過把流水表進(jìn)行物理水平分割，把不同月份的數(shù)據(jù)分割放在不同的物理表上的模型改造設(shè)想，礙于產(chǎn)生的應(yīng)用程序修改工作量大，老舊數(shù)據(jù)遷移 的麻煩，再加上進(jìn)行了從單庫架構(gòu)改造到分庫架構(gòu)后，數(shù)據(jù)庫性能瓶頸就不是特別突出。所以模型改造這部分工作沒展開。無 論是單庫或是分庫的模式，出現(xiàn)平臺訪問數(shù)據(jù)庫的性能瓶頸依然集中在大流水表上，在訪問高峰高并發(fā)量情況下，短信

4、的流水表進(jìn)程堵塞，數(shù)據(jù)庫服務(wù)I/O ,CPU的資源耗費(fèi)達(dá)到頂點(diǎn)，在服務(wù)器硬件環(huán)境不是特別理想情況下，出現(xiàn)了一定概率造成用戶訪問緩慢甚至覺得頁面無法響應(yīng)現(xiàn)象，造成了用戶體念不良影響。2. 運(yùn)營維護(hù)難點(diǎn) 1)歷史數(shù)據(jù)清理運(yùn)維工作 為了存儲充分利用，為了性能的提升，需要定期進(jìn)行不再使用的歷史數(shù)據(jù)清理，由 于清理的數(shù)據(jù)量龐大，傳統(tǒng)的數(shù)據(jù)清理方法根本不可能保證一個晚上有效清理完畢，確保平臺第二天正常的運(yùn)行。雖然目前已經(jīng)實(shí)行了比較高效且可行的數(shù)據(jù)清理方 法，但是每次實(shí)行都需要晚上到通宵進(jìn)行處理，使得數(shù)據(jù)清理的運(yùn)維工作特別勞累，影響到運(yùn)維人員第二天的正常出勤，間接就有可能影響到數(shù)據(jù)庫的正常運(yùn)維監(jiān) 控，導(dǎo)致數(shù)

5、據(jù)庫問題出現(xiàn)。 2)防止索引失效而進(jìn)行的統(tǒng)計(jì)量更新運(yùn)維工作 由于流水表數(shù)據(jù)變動量大，容易導(dǎo)致流水表的索引失效，從而需要定期的進(jìn)行索引甚至整表的統(tǒng)計(jì)量更新工作，統(tǒng)計(jì)量更新時間跟流水表的數(shù)據(jù)總量成正比關(guān)系，所 以導(dǎo)致統(tǒng)計(jì)量更新速度比較慢，不能確保在計(jì)劃時間內(nèi)，統(tǒng)計(jì)量更新的完全成功，而且目前外網(wǎng)安裝的sybase12.5版本是最低一個的EBF版本，存在較 多BUG,在索引統(tǒng)計(jì)量更新過程中可能導(dǎo)致數(shù)據(jù)庫出現(xiàn)病態(tài)，進(jìn)而影響第二天數(shù)據(jù)庫的正常運(yùn)行。3.運(yùn)維監(jiān)控紕漏（此部分非架構(gòu)原因引起） 當(dāng)前的數(shù)據(jù)庫監(jiān)控以及運(yùn)維維護(hù)還存在一些紕漏，出現(xiàn)了多次數(shù)據(jù)庫設(shè)備空間使用完畢，沒有及時添加數(shù)據(jù)庫設(shè)備空間導(dǎo)致數(shù)據(jù)庫掛起

6、問題，也多次出現(xiàn)了數(shù)據(jù)庫日 志空間占滿導(dǎo)致數(shù)據(jù)庫掛起問題。此類問題還是比較明顯，還有一類問題，不是整庫掛起，而是部分業(yè)務(wù)表訪問異常，運(yùn)維可能監(jiān)控不到，等用戶訪問到了這部分業(yè) 務(wù)功能不正常，由用戶反饋到運(yùn)維這邊。4.運(yùn)營統(tǒng)計(jì)報(bào)表在當(dāng)前數(shù)據(jù)模型架構(gòu)下重用性較低 由于用戶需求的漸進(jìn)性，導(dǎo)致數(shù)據(jù)庫統(tǒng)計(jì)報(bào)表在數(shù)據(jù)模型設(shè)計(jì)時沒有站在至高點(diǎn)，隨著用戶需求的不斷積累，數(shù)據(jù)庫統(tǒng)計(jì)報(bào)表對象也跟著不斷積累，發(fā)現(xiàn)目前存在比較大一部分的統(tǒng)計(jì)報(bào)表數(shù)據(jù)在不同數(shù)據(jù)庫對象之間重復(fù)統(tǒng)計(jì)，沒有充分發(fā)揮統(tǒng)計(jì)數(shù)據(jù)的重用性。5.沒利用集群技術(shù) 當(dāng)前的數(shù)據(jù)庫架構(gòu)還沒采用成熟的集群技術(shù)，集群技術(shù)并不單單指單一數(shù)據(jù)庫系統(tǒng)的集群，可以混合集群，

7、比如內(nèi)存數(shù)據(jù)庫跟傳統(tǒng)永久磁盤化數(shù)據(jù)庫系統(tǒng)集群。6.分庫架構(gòu)還可完善 當(dāng)前的分庫架構(gòu)還可以繼續(xù)完善，引用成熟的數(shù)據(jù)庫主從分離，讀寫分離技術(shù)。7.內(nèi)存數(shù)據(jù)庫技術(shù)還沒充分利用 當(dāng)前的數(shù)據(jù)庫架構(gòu)雖然在前端使用了memcache技術(shù)，但是還可以繼續(xù)完善使用內(nèi)存數(shù)據(jù)庫技術(shù)再結(jié)合異步寫技術(shù)，使得架構(gòu)相得益彰。8.適合海量數(shù)據(jù)高并發(fā)讀寫，高效率存儲的非關(guān)系型數(shù)據(jù)庫沒充分利用 當(dāng)前的數(shù)據(jù)庫架構(gòu)還沒采用正在興起的NoSql，NewSql技術(shù)（目前部分外圍系統(tǒng)采用了mongodb來做試驗(yàn)品，而這部分系統(tǒng)的數(shù)據(jù)量并不大，非關(guān) 系型數(shù)據(jù)庫海量數(shù)據(jù)高并發(fā)訪問的高效性優(yōu)勢沒有體現(xiàn)出來，從而也沒掌握真正的使用經(jīng)驗(yàn)），當(dāng)然這種

8、數(shù)據(jù)庫也有缺點(diǎn)，就是數(shù)據(jù)庫事務(wù)一致性，數(shù)據(jù)庫的寫實(shí)時 性和讀實(shí)時性，復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢是無法滿足的。三改進(jìn)思路 在第二部分的劣勢現(xiàn)象中，總結(jié)了當(dāng)前數(shù)據(jù)庫架構(gòu)以及數(shù)據(jù)模型架構(gòu)的缺陷，缺陷還比較多，從另外一個角度也反映了公司產(chǎn)品數(shù)據(jù)庫架構(gòu)改進(jìn)和提升的空間還比較大，將來隨著不斷的迭代改進(jìn)，可以承受的業(yè)務(wù)量提升的空間也相應(yīng)的比較大。下面就根據(jù)劣勢現(xiàn)象進(jìn)行針對性的闡述改進(jìn)思路：1.流水表性能瓶頸改進(jìn) Sybase12.5沒有很好的解決大數(shù)據(jù)量表的性能問題，但是通過數(shù)據(jù)庫轉(zhuǎn)到Oracle后，充分利用Oracle分區(qū)表，分區(qū)索引的特性來提升流水表 的訪問性能，邏輯上表仍然是一張完整的表，只

9、是將表中的數(shù)據(jù)在物理上存放到多個表空間(物理文件上，這樣查詢數(shù)據(jù)時，不至于每次都掃描整張表。由于邏輯上 仍舊一表，使得應(yīng)用程序不需要修改，也避免了這個劣勢點(diǎn)描述的帶來額外許多開發(fā)工作量的問題，但是效果幾乎等同水平分割數(shù)據(jù)模型。2.大流水表運(yùn)維難的改進(jìn) 1)歷史數(shù)據(jù)清理運(yùn)維工作 在Oracel數(shù)庫系統(tǒng)中，針對對大流水表每個月的數(shù)據(jù)進(jìn)行分區(qū)，這樣運(yùn)維人員在清理歷史月份的數(shù)據(jù)時候，只要通過TRUNCATE PARTITION、DROP PARTITION的Oracle本身的分區(qū)維護(hù)命令輕松快速清理掉分區(qū)的數(shù)據(jù)（既指定月份的流水?dāng)?shù)據(jù)） 2)防止索引失效而進(jìn)行的統(tǒng)計(jì)量更新運(yùn)維工作 同樣Oracle也有等

10、同于sybase的統(tǒng)計(jì)量更新工作，在Oracle中通過對大流水表的分區(qū)工作后，進(jìn)行統(tǒng)計(jì)量的更新工作同樣就快捷簡易，可以通過ANALYZE PARTITION的統(tǒng)計(jì)量分析維護(hù)命令可以輕松快速對指定分區(qū)的統(tǒng)計(jì)量進(jìn)行更新。3.運(yùn)維監(jiān)控紕漏的改進(jìn) 主要分兩個方面：a)數(shù)據(jù)庫剩余空間方面的監(jiān)控；b)數(shù)據(jù)庫出錯日志的監(jiān)控。這兩個監(jiān)控雖然通過人為主動性的查看數(shù)據(jù)庫相關(guān)信息可以監(jiān)控到，但是總歸還是 會有疏忽遺漏的時候，只是出問題幾率高低之分。所以這里再加一道監(jiān)控，就是通過數(shù)據(jù)庫服務(wù)器端的監(jiān)控程序主動發(fā)回有問題或者告警的信息給運(yùn)維人員。這道監(jiān) 控程序可以通過shell程序以及數(shù)據(jù)庫程序，結(jié)合數(shù)據(jù)庫日志以及剩余空

11、間信息以短信或者郵件的方式發(fā)回給運(yùn)維人員。在數(shù)據(jù)庫剩余空間方面甚至可以通過數(shù) 據(jù)庫本身閥值的設(shè)置，做到自動截取日志，自動添加設(shè)備。4.運(yùn)營統(tǒng)計(jì)報(bào)表數(shù)據(jù)模型的改進(jìn) 由于原先一些報(bào)表模型存在著數(shù)據(jù)統(tǒng)計(jì)的重復(fù)性，在晚上定時task中既占用了任務(wù)列表的總時間，也對其他并行的task運(yùn)行造成了一定的資源爭用，影響了 數(shù)據(jù)庫性能。所以在這里提出了一種類似蒲公英性質(zhì)的模型，數(shù)據(jù)通過發(fā)散模式，即插即用到不同的運(yùn)營統(tǒng)計(jì)報(bào)表中，勢必需要改進(jìn)當(dāng)前接近一事一地的3范式模 型，把原先的數(shù)據(jù)模型拆散，從縱向和橫向都接近最小粒度需求的數(shù)據(jù)模型。使得統(tǒng)計(jì)數(shù)據(jù)可以重復(fù)使用，不同的統(tǒng)計(jì)報(bào)表通過這些原子性的統(tǒng)計(jì)數(shù)據(jù)再組合成報(bào)表 所

12、需要的數(shù)據(jù)，當(dāng)然這里需要一個平衡，并不完全等同蒲公英模型的統(tǒng)計(jì)粒度越細(xì)越好，因?yàn)樵郊?xì)也代表著原始的統(tǒng)計(jì)數(shù)據(jù)量越大，一會影響原始統(tǒng)計(jì)的性能，二會 影響組合成報(bào)表的性能，三會占用更多的存儲空間。這個平衡度需要掌控好。5.利用集群技術(shù) 當(dāng)然通過了前面4點(diǎn)的改進(jìn)之后，數(shù)據(jù)庫性能會比目前的架構(gòu)提升一定的性能，至于集群技術(shù)就可以作為前面4點(diǎn)改進(jìn)后的補(bǔ)充和擴(kuò)展，如果在改進(jìn)后，依然還存在 較大性能瓶頸情況下可以采用Oracle RAC技術(shù)。甚至采用基于內(nèi)存數(shù)據(jù)庫的分布式數(shù)據(jù)庫架構(gòu)的混合集群技術(shù)。比如在Oracle數(shù)據(jù)庫及Web服務(wù)之間加一層Ameoba分布式數(shù)據(jù)庫代 理結(jié)合內(nèi)存數(shù)據(jù)庫的架構(gòu)，6.分庫架構(gòu)完善改

13、進(jìn) 目前的數(shù)據(jù)庫架構(gòu)采用了分庫方式，但是主庫（當(dāng)前庫）的讀寫卻是沒有分離的，縱觀淘寶的數(shù)據(jù)庫架構(gòu)演進(jìn)歷程，確是在某個歷程碑點(diǎn)做到了很好的讀寫分離，應(yīng) 用到DB的數(shù)據(jù)寫入與查詢從雙向通行變成了單向通行，通行效率更高，大大避免了相互影響?！敖璧佬旭偂钡那闆r不再出現(xiàn)。淘寶那個碑點(diǎn)做到了以下幾點(diǎn)：1)寫庫為集中式的oracle環(huán)境,提供數(shù)據(jù)安全性保障。2)讀庫使用mysql, 采用數(shù)據(jù)分片，分庫分表，每臺mysql放少量的數(shù)據(jù),單個數(shù)據(jù)分片內(nèi)部采用mysql復(fù)制機(jī)制。3)讀庫的超大memory容量，起到了很好的cache作用，在內(nèi)存中的數(shù)據(jù)查詢性能遠(yuǎn)遠(yuǎn)高于在硬盤上的性能4)oracle到多臺mysql

14、按規(guī)則復(fù)制結(jié)合淘寶架構(gòu)的思考，校訊通大流水也可以做到垂直分割到不同的服務(wù)器，也可以做到水品分割到不同的服務(wù)器，通過不同的服務(wù)器訪問不同的流水表或者是不同范圍數(shù)據(jù)的流水表，那提升性能是肯定的。不過也要平衡考慮到應(yīng)用程序開發(fā)的簡便性。7.內(nèi)存數(shù)據(jù)庫技術(shù)利用 常見的內(nèi)存數(shù)據(jù)庫產(chǎn)品包括商業(yè)版和免費(fèi)版兩類。商業(yè)版如：Altibase，Timesten，Berkley DB等。他們在電信，金融，證券等高性能計(jì)算應(yīng)用中運(yùn)用較為廣泛。商業(yè)版功能強(qiáng)大，然而，價格比較昂貴，不適合目前“廉價PC+免費(fèi)軟件”的架構(gòu)搭建思 想。開源領(lǐng)域產(chǎn)品主要有H2，HsqlDB，Derby，BerkeleyDB等。在混合集群架構(gòu)中，

15、內(nèi)存數(shù)據(jù)庫將承擔(dān)OLTP的職責(zé)，因此除了讀寫性能外，功能的完備，事務(wù)等都需要作為優(yōu)先評估的因素。盛傳H2是一個開源的高性能內(nèi)存數(shù)據(jù)庫，可以通過整合Ameoba與H2，夾在applications和傳統(tǒng)db層之間來達(dá)到內(nèi)存數(shù)據(jù)庫層的架構(gòu)部署。Ameoba是分布式數(shù)據(jù)庫代理，它與MySQL整合已經(jīng)在阿里巴巴核心業(yè)務(wù)中成功運(yùn)用。如果僅將數(shù)據(jù)庫節(jié)點(diǎn)看作一個存儲，MySQL Node和H2 Node并無本質(zhì)區(qū)別。JDBC驅(qū)動，DB切分，路由，皆由Ameoba統(tǒng)一負(fù)責(zé)。8.非關(guān)系型數(shù)據(jù)庫的使用 外圍的非核心數(shù)據(jù)，但是數(shù)據(jù)量又是比較大的的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫可以采用非關(guān)系型數(shù)據(jù)庫，這是由非關(guān)系型數(shù)據(jù)庫的一些基本特

16、性決定的。非關(guān)系型數(shù)據(jù)庫有滿足如下需求的優(yōu)點(diǎn)特性：1)High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求2)Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求3)High Scalability & High Availability- 對數(shù)據(jù)庫的高可擴(kuò)展性和高可用性的需求但同時伴隨不能滿足以下需求的缺點(diǎn)：1)數(shù)據(jù)庫事務(wù)一致性需求2)數(shù)據(jù)庫的寫實(shí)時性和讀實(shí)時性需求3)對復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求正 是由于以上的優(yōu)缺點(diǎn)也決定了，核心的需要保持一致性的數(shù)據(jù)，需要復(fù)雜關(guān)聯(lián)的數(shù)據(jù)，需要實(shí)時訪問的數(shù)據(jù)不要采用關(guān)系型數(shù)據(jù)庫，如果通過ETL把關(guān)系型數(shù)據(jù)庫 的流水?dāng)?shù)據(jù)

17、冗余基本信息，組成可以直接查詢的業(yè)務(wù)信息數(shù)據(jù)，導(dǎo)入到非關(guān)系型數(shù)據(jù)庫后，那對海量流水?dāng)?shù)據(jù)的查詢速度提升空間是很大的。其中代表型的非關(guān)系型 數(shù)據(jù)有Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai，ThruDB等等非常之多。四架構(gòu)計(jì)劃 通過以上當(dāng)前架構(gòu)劣勢以及改進(jìn)思路的總結(jié)，改善的架構(gòu)計(jì)劃就比較清晰了，以下還是通過橫向的整體數(shù)據(jù)庫架構(gòu)，縱向的整體數(shù)據(jù)庫架構(gòu)，以及數(shù)據(jù)模型的架構(gòu)改進(jìn)來做為

18、新的架構(gòu)計(jì)劃。風(fēng)險最小，改動工作量最小的架構(gòu)就是改進(jìn)思路中以第4點(diǎn)和第5點(diǎn)之間為分割線。這條分割線前的數(shù)據(jù)架構(gòu)基本不需要變動，主要變動的就是數(shù)據(jù)模型架構(gòu)中的流水表對象，以及數(shù)據(jù)庫服務(wù)器后臺添加監(jiān)控以及智能處理的運(yùn)維程序工具。主要改進(jìn)的數(shù)據(jù)模型流水表對象如下圖：同樣進(jìn)行分區(qū)的還有其他的一些大流水表，這里不一一詳述，這些流水表從sybase進(jìn)入oracle的分區(qū)表，在數(shù)據(jù)庫轉(zhuǎn)型升級過程中完成。還有一點(diǎn)就是關(guān)于數(shù)據(jù)庫監(jiān)控工具在架構(gòu)中的部署，如下圖所示：以上架構(gòu)改進(jìn)計(jì)劃可以在一期中先完成。看運(yùn)行效果狀態(tài)，第5點(diǎn)之后的改進(jìn)計(jì)劃幾乎就是架構(gòu)的重構(gòu)了，所以涉及的工作量更大，如果在第1，2，3，4點(diǎn)改進(jìn)后數(shù)據(jù)庫運(yùn)行穩(wěn)定，后續(xù)的改進(jìn)，可以通過實(shí)驗(yàn)和應(yīng)用結(jié)合逐步實(shí)施起來，作為應(yīng)付更大型的業(yè)務(wù)應(yīng)用技術(shù)儲備。 下面結(jié)合5，6，7，8點(diǎn)的改進(jìn)思路做個架構(gòu)規(guī)劃，也就是分布式的內(nèi)存與傳統(tǒng)數(shù)據(jù)庫結(jié)合的混合集群架構(gòu)模式，再加上外圍產(chǎn)品的非關(guān)系型數(shù)據(jù)庫，如下圖所示（服務(wù)器和db合為同個節(jié)點(diǎn)說明，否則圖片篇幅占用過大）： 上面的架構(gòu)圖中，application（應(yīng)用服務(wù)層），data cache層，disk db layer層已經(jīng)實(shí)現(xiàn)，但是disk db Laye