(完整版)數據架構規劃

數據架構規劃

一．當前架構

結合研發二部數據量最大的校訊通產品來描述，其他的產品在性能上出現瓶

頸，可以向校訊通靠攏。

數 據庫整體架構：目前校訊通產品根據用戶量的多少以及數據庫服務資源的繁

忙程度，橫向采用了歷史庫+當前庫的分庫架構或者單一的當前庫架構，其中歷

史庫只作 為web平臺讀數據庫，縱向結合了applications的

memcache+Syba ASE12.5傳統永久磁盤化數據庫架構。

數據模型架構：原則上采用了一事一地的數據模型（3NF范式），為了性能考

慮，一些大數據量表適當的引用了數據冗余，根據業務再結合采用了當前表+歷

史表的數據模型。

以下就用圖表來進行當前數據架構的說明：

橫向分庫數據庫架構圖：

縱向app layer+memcache layler+disk db layer圖：

其中web層指的是客戶端瀏覽器層，邏輯上：app層指的是應用服務層，mc

層指的是memcache的客戶端層，ms層指的是memcache的服務層，db層

指的是目前永久磁盤化的數據庫層，當然在物理機器上可能app層跟mc層，

ms層是重疊的部署在相同服務器上。

數據模型架構圖：

其中以上數據模型中除了少數幾張表外其他的都有歷史表存在，當然有很多

表是沒在這個模型圖中的，這部分是核心數據模型。這部分模型對象中也包括了

一些冗余 性的設計，比如用戶中有真實姓名，特別是不在這個模型內，由模型

核心表產生的一些統計報表，為了查詢的性能冗余了合理一些學校名稱，地區名

稱等方面的設 計。

二．劣勢現象

1.流水表性能瓶頸

當前架構的性能瓶頸集中在流水表的訪問上，最大流水表的記錄量達到了超

5億級別，這是由于目前外網在用的syba數據庫系統版本，沒有采取很好的

關于 分區的技術。曾經有過把流水表進行物理水平分割，把不同月份的數據分

割放在不同的物理表上的模型改造設想，礙于產生的應用程序修改工作量大，老

舊數據遷移 的麻煩，再加上進行了從單庫架構改造到分庫架構后，數據庫性能

瓶頸就不是特別突出。所以模型改造這部分工作沒展開。

無 論是單庫或是分庫的模式，出現平臺訪問數據庫的性能瓶頸依然集中在大流

水表上，在訪問高峰高并發量情況下，短信的流水表進程堵塞，數據庫服務

I/O ,CPU的資源耗費達到頂點，在服務器硬件環境不是特別理想情況下，出現

了一定概率造成用戶訪問緩慢甚至覺得頁面無法響應現象，造成了用戶體念不良

影響。

2. 運營維護難點

1)歷史數據清理運維工作

為了存儲充分利用，為了性能的提升，需要定期進行不再使用的歷史數據清

理，

由 于清理的數據量龐大，傳統的數據清理方法根本不可能保證一個晚上有效清

理完畢，確保平臺第二天正常的運行。雖然目前已經實行了比較高效且可行的數

據清理方 法，但是每次實行都需要晚上到通宵進行處理，使得數據清理的運維

工作特別勞累，影響到運維人員第二天的正常出勤，間接就有可能影響到數據庫

的正常運維監 控，導致數據庫問題出現。

2)防止索引失效而進行的統計量更新運維工作

由于流水表數據變動量大，容易導致流水表的索引失效，從而需要定期的進

行索引甚至整表的統計量更新工作，統計量更新時間跟流水表的數據總量成正比

關系，所 以導致統計量更新速度比較慢，不能確保在計劃時間內，統計量更新

的完全成功，而且目前外網安裝的syba12.5版本是最低一個的EBF版本，存

在較 多BUG,在索引統計量更新過程中可能導致數據庫出現病態，進而影響第

二天數據庫的正常運行。

3.運維監控紕漏（此部分非架構原因引起）

