最近参与到某新能源制造企业去O上云的项目，网站的需求很简单：以WEB/APP 的形式提供数据查询展示、分析的功能。
网站使用java编写，数据库采用Oracle DataGuard 搭建的高可用架构。DG环境是找第三方公司来搭建的，过了维保期之后主库出了问题，客户根据维保手册自行将备库提升为主库，但DG环境却搭不起来。找数据库运维公司来搭建，要10WRMB（狠！），也就咬牙不搭建DG环境了。相当于数据库一直处于果奔状态。
数据库主要存储站点、设备状态、设备运行日志、发电量、二氧化碳减排量等数据。数据表不多，但单表数据量特别大。WEB站点大都以图表的形式展示日、月、年发电量、二氧化碳减排量、Input、Output数据。很遗憾，所有的统计数据都是在用户访问页面时实时计算得来的。
随着新能源产业的兴起，公司销售的设备也越来越多，收集到的数据量也越来越大，单表最高达2亿，多张表数据量相当可观。同时也因为页面响应越来越慢的原因，收到更多的用户投诉。
而此时用户已经感受到来自WEB架构、数据表扩展等的压力，通过一番咨询后，找到我们来优化架构，解决数据量越来越大，WEB访问越来越慢、便于开发维护的问题。
在对公司业务、WEB/APP的业务类型、数据量变化趋势及客户想要达到的数据入库速度、页面响应时间详细了解之后，开始架构优化和数据库改造计划。
大家都知道Oracle相较于其他开源或者非开源的数据库都有很大的优势，表现在OLTP、OLAP等事务操作，以及对过程、触发器、函数等的强烈支持。但在大数据表的处理及扩展方面的能力也一直被大家诟病。另外一面就是对非专业数据库管理人员来说，维护起来有很大的挑战，并且第三方的运维服务公司大都很贵！
出于易运维、可扩展的需求，推荐使用阿里云分库分表中间价DRDS+RDS数据库架构；并对当前实时数据统计的业务场景做了优化。
DRDS：https://help.aliyun.com/document_detail/29659.html?spm=5176.doc52009.6.539.xf7Rpp
RDS：https://help.aliyun.com/knowledge_detail/41872.html
解决的问题：
DRDS单实例可以和N个RDS实例组成分库分表集群，每个RDS会创建8个数据库，每个数据库可以根据拆分规则创建M个分表，最终一张大表的数据会均匀（理论上）的分布在NM8个数据表上，单表数据量直线下降。
阿里云提供DRDS、RDS管理控制台，实例CPU、内存、慢日志等等都可以直观的在页面展示，快速定位解决问题，节省人工运维的成本。
针对实时计算的业务类型，做了大量的代码层和数据库层改造。基本思想是将该类型的业务放到后台，以定时任务的方式去计算，不同需求的结果存储在不同的月、年统计表中，真正做到页面与数据库的交互只有简单的DML操作，减少响应时间提升客户体验。

多轮性能测试下来，在100并发下，单个页面最快响应时间可达到500ms以下，多个页面的性能测试响应时间也在2S以下。
去O改造的指导思想是：
梳理和拆分业务，将需要计算的事情交给后台JOB去做，页面对数据库的请求只有一次交互、且只是一次对表的查询操作，避免多次交互和大量的计算操作，提升性能。
