最近參與到某新能源制造企業去O上雲的項目，網站的需求很簡單：以WEB/APP 的形式提供資料查詢展示、分析的功能。
網站使用java編寫，資料庫采用Oracle DataGuard 搭建的高可用架構。DG環境是找第三方公司來搭建的，過了維保期之後主庫出了問題，客戶根據維保手冊自行将備庫提升為主庫，但DG環境卻搭不起來。找資料庫運維公司來搭建，要10WRMB（狠！），也就咬牙不搭建DG環境了。相當于資料庫一直處于果奔狀态。
資料庫主要存儲站點、裝置狀态、裝置運作日志、發電量、二氧化碳減排量等資料。資料表不多，但單表資料量特别大。WEB站點大都以圖表的形式展示日、月、年發電量、二氧化碳減排量、Input、Output資料。很遺憾，所有的統計資料都是在使用者通路頁面時實時計算得來的。

随着新能源産業的興起，公司銷售的裝置也越來越多，收集到的資料量也越來越大，單表最高達2億，多張表資料量相當可觀。同時也因為頁面響應越來越慢的原因，收到更多的使用者投訴。
而此時使用者已經感受到來自WEB架構、資料表擴充等的壓力，通過一番咨詢後，找到我們來優化架構，解決資料量越來越大，WEB通路越來越慢、便于開發維護的問題。
在對公司業務、WEB/APP的業務類型、資料量變化趨勢及客戶想要達到的資料入庫速度、頁面響應時間詳細了解之後，開始架構優化和資料庫改造計劃。
大家都知道Oracle相較于其他開源或者非開源的資料庫都有很大的優勢，表現在OLTP、OLAP等事務操作，以及對過程、觸發器、函數等的強烈支援。但在大資料表的處理及擴充方面的能力也一直被大家诟病。另外一面就是對非專業資料庫管理人員來說，維護起來有很大的挑戰，并且第三方的運維服務公司大都很貴！
出于易運維、可擴充的需求，推薦使用阿裡雲分庫分表中間價DRDS+RDS資料庫架構；并對目前實時資料統計的業務場景做了優化。
解決的問題：
DRDS單執行個體可以和N個RDS執行個體組成分庫分表叢集，每個RDS會建立8個資料庫，每個資料庫可以根據拆分規則建立M個分表，最終一張大表的資料會均勻（理論上）的分布在NM8個資料表上，單表資料量直線下降。
阿裡雲提供DRDS、RDS管理控制台，執行個體CPU、記憶體、慢日志等等都可以直覺的在頁面展示，快速定位解決問題，節省人工運維的成本。
針對實時計算的業務類型，做了大量的代碼層和資料庫層改造。基本思想是将該類型的業務放到背景，以定時任務的方式去計算，不同需求的結果存儲在不同的月、年統計表中，真正做到頁面與資料庫的互動隻有簡單的DML操作，減少響應時間提升客戶體驗。

多輪性能測試下來，在100并發下，單個頁面最快響應時間可達到500ms以下，多個頁面的性能測試響應時間也在2S以下。
去O改造的指導思想是：
梳理和拆分業務，将需要計算的事情交給背景JOB去做，頁面對資料庫的請求隻有一次互動、且隻是一次對表的查詢操作，避免多次互動和大量的計算操作，提升性能。