當前的數據庫監控以及運維維護還存在一些紕漏，出現了多次數據庫設備空

間使用完畢，沒有及時添加數據庫設備空間導致數據庫掛起問題，也多次出現了

數據庫日 志空間占滿導致數據庫掛起問題。此類問題還是比較明顯，還有一類

問題，不是整庫掛起，而是部分業務表訪問異常，運維可能監控不到，等用戶訪

問到了這部分業 務功能不正常，由用戶反饋到運維這邊。

4.運營統計報表在當前數據模型架構下重用性較低

由于用戶需求的漸進性，導致數據庫統計報表在數據模型設計時沒有站在至

高點，隨著用戶需求的不斷積累，數據庫統計報表對象也跟著不斷積累，發現目

前存在比較大一部分的統計報表數據在不同數據庫對象之間重復統計，沒有充分

發揮統計數據的重用性。

5.沒利用集群技術

當前的數據庫架構還沒采用成熟的集群技術，集群技術并不單單指單一數據

庫系統的集群，可以混合集群，比如內存數據庫跟傳統永久磁盤化數據庫系統集

群。

6.分庫架構還可完善

當前的分庫架構還可以繼續完善，引用成熟的數據庫主從分離，讀寫分離技

術。

7.內存數據庫技術還沒充分利用

當前的數據庫架構雖然在前端使用了memcache技術，但是還可以繼續完

善使用內存數據庫技術再結合異步寫技術，使得架構相得益彰。

8.適合海量數據高并發讀寫，高效率存儲的非關系型數據庫沒充分利用

當前的數據庫架構還沒采用正在興起的NoSql，NewSql技術（目前部分外

圍系統采用了mongodb來做試驗品，而這部分系統的數據量并不大，非關 系

型數據庫海量數據高并發訪問的高效性優勢沒有體現出來，從而也沒掌握真正的

使用經驗），當然這種數據庫也有缺點，就是數據庫事務一致性，數據庫的寫實

時 性和讀實時性，復雜的SQL查詢，特別是多表關聯查詢是無法滿足的。

三．改進思路

在第二部分的劣勢現象中，總結了當前數據庫架構以及數據模型架構的缺陷，

缺陷還比較多，從另外一個角度也反映了公司產品數據庫架構改進和提升的空間

還比較大，將來隨著不斷的迭代改進，可以承受的業務量提升的空間也相應的比

較大。

下面就根據劣勢現象進行針對性的闡述改進思路：

1.流水表性能瓶頸改進

Syba12.5沒有很好的解決大數據量表的性能問題，但是通過數據庫轉到

Oracle后，充分利用Oracle分區表，分區索引的特性來提升流水表 的訪問性

能，邏輯上表仍然是一張完整的表，只是將表中的數據在物理上存放到多個表空

間(物理文件上，這樣查詢數據時，不至于每次都掃描整張表。由于邏輯上 仍舊

一表，使得應用程序不需要修改，也避免了這個劣勢點描述的帶來額外許多開發

工作量的問題，但是效果幾乎等同水平分割數據模型。

2.大流水表運維難的改進

1)歷史數據清理運維工作

在Oracel數庫系統中，針對對大流水表每個月的數據進行分區，這樣運維

人員在清理歷史月份的數據時候，只要通過TRUNCATE PARTITION、 DROP

PARTITION的Oracle本身的分區維護命令輕松快速清理掉分區的數據（既指

定月份的流水數據）

2)防止索引失效而進行的統計量更新運維工作

同樣Oracle也有等同于syba的統計量更新工作，在Oracle中通過對大

流水表的分區工作后，進行統計量的更新工作同樣就快捷簡易，可以通過

ANALYZE PARTITION的統計量分析維護命令可以輕松快速對指定分區的統計

量進行更新。

3.運維監控紕漏的改進

主要分兩個方面：a)數據庫剩余空間方面的監控；b)數據庫出錯日志的監控。

這兩個監控雖然通過人為主動性的查看數據庫相關信息可以監控到，但是總歸還

