文档介绍：数据架构规划

结合研发二部数据量最大的校讯通产品来描述，其他的产品在性能上出现瓶颈，可以向校讯通靠拢。
数据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度，横向采用了历史库+当前库的分库架构或者单用集群技术
当前的数据库架构还没采用成熟的集群技术，集群技术并不单单指单一数据库系统的集群，可以混合集群，比如内存数据库跟传统永久磁盘化数据库系统集群。
分库架构还可完善
当前的分库架构还可以继续完善，引用成熟的数据库主从分离，读写分离技术。
内存数据库技术还没充分利用
当前的数据库架构虽然在前端使用了memcache技术，但是还可以继续完善使用内存数据库技术再结合异步写技术，使得架构相得益彰。
适合海量数据高并发读写，高效率存储的非关系型数据库没充分利用
当前的数据库架构还没采用正在兴起的NoSql,NewSql技术（目前部分外围系统采用了mongodb来做试验品，而这部分系统的数据量并不大，非关系型数据库海量数据高并发访问的高效性优势没有体现出来，从而也没掌握真正的使用经验），当然这种数据库也有缺点，就是数据库事务一致性，数据库的写实时性和读实时性，复杂的SQL查询，特别是多表关联查询是无法满足的。

在第二部分的劣势现象中，总结了当前数据库架构以及数据模型架构的缺陷，缺陷还比较多，从另外一个角度也反映了公司产品数据库架构改进和提升的空间还比较大，将来随着不断的迭代改进，可以承受的业务量提升的空间也相应的比较大。
下面就根据劣势现象进行针对性的阐述改进思路：
流水表性能瓶颈改进
，但是通过数据库转到Oracle后，充分利用Oracle分区表，分区索引的特性来提升流水表的访问性能，逻辑上表仍然是一张完整的表，只是将表中的数据在物理上存放到多个表空间（物理文件上，这样查询数据时，不至丁每次都扫描整张表。由丁逻辑上仍旧一表，使得应用程序不需要修改，也避免了这个劣势点描述的带来额外许多开发
工作量的问题，但是效果几乎等同水平分割数据模型。
大流水表运维难的改进
1）历史数据活理运维工作
在Oracel数库系统中，针对对大流水表每个月的数据进行分区，这样运维人员在活理历史月份的数据时候，只要通过TRUNCATEPARTITION、DROPPARTITION的Oracle本身的分区维护命令轻松快速活理掉分区的数据（既指定月份的流水数据）
2）防止索引失效而进行的统计量更新运维工作
同样Oracle也有等同丁sybase的统计量更新工作，在Oracle中通过对大流水表的分区工作后，进行统计量的更新工作同样就快捷简易，可以通过ANALYZEPARTITION的统计量分析维护命令可以轻松快速对指定分区的统计量进行更新。
运维监控纸漏的改进
主要分两个方面：a）数据库剩余空间方面的监控；b）数据库出错日志的监控。
这两个监控虽然通过人为主动性的查看数据库相关信息可以监控到，但是总归还是会有疏忽遗漏的时候，只是出问题几率高低之分。所以这里再加一道监控，就是通过数据库服务器端的监控程序主动发回有问题或者告警的信息给运维人员。这道监控程序可以通过shell程序以及数据库程序，结合数据库日志以及剩余空间信息以短信或者邮件的方式发回给运维人员。在数据库剩余空间方面甚至可以通过数据库本身阀值的设置，做到自动截取日志，自动添加设备。
运营统计报表数据模型的改进
由丁原先一些报表模型存在着数据统计的重复性，在晚上定时task中既占用了任务列表的总时间，也对其他并行的task运行造成了一定的资源争用，影响了数据库性能。所以在这里提出了一种类似蒲公英性质的模型，数据通过发散模式，即插即用到不同的运营统计报表中，势必需要改进当前接近一事一地的3范式模型，把原先的数据模型拆散，从纵向和横向都接近最小粒度需求的数据模型。使得统计数据可以重复使用，不同的统计报表通过这些原子性的统计数据再组合成报表所需要的数据，当然这里需要一个平衡，并不完全等同蒲公英模型的统计粒度越细越好，因为越细也代表着原始的统计数据量越大，一会影响原始统计的性能，二会影响组合成报表的性能，三会占用更多的存储空间。这个平衡度需要掌控好。
利用集群技术
当然通过了前面4点的改进之后，数据库性能会比目前的架构提升一定的性能，至丁集群技术就可以作为前面4点改进后的补充和扩展，如果在改进后，依然还存在较大性能瓶颈情况下可以采用OracleRAC技术。甚至采用基丁内存数据库的分布式数据库架构的混合集群技术。比如在Oracle数据库及Web服务之间加一层Ameoba分布式数据库代理结合内存数据库的架构，分库架构完善改进
目前的数据库架构采用了分库方式，但是主库（