|
精华帖 (5) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-02-24
jizhan 写道 对于一个纯JAVA实现的项目，有如下一些需求，采取何种方案为好呢：
并发的、大数据量的持久化（最少15G/天）； 大量的报表统计（对上面收集的各种数据做统计，时间跨度月、周、天....不等）； 第一时间反应要敏捷； 关系数据库多变； 并发用户访问量不大； 这是一个产品型的项目； 对于以上这么一个需求，采取什么实现比较合理?这里的合理第一位为性能，然后才考虑可维护性、扩展性（首先、然后都很重要，不能太有偏向）。个人认为项目的可维护性和扩展性主要与程序的具体设计有关系，与采取什么样的持久化方案关系不大，这里要考虑的其实就一个性能问题。 呵呵，以前主要做行业软件，初次接触产品型的开发，也很少碰到这么大的数据量，感觉比较紧张，恭请各位赐教...... 单看这份需求就自相矛盾！ 并发的、大数据量的持久化（最少15G/天） vs 并发用户访问量不大 不知道这个15G/天的数据怎么来的？ 关系数据库多变 vs 这是一个产品型的项目 合起来就是多变的产品 ... |
| 返回顶楼 | |
|
发表时间：2009-02-24
stephen830 写道 jizhan 写道 对于一个纯JAVA实现的项目，有如下一些需求，采取何种方案为好呢：
并发的、大数据量的持久化（最少15G/天）； 大量的报表统计（对上面收集的各种数据做统计，时间跨度月、周、天....不等）； 第一时间反应要敏捷； 关系数据库多变； 并发用户访问量不大； 这是一个产品型的项目； 对于以上这么一个需求，采取什么实现比较合理?这里的合理第一位为性能，然后才考虑可维护性、扩展性（首先、然后都很重要，不能太有偏向）。个人认为项目的可维护性和扩展性主要与程序的具体设计有关系，与采取什么样的持久化方案关系不大，这里要考虑的其实就一个性能问题。 呵呵，以前主要做行业软件，初次接触产品型的开发，也很少碰到这么大的数据量，感觉比较紧张，恭请各位赐教...... 单看这份需求就自相矛盾！ 并发的、大数据量的持久化（最少15G/天） vs 并发用户访问量不大 不知道这个15G/天的数据怎么来的？ 关系数据库多变 vs 这是一个产品型的项目 合起来就是多变的产品 ... 貌似lz的问题不在报表上 |
| 返回顶楼 | |
|
发表时间：2009-02-24
最后修改：2009-02-24
stephen830 写道 jizhan 写道 对于一个纯JAVA实现的项目，有如下一些需求，采取何种方案为好呢：
并发的、大数据量的持久化（最少15G/天）； 大量的报表统计（对上面收集的各种数据做统计，时间跨度月、周、天....不等）； 第一时间反应要敏捷； 关系数据库多变； 并发用户访问量不大； 这是一个产品型的项目； 对于以上这么一个需求，采取什么实现比较合理?这里的合理第一位为性能，然后才考虑可维护性、扩展性（首先、然后都很重要，不能太有偏向）。个人认为项目的可维护性和扩展性主要与程序的具体设计有关系，与采取什么样的持久化方案关系不大，这里要考虑的其实就一个性能问题。 呵呵，以前主要做行业软件，初次接触产品型的开发，也很少碰到这么大的数据量，感觉比较紧张，恭请各位赐教...... 单看这份需求就自相矛盾！ 并发的、大数据量的持久化（最少15G/天） vs 并发用户访问量不大 不知道这个15G/天的数据怎么来的？ 关系数据库多变 vs 这是一个产品型的项目 合起来就是多变的产品 ... 挺有意思，还是我没说清楚： 项目定时并发的到不同地方去采集数据然后对数据进行处理。该产品是管理类型的东西，使用的用户群是有范围界定的； 用来存储数据的数据库不定，随着客户的需求可以支持目前主流的大部分数据库； 还有我前面犯了个错，项目要统计各种报表，对检索出的数据有一些处理，所以用存储过程应该有用处，只是一般的存储过程可能与具体的关系数据库有关，所以不太想使用这个东西（存储过程） |
| 返回顶楼 | |
|
发表时间：2009-02-24
挺有意思，还是我没说清楚： 项目定时并发的到不同地方去采集数据然后对数据进行处理。该产品是管理类型的东西，使用的用户群是有范围界定的； 用来存储数据的数据库不定，随着客户的需求可以支持目前主流的大部分数据库； 还有我前面犯了个错，项目要统计各种报表，对检索出的数据有一些处理，所以用存储过程应该有用处，只是一般的存储过程可能与具体的关系数据库有关，所以不太想使用这个东西（存储过程） 即使不用存储过程, 大数据量的报表输出, 为了性能, 都应该是尽量用对数据库友好的复杂 sql 语句完成, 很有可能会写成数据库相关的. |
| 返回顶楼 | |
|
发表时间：2009-02-24
项目定时并发的到不同地方去采集数据然后对数据进行处理
----这就是说,这是一个数据集成项目,很少或基本没有录入系统 该产品是管理类型的东西，使用的用户群是有范围界定的 ----似乎是指该系统主要为管理决策人员使用,很可能在过程中遇极其变态的用户需求 结论: 感觉象是比较典型的OLAP需求....用OLTP的思路,恐怕会遇到N多问题,效率上,伸缩性上,方案上... 随便拉拉^_^ |
| 返回顶楼 | |
|
发表时间：2009-02-24
不必太在意数据库绑定
这部分完全可以通过灵活的设计来避免过硬的绑死 |
| 返回顶楼 | |
|
发表时间：2009-02-24
BI啊！！
|
| 返回顶楼 | |
|
发表时间：2009-02-24
并发的、大数据量的持久化（最少15G/天）；
能说说都是些什么数据吗？每天能有15G，很是好奇 |
| 返回顶楼 | |
|
发表时间：2009-02-24
前端做数据库适配器，后端分段存储统计临时文件，文件格式自行优化，不要用数据库。
有点技术含量的地方就在这个临时文件上，其他都是体力活。 也就这种15G/天的小流量应用可以考虑用java了... 我们3路高速视频处理每秒就要处理100M，直接使用8G内存缓存.这样的需求，java就不用考虑了。你们这个需求,用java唯一好的一点就是数据库适配器能直接用jdbc... |
| 返回顶楼 | |
|
发表时间：2009-02-24
其实，这么大的数据量时，概率论已经可以充分发挥作用了，
你只需要做抽样的统计就可以了 比如只统计1/10甚至1/100的记录 每条记录有一个字段，在生成记录是是1-10000随机数，并在上面做索引 对这个字段用where ,就可以抽样统计了 然后把抽样统计结果放大相应的倍数 |
| 返回顶楼 | |
