有关多用户多并发巨大数据量的硬件和数据库架构的问题

显示全部楼层 · 2005-4-27 08:46:18

业务模式：
全国有二、三十家子公司，北京为公司总部，也是数据中心。
每家子公司通过internet连到北京总公司的数据库上进行业务操作。
每家子公司每天的业务票据量大概在3000条左右。
在硬件以及数据库的架构上应该如何进行才能支持这种要求呢？
我想，是否这样可行：
1、对几大主业务表采用分区的方式，每家子公司一个分区。
2、每个分区放在单独的磁盘组上。
3、采用RAC的方式进行负载均衡。
但我了解下来，似乎RAC在不同的instance之间进行数据同步也比较消耗性能。不知是否如此？
4、查询所对应的数据库与业务所对应的数据库分离。
5、硬件系统上采用RAID0+1。
暂时想到这些，不知道还应该注意些什么。
偶想不通的是那些交易网站，比如易趣、淘宝们，是怎们实现类似需求的。
恳请各位高手给个意见。

千问 · 2005-4-27 08:46:18

30*3000，数据量不大嘛！

千问 · 2005-4-27 08:46:18

问些问题:
web应用把?有没有长事务型的操作?业务逻辑在中间层实现的把?
并发连接有多少?大表的数据量估计有多大?
一个月新增数据量30*3000,不算大了.

千问 · 2005-4-27 08:46:18

要考虑3～5年的数据量

千问 · 2005-4-27 08:46:18

每月必须的业务数据为：3000×30(子公司数量)×30(一个月30天)＝2100000条记录。
通过这些业务数据需要生成财务应收、应付、商品帐等数据，同时生成一些财务业务的报表数据，同时还会生成其他一些功能的数据。
这样就把数据量提上去了。

千问 · 2005-4-27 08:46:18

最初由 husthxd 发布
[B]问些问题:
web应用把?有没有长事务型的操作?业务逻辑在中间层实现的把?
并发连接有多少?大表的数据量估计有多大?
一个月新增数据量30*3000,不算大了. [/B]
web没有长事务的操作。
业务逻辑在中间层。
如果把部分得业务逻辑在数据库端用存储过程以及触发器完成，应该也没有什么问题吧？
并发连接暂时没有测量。
每个分区每个月新增近10万条数据，要是一年得有近3600万得数据了，两三年下来不得有近1亿条数据了。还真没想过如何在1亿条数据里进行查询。
如果这个表还要进行update得话，也是非常麻烦得。
在假设应用系统设计得是合理得前提下，这时，从数据库上考虑应该注意些什么？

千问 · 2005-4-27 08:46:18

这些数据量不是很大，Oracle层次不需要做太多工夫。
如果说架购的话，应用程序级别重视就够了。

千问 · 2005-4-27 08:46:18

最初由 licy 发布
[B]这些数据量不是很大，Oracle层次不需要做太多工夫。
如果说架购的话，应用程序级别重视就够了。 [/B]
就是。不要写太烂的SQL。
楼主的应用，一台PC级服务器就搞定。

千问 · 2005-4-27 08:46:18

最初由 hanson 发布
[B]
web没有长事务的操作。
业务逻辑在中间层。
并发连接暂时没有测量。
每个分区每个月新增近10万条数据，要是一年得有近3600万得数据了，两三年下来不得有近1亿条数据了。还真没想过如何在1亿条数据里进行查询。
如果这个表还要进行update得话，也是非常麻烦得。
在假设应用系统设计得是合理得前提下，这时，从数据库上考虑应该注意些什么？ [/B]
这边的帐目表按月分区,每月增长100W,目前的数据量为2.6-2.7亿.
只要设计的好,前台操作不会有明显的延迟.
调优主要还是应用的sql调整.其他没有特别需要关注的地方.
当然,硬件不能太差

千问 · 2005-4-27 08:46:18

看了很多朋友都说这个数据量不大，确实是我没接触过海量数据得应用得关系。
还是很好奇象电信、银行这些海量数据应用，是如何实现oracle方面得架构得？
有没有高手可以介绍一下得？