|
精华帖 (5) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-03-02
楼主，还招人么，我对这个很感兴趣的，也有些经验
|
| 返回顶楼 | |
|
发表时间：2009-03-02
igogo007 写道 数据库里面装的是沙子吗？
一天能装15G？ 这硬盘需要准备多少T的啊？ 我们做东西一般会备份3个月的数据.1500G,再算点冗余,有3T足够了..也没多少.... 当然还要看报表数据和中间数据有多少了.. |
| 返回顶楼 | |
|
发表时间：2009-03-02
感觉这是在做数据仓库，有多种数据源，要将数据源统一到一个数据库中，然后出报表，如果有钱可以去买一个工具，IBM的DataStage就挺不错
|
| 返回顶楼 | |
|
发表时间：2009-03-02
个人感觉 减少数据库的连接，加大内存的利用率。
如果是性能和效率上来说 主要在数据库上，服务器承担的压力不是很大（除非是大量的并发计算） 如果非常做到性能和效率明显提升，单独一个服务器好了。 |
| 返回顶楼 | |
|
发表时间：2009-03-02
jizhan 写道 nihaozhe 写道 菜鸟发表一下自己的意见。说错不要见怪。。
明确一下，并发用户访问是B/S吗，一般报表的查询都是用浏览器比较便利吧。 如果是通过浏览器那么J2EE这部分可以单纯的通过数据库显示报表。 所谓第一时间敏捷就是查询最新的实时的数据吧。那么就后台的统计可以分为两个部分统计，一个是实时的统计，一个是历史的维护。实时统计的程序用来统计收集来的数据，或读写磁盘文件或建临时表，15G对于数据库来说不是很大。历史的统计的程序可以跑线程定时服务器压力小的时候来完成。 别谦虚。 我没说清楚，这里的敏捷性是指反应要快，就是速度，不是实时的数据处理，对于数据的采集是定时循环的。对于统计不打算采取实时的，由于一次的数据量不小，如果实时统计的话会给系统太大的压力，打算采用定时任务调度的方式进行统计。 项目支持多数据库，如果存储过程没有绝对的优势，是不打算采用的（这里考虑要支持各种主流的关系数据库，而存储过程一般在具体数据库有一定的区别，所以不怎么想用，主要是怕麻烦  ）。反映快而不需要实时数据可以考虑使用cache机制,建立不同的region并在特定的时间更新 如果不需要使用浏览器可以考虑使用swing,CS可以降低大数据的显示的操作 |
| 返回顶楼 | |
|
发表时间：2009-03-10
数据存储在不同的表中，分日表和月表。接收数据的时候，可以先按照一定的时间粒度（比如15分钟）对数据累加一次，放入日表中。在一定的时候，将日表数据按天进行累加，存入月表。
|
| 返回顶楼 | |
|
发表时间：2009-03-10
这有点像数分的项目，需要有etl,dw,dm等结构。。。
|
| 返回顶楼 | |
|
发表时间：2009-03-12
sdh5724 写道 存储过程从任何角度都是不利的。
我们说， 业务绑在数据库上， 非常不利于开发。 特别是变化比较大的应用。 大规模的数据尽量避免join等复发操作。 另外分阶段， 利用晚上空闲时间统计阶段性数据。 避免一次长时间跨度的计算。 正解~~ |
| 返回顶楼 | |
|
发表时间：2009-03-12
其实LZ的问题既不在java也不在何种持久，如果楼主确定数据库本身对数据量支持没有问题，难免关键就在查询速度上。
分析报表需求，构造最优化的数据结构，分阶段和分布处理查询，使用内存数据库或者共享文件系统缓存中间结果。 |
| 返回顶楼 | |
|
发表时间：2009-03-12
海量数据关键是性能，所以跟java没什么关系。
我建议本着数据仓库的思想去做。 先用etl做数据整理。然后就没有性能问题了。 |
| 返回顶楼 | |
