前段時間把公司的主數據庫切了，分成業務庫和報表庫，業務庫向報表庫進行實時的Replication。這個項目的上線提升了系統的性能和可維護性，現在把設計時的考量和所做的工作重新回顧一下，作為備忘。

　　項目起源

　　在日常的開發過程中，功能總是先于性能被考慮。只有當用戶抱怨系統性能時，我們才開始頭痛醫頭，腳痛醫腳地來解決這些性能問題。

　　公司的CRM和ERP系統叫作Olite，完全是我們組開發的。從無到有，功能不斷擴展，原先只有CRM模塊，后來加入了ERP模塊，Accounting功能和Report功能。近來出現的情況是當某些用戶跑一個大Report時，正在進行業務操作的用戶感覺系統響應非常慢。通過對系統的性能監視發現，在這些時刻，數據庫中產生了大量的鎖，同時服務器上出現了CPU和內存資源消耗的尖峰。

　　系統結構

　　性能問題源于系統的整體結構和發展過程。Olite系統的Application是基于.NET平臺的Web Form程序，數據庫為SQL Server 2005。其主體結構如下圖所示：

　　其Application端包括兩個網站：OliteBase和OliteReport，但連接的都是同一個數據庫。

　　Olite的Application端其實很薄，而把大量的業務邏輯包裝在存儲過程中，放在數據庫端來運行。

　　這種結構在起初性能很好，而且提供給用戶的Report是實時的業務數據。但隨著提供的業務模塊，特別是Report的增多（Report對應的存儲過程連接的表多，計算量大，輸出的結果集大），數據庫就成為了瓶頸。

　　首先，我們做了存儲過程的優化，通過創建Trace捕獲性能差的存儲過程，并對其進行優化。我們這么做了一段時間，但獲得的收效并不大。我們在優化以往存儲過程的同時，隨著系統新功能的上線，又有新的存儲過程進入需要優化的列表中。

　　其次，修改數據庫設計，其中包括修改表結構和優化索引。在系統局部重構表結構與關系對于性能的提升還是比較明顯的，但這樣的修改會造成Application端的大量修改，工作量大，風險大，所以不能大規模實施。對于索引優化又存在矛盾，業務模塊（OliteBase）要求數據庫中的索引不要太多，以支持高效的插入、修改和刪除，而報表模塊（OliteReport）則希望在數據庫中有更多的索引，以支持高效讀。

　　最后，我們還試圖提供晚一天的Report服務，來分流主數據庫的壓力。每天通過把前一天的備份數據庫恢復在另一臺服務器上，并在此服務器上提供OliteReport2站點，給用戶提供Report服務。但用戶并不喜歡使用OliteReport2，原因分析下來有3個方面：其一，有時用戶確實需要實時的Report。其二，OliteReport能存儲用戶的Report條件，而OliteReport2由于每天都會被刷新，無法保留這些條件。其三，用戶更習慣打開原來的Report鏈接。

　　項目需求

　　上述的各種優化方案都沒有根本性的解決系統的性能問題。在這種的背景下我們有了把報表數據庫與業務數據庫分離的想法。

　　此項目的需求：

　　1. 提高用戶對整個系統性能的感受，Report模塊不要影響到業務模塊的運行。

　　2. 用戶可以和原先一樣使用Report模塊，即不增加新的Report站點。

　　3. 用戶可以和原先一樣存儲填寫的Report條件，以供重復使用。

　　4. 盡可能提供最小延時的Report。

　　需求1是這個項目的主要目標，需求2、3、4是盡可能保證項目所帶來的改變對用戶是透明的。