2005-2013: Java
1)2005-2007: Struts1.1+Ibatis 1.3
2)2008-2010: Spring mvc+Spring ioc+ibatis
3)2011-2013: 按业务进行组件化拆分,RPC调用。原因：业务线(包括公司自有业务和第三方集成业务)加速膨胀，有大量公用功能，原架构重用性低，导致开发部署效率不高。
架构图：
现状简述：
多版本同时并存(php,java): 部分客户不愿意升级，认为已经够用
组件化改造工作还在进行中，并非所有业务线都进行了改造；相对来说，新业务线采用最新架构的主动性最高，因为没有历史包袱。
RPC每日调用大概在千万级别：折合每秒100多次调用，比起互联网应用差的比较远
目前DB数据量：
中小客户公用site：每年大概新增3000万，DB只存储3年内数据。每天大概新增10万Meeting。
前10大客户site：DB独立，总共每年大概新增1000万Meeting，每天新开会议2万个左右。
平均每个会议有10人左右加入，因此Attendee表每年新增大约1亿条记录
但是分摊下来，一平均大概每个Site100万meeting每年，每天大约2000多会议，attendee表平均新增1000万记录
部分数据总量可达meeting数量的百倍（如会前会后调查）
如何拆分这些非关键数据？
历史数据分析：
这部分数据如何分析，以产生商业价值？？