技术架构问题
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都可以
------解决方案--------------------
学习
[解决办法]
前台用struts或Spring MVC, 后台直接使用JDBC，不要使用hibernate(数据量过百万就成为瓶颈了)。
使用resin发布，不要使用tomcat。
数据库使用oracle或DB2都行。记住要请数据库专家设计整个数据库架构(这才是项目的关键所在)。
选择Unix服务器，不要使用windows的。
[解决办法]
服务器方面可以搞双机或集群
[解决办法]
继续补充一下: 这里涉及一个总的原则, 是靠自己还是靠产品. 这完全是两个不同的道路, 深刻地决定了你搞出来的东西是什么样. 前者靠的是硬桥硬马, 一切尽在掌握当中, 凭得是一块板砖盖大厦的底气, 但容易陷于事事追求本公司实现一切的牛角尖, 可能会越走越吃力. 后者则前期会体现出一定的快速建设的优势, 但这种优势是被架空的, 是一种头重脚轻根底浅的思维. 后面越走越妖, 机器里面全是第三方, 惟独自己成不了第三方. 所以, 你要搞大茶饭, 要抱有中庸的态度, 核心技术绝不能放在敌人的手里, 皮毛杂碎则先来个快速建模.
大系统, 里面水深着呢, 就凭这每天5G的数据, 压缩就成了大事, 每天应付的企业那么多, 加密又是另外一个重要的问题, 深究下去没完了, 这些都是核心技术.
[解决办法]
这样的问题你应该去DBA那边问。
按着你的描述，一个月大约就是6kw的记录，即使放在一个表里面，你的综合查询应该也能支持两个月的查询，如果分表，一年应该可以支撑。当然，sql语句不能太烂，不能用mysql这样级别的数据库。
这个数据库的性能关键点主要在查询这块，所以选择一个好的存储方案，减少i/o方面的问题是关键，运算量并不大。理论上pc server应该可以支撑，实际上面向1000多个每天1000条记录的企业，你好意思不用小机？ ：)
应用程序上，就是一个查询系统，真没有什么架构可言。
建议去itpub或者chinaunix问问吧，那里存储方面的专家多一些，csdn一些还在玩hibernate的人只会误导你的。
[解决办法]
与整体的技术机构没有太大关系吧,应该属于调研那边的工作吧,这个;
选好服务器,选择好内网传输还是外网传输,考虑传播范围,再有就是使用硬件的选择,如果内网的话选用VPN传输,效率会比外网要好一些;
数据库当然是DB2或oracle;
还有这个表面看着是数据传输,其实多系统的交互,有没有考虑过做系统的中间件平台,然后与那些企业的erp固定格式的接口传输与校验;
还有是打算做同步传输还是异步传输,大数据量的偏差计算有做好固定的预算没,再有数据安全有没有做过具体的方案,服务器选型有没有考虑配置参数的优化;
要考虑的东西多了去,让调研的部门把数据统计好;
如果是你说每个公司都有1白W的数据量.然后又2000家公司进行每天传输数据,丫丫的这个不用集群,等于说废话呢,上亿万的数据硬件做好向上升级的准备;
再有,除了你的那一方处理,那些公司也要做优化;
首先要建2000企业那边加上数据平台,将数据格式统一化,变成统一的格式;
然后,你这边也要建立一个数据平台将统一化的数据平台进行解析;
最后建立一个两个中间转交换平台对数据的安全情以及数据检验,续点再传等等,当然,这是逻辑上一层,当作中间件就OK了;
上面是传输的解决方法,有N多产品可以解决;
数据库的优化存储,这玩意找DBA讨论,他会给出你解决几个方案,然后选一个适合的在做适当的优化;
选用开发模式,和IDE工具等等,这就要看用户的要求了,看他们用什么应用服务器,IBM就用WPSHERE的专属IDE,sap的话也有自己的IDE;
如果是多系统之间的交互,那就是多层组件化的设计了,总体分为几层架构,具体架构系统模块分为几层架构,在加上项目管理系统一些控制,大的系统可以分到20层,
这要看具体的需求;
具体技术架构看系统要求了,和综合需求决定,至于说SSH的...拜托...那在系统项目中说他是局部的技术架构都给它面子了.......
[解决办法]
消息中间件,的话,貌似以前似乎看过其他项目的需求用的是东方通的什么消息中间件,这样产品话说国内国外的都不少;
顺便补充数据库那边,如果访问频繁的话,就用模拟DNS服务器的思想,高速缓存嘛,人家DNS的服务器一天上亿次和
数据库交流呢,应该有这类缓存产品;
再有就是用分布式缓存memcached,如果数据不是特别快与数据库同步的话,你是异步消息嘛,应该数据同步要求没那么大,那么就自己写hashMap的缓存,用hashMap模拟表,然后几秒钟让hashMap和数据库进行一次更新;
hashMap+memcached,几乎可以完美KO,如果懒得写,还有一些中间件缓存,jboos-缓存等等一系列产品,哈哈
俺也是抛砖引玉,大家互相探讨嘛,架构这东西,都是探讨出来,也没有自己闭门造车能造出来的;
再说思想这个东西,不讨论不创新,藏着藏着就过时了
[解决办法]
再有就是用oracle的缓存,它本身的做得相当好,还有内存数据库等等,优化起来,命中率可以在90%以上吧,厄,这是保守估计,不过缺点也很多用起来不太方便,特别是如果业务比较复杂,和其他系统交互的,使用软件和人力资源要加很大的成本.哈;
不过oracle11G有新的功能缓存结果集,具体不是很了解,不过应该可以优化这方面的问题,楼下继续