是 會有疏忽遺漏的時候，只是出問題幾率高低之分。所以這里再加一道監控，

就是通過數據庫服務器端的監控程序主動發回有問題或者告警的信息給運維人

員。這道監 控程序可以通過shell程序以及數據庫程序，結合數據庫日志以及

剩余空間信息以短信或者郵件的方式發回給運維人員。在數據庫剩余空間方面甚

至可以通過數 據庫本身閥值的設置，做到自動截取日志，自動添加設備。

4.運營統計報表數據模型的改進

由于原先一些報表模型存在著數據統計的重復性，在晚上定時task中既占用

了任務列表的總時間，也對其他并行的task運行造成了一定的資源爭用，影響

了 數據庫性能。所以在這里提出了一種類似蒲公英性質的模型，數據通過發散

模式，即插即用到不同的運營統計報表中，勢必需要改進當前接近一事一地的3

范式模 型，把原先的數據模型拆散，從縱向和橫向都接近最小粒度需求的數據

模型。使得統計數據可以重復使用，不同的統計報表通過這些原子性的統計數據

再組合成報表 所需要的數據，當然這里需要一個平衡，并不完全等同蒲公英模

型的統計粒度越細越好，因為越細也代表著原始的統計數據量越大，一會影響原

始統計的性能，二會 影響組合成報表的性能，三會占用更多的存儲空間。這個

平衡度需要掌控好。

5.利用集群技術

當然通過了前面4點的改進之后，數據庫性能會比目前的架構提升一定的性

能，至于集群技術就可以作為前面4點改進后的補充和擴展，如果在改進后，依

然還存在 較大性能瓶頸情況下可以采用Oracle RAC技術。甚至采用基于內存

數據庫的分布式數據庫架構的混合集群技術。比如在Oracle數據庫及Web服

務之間加一層 Ameoba 分布式數據庫代 理結合內存數據庫的架構，

6.分庫架構完善改進

目前的數據庫架構采用了分庫方式，但是主庫（當前庫）的讀寫卻是沒有分

離的，縱觀淘寶的數據庫架構演進歷程，確是在某個歷程碑點做到了很好的讀寫

分離，應 用到DB的數據寫入與查詢從雙向通行變成了單向通行，通行效率更

高，大大避免了相互影響。“借道行駛”的情況不再出現。淘寶那個碑點做到了

以下幾點：

1)寫庫為集中式的oracle環境,提供數據安全性保障。

2)讀庫使用mysql, 采用數據分片，分庫分表，每臺mysql放少量的數據,單個

數據分片內部采用mysql復制機制。

3)讀庫的超大memory容量，起到了很好的cache作用，在內存中的數據查詢

性能遠遠高于在硬盤上的性能

4)oracle到多臺mysql按規則復制

結合淘寶架構的思考，校訊通大流水也可以做到垂直分割到不同的服務器，也可

以做到水品分割到不同的服務器，通過不同的服務器訪問不同的流水表或者是不

同范圍數據的流水表，那提升性能是肯定的。不過也要平衡考慮到應用程序開發

的簡便性。

7.內存數據庫技術利用

常見的內存數據庫產品包括商業版和免費版兩類。商業版如：Altiba，

Timesten，Berkley DB等。他們在電信，金融，證券等高性能計算應用中運用

較為廣泛。商業版功能強大，然而，價格比較昂貴，不適合目前“廉價PC+免

費軟件”的架構搭建思 想。

開源領域產品主要有H2，HsqlDB，Derby，BerkeleyDB 等。在混合集群架構

中，內存數據庫將承擔OLTP的職責，因此除了讀寫性能外，功能的完備，事務

等都需要作為優先評估的因素。

盛傳H2是一個開源的高性能內存數據庫，可以通過整合 Ameoba 與 H2，夾

在applications和傳統db層之間來達到內存數據庫層的架構部署。

Ameoba 是分布式數據庫代理，它與 MySQL 整合已經在阿里巴巴核心業務中

