关于一个数据量极大的程序架构

高性能

songrj2903

09-04-15 4 623

最近公司接到一个移动的项目，这个项目其他的也没什么就是数据量会很大，目前保守估计数据量会超过上千万，现在架构还没定形，想采用市面上比较成熟的框架struts+hibernate +spring ,使用struts的原因是因为struts出来的时间久一些，在稳定性还维护性会高一些，采用hibernate的原因可以使用hibernate的缓存，spring进行类的管理的事务方面的配置，还想在项目中的使用数据库连接池（c3p0）和一些缓存的JBossCache，安全使用acegi,报表和画图使用JFreeChart JasperReports。
本人只是一个初学者，个人对技术的认识有些不全面，请banq大哥和JDon的朋友替我分析一下，谢谢

banq

2009-04-16 09:05

数据量极大关键是用树立内存对象编程模式，而不是围绕数据库，保证系统是一个可伸缩性的系统，将来就可以进行性能拓展。

具体框架不是很重要。

usejava

2009-04-20 13:18

在选择框架前，至少先优化下数据库。千万记录不算什么，好的数据库设计相对于差的可能有上百倍性能差距。

spikeme

2009-05-02 14:36

>>数据量极大关键是用树立内存对象编程模式，而不是围绕数据库，保证系统是一个可伸缩性的系统，将来就可以进行性能拓展。

具体框架不是很重要。

我看了banq的很多帖子，其实总结一句话，banq基本都是讲的一个思想，那就是DDD，更抽象的说，就是倡导面向对象的编程思想。
这是好事。

但我认为DDD和面向对象都不是万能的，不是所有问题通过它就能解决的。而且有很多问题都是不同层面的问题。比较架构问题，数据库问题，OO设计问题，其实都有侧重点。不能说我的架构设计问题，数据库设计问题，设计好内存对象就解决了。我认为不现实。每个人理解OO的程度不一样，自然设计水平就不一样。难道因为团队成员OO思想不够好就把人给开了。当前中国现状，我可以说就OO这一个方面，理论水平达不到Banq的程度的一把，但是这样就不能做系统了吗，照样做，而且还能做出高质量高性能的系统。因为一技术个问题可能通过很多驱动去解决的。所以你倡导的思想不是万能的。我认为，重理论，重设计思想是好事，但不能套进去了，忽略了实际情况，我觉得其实大家需要的确实能解决问题的策略。比如楼主的问题。

另外，我再重申，很多技术上的思想是相互融通的，可以相互补充，不是相互矛盾的。不要太夸大某一个技术方面的重要性。这样你可能看不到其他技术层面的优点。。

我其实并不是针对Banq的，我主要是看了Banq的很多帖子，突然不自觉产生了这样的一种感觉。不过我确实佩服Banq在设计上的理论水平。

spikeme

2009-05-02 14:47

>>数据量极大关键是用树立内存对象编程模式，而不是围绕数据库，保证系统是一个可伸缩性的系统，将来就可以进行性能拓展

这个设计思想我很赞成。根据我经验和别人的经验，一般海量数据的系统。在架构设计上一次设计OK的实在是太少了，基本上都没有。一般都是摸索中前进。一开始根据基本系统的要求设计好了后，然后再测试，找出性能瓶颈，然后寻找架构设计上的解决方案。然后慢慢优化，直到达到需求。

但是这中间就存在一个问题。因为设计上的变更往往导致编码修改，业务逻辑修改很大。最终连锁反应，导致项目成本极大增加。所以要想减少成本。就必须在设计程序的时候做好面向对象设计，面向接口编程。主要模块之间的耦合处理。就想banq所说的，树立内存对象编程模式。。关键是要保证系统是一个可伸缩性的系统，将来就可以进行性能拓展。。。