技术架构问题
1、面向2000多家企业上报信息的数据库，每家企业估计每天的数据量在(1000条记录*1k)左右，也可能会更多（每个表的字段约 <20）；每家企业的数据基数平均大约是：(2500条*1k)；这些信息添加到数据库的模式有多种，有被动（客户端上报）和主动（服务器端抓取客户端数据）两种方式，在主动方式下，数据是同时抓取的，被动方式下，由客户自己上传；传送频度为每天一次。
2、数据分布在不同种类的表中，也可以归并在同一表中，视具体情况设计而定（具体情况就是根据现有的数据增长量、用户数、传输效率、查询效率等综合考量）；
3、数据库操作，主要是数据传输（从不同地区得到数据），和对整个数据的综合查询和统计。
4、数据库大概会对3-5年内的历史数据进行备份和导出，以作为历史记录保存，那么用什么样的策略进行备份导出比较合理，无须做数据仓库。
5、系统整体的业务逻辑不算复杂，问题集中在技术方案选型、系统性能、数据传输效率、准确性。
=========================================================================

就以上的问题，我想请问：
1、根据上面说的，大致给个总体技术方案，比如采用什么系统，什么技术框架，服务器，中间件等等；
2、根据上面粗略估算的数据量和大致一个业务要求（上面的业务要求大概是25%），数据库准备用oracle，技术平台想用J2EE。如果定了这两个技术平台，那么开发框架和工具用什么比较好？请推荐1-2个方案，最好能给个理由；
3、数据库是否要做分布式，是否集群（2000家企业分布在4-5个地区）；
4、最后就是一些没有考虑到的问题，请提示！

谢谢~~！

------解决方案--------------------
这，，，
------解决方案--------------------
...
------解决方案--------------------
linux, jdbc, mysql
------解决方案--------------------
hao ddddddddddddddddddddd
------解决方案--------------------
经验一年的飘过，暂时解决不了，帮顶。。。。。。。。。。。。。。。。。。。。。。。。。。。。
------解决方案--------------------
oracle J2EE
ECLIPSE
STRUTS
------解决方案--------------------
建议框架用 SSH(struts spring hibernate)
工具用 myeclipse
理由：SSH框架是一个比较成熟的框架
用myeclipse工具可以直接整合框架

------解决方案--------------------
首先s2sh是可以满足你的要求，原因在于减少开发成本，也可以容易采用合适的缓存策略 
其二数据库暂可以不做分布式，等数据量接近千万级，再考虑分布式
其三，集群就完全不必要了吧，除非你的负载最主要是你的页面流量超过了千万级（主要看请求是否是动态的）
我曾经做完静态化后，一台服务器抗过了一千万流量，看具体需求，动态请求过多，则还是做集群吧，大概一台机子扛个
五六百万是没问题的

------解决方案--------------------
1000记录×1K是什么意思？是每条记录有1K大小，还是有1000×1000条记录呀？

还有
每家企业估计每天的数据量在(1000条记录*1k)左右，每家企业的数据基数平均大约是：(2500条*1k)；这两个数据是怎么来的以哪一个为准呀？
------解决方案--------------------
.
------解决方案--------------------
还么有经验 帮顶

------解决方案--------------------
这样的问题，只能学习学习了…………
------解决方案--------------------
1, 网络流量, 一个企业1000x1k或者2500x1k, 算你最大值,2.5m bytes/日, 共2000家, 则每天上传5G,问题在于这5G数据的突发性有多大, 最大时候是多少字节/秒? 按照普通电信级的主机托管线路, 可达1-5m 字节/s的速度, 你自己考虑一下够不够用.
2, 数据库写入的速度, 上面那5G最后要写入数据库, 你买什么牌子的数据库, 就最好做个小测试, 看看单纯的写入速度有多快, 自己心里有数, 不过这部分应该没啥问题.
3, 服务器处理的速度, 你上面5G以什么形式拿来有很大的区别, 如果一次拿一个大数据包,仅仅左手交右手, 放进数据库了事,只要用自定义的序列化方法,那么这也没啥难度, 快如闪点. 如果来的是什么Excel数据, 你得一字排开十来台服务器, 晃悠晃悠地慢慢来吧. 一台接受服务器拿了数据以后, 再交给那十来台民工机慢慢熬.
4, 你那些数据从企业来的时候是否一点一点挤牙膏似得过来, 来一点就写一点进数据库? 而且写了又读, 读了又写反反复复? 这是最麻烦的, 考验你的时候到了, 这时候靠的就是自己的功底,什么架构都帮不了你, 得慢慢设计牛B的数据结构和算法. 读, 我们很容易搞牛B的散列缓冲, 而写你也要下点功夫, 还是要避开直接写穿数据库, 最好仿效写回的办法, 只要你的服务器够稳定, 这大大减轻你数据库的负担.
5, 最好别搞分地区的分布式计算, 要建立自己的数据中心, 在一个机房里面搞分布式怎么都不为过, 一旦不同地区的分布式计算, 低速低质的线路会造成很大的困扰.用什么开发平台,什么数据库,什么操作系统都没关系,这都是边角料.
你单位想必是牛B单位, 但越牛B的单位这种东西干得越烂, 前两年中国海关搞的核销系统, 烂得半天进不去, 还经常死,前车之鉴.别把大好的项目砸在自己手里.
------解决方案--------------------
mark
------解决方案--------------------
Study
------解决方案--------------------
开发工具用myeclipse,发布用tomcat或者收费发布器。框架用ssh或ssh2都可以
------解决方案--------------------