成功運用。如果僅將數據庫節點看作一個存儲，MySQL Node 和 H2 Node 并

無本質區別。JDBC驅動，DB切分，路由，皆由Ameoba 統一負責。

8.非關系型數據庫的使用

外圍的非核心數據，但是數據量又是比較大的的業務系統數據庫可以采用非

關系型數據庫，這是由非關系型數據庫的一些基本特性決定的。

非關系型數據庫有滿足如下需求的優點特性：

1)High performance - 對數據庫高并發讀寫的需求

2)Huge Storage - 對海量數據的高效率存儲和訪問的需求

3)High Scalability && High Availability- 對數據庫的高可擴展性和高可用性

的需求

但同時伴隨不能滿足以下需求的缺點：

1)數據庫事務一致性需求

2)數據庫的寫實時性和讀實時性需求

3)對復雜的SQL查詢，特別是多表關聯查詢的需求

正 是由于以上的優缺點也決定了，核心的需要保持一致性的數據，需要復雜關

聯的數據，需要實時訪問的數據不要采用關系型數據庫，如果通過ETL把關系

型數據庫 的流水數據冗余基本信息，組成可以直接查詢的業務信息數據，導入

到非關系型數據庫后，那對海量流水數據的查詢速度提升空間是很大的。其中代

表型的非關系型 數據有Redis，Tokyo Cabinet，Cassandra，Voldemort，

MongoDB，Dynomite，HBa，CouchDB，Hypertable， Riak，Tin， Flare，

Lightcloud， KiokuDB，Scalaris， Kai，ThruDB等等非常之多。

四．架構計劃

通過以上當前架構劣勢以及改進思路的總結，改善的架構計劃就比較清晰了，

以下還是通過橫向的整體數據庫架構，縱向的整體數據庫架構，以及數據模型的

架構改進來做為新的架構計劃。

風險最小，改動工作量最小的架構就是改進思路中以第4點和第5點之間為分

割線。這條分割線前的數據架構基本不需要變動，主要變動的就是數據模型架構

中的流水表對象，以及數據庫服務器后臺添加監控以及智能處理的運維程序工具。

主要改進的數據模型流水表對象如下圖：

同樣進行分區的還有其他的一些大流水表，這里不一一詳述，這些流水表從

syba進入oracle的分區表，在數據庫轉型升級過程中完成。

還有一點就是關于數據庫監控工具在架構中的部署，如下圖所示：

以上架構改進計劃可以在一期中先完成。看運行效果狀態，第5點之后的改進計

劃幾乎就是架構的重構了，所以涉及的工作量更大，如果在第1，2，3，4點改

進后數據庫運行穩定，后續的改進，可以通過實驗和應用結合逐步實施起來，作

為應付更大型的業務應用技術儲備。

下面結合5，6，7，8點的改進思路做個架構規劃，也就是分布式的內存與

傳統數據庫結合的混合集群架構模式，再加上外圍產品的非關系型數據庫，如下

圖所示（服務器和db合為同個節點說明，否則圖片篇幅占用過大）：

上面的架構圖中，application（應用服務層），data cache層，disk db layer

層已經實現，但是disk db Layer層的多數據庫集群技術還沒不能說正式實現，

雖然分庫技術有類似集群嫌疑，async write（異步寫）聽開發人員也已經涉及

使用。那么此新架構圖針對原架構的改進就是Memory DB Layer層以及類似

Ameoba （可以使用其他的代理）分布式數據庫代理還沒實現。Memory DB

Layer集群加上每個邏輯分區有兩個內存庫是為了其中一個內存數據庫一旦崩

潰，同一邏輯分區中的替補節點立即頂替工作，做到健壯的容錯和 Failover機

制。這個架構明顯比校訊通當前在使用的架構要復雜很多，穩定性以及性能的提

升都有待實際驗證，雖然單單從架構上來講融合了目前很多的技 術優點（集群，

內存數據庫等）。