请问大家一个关于海量数据库的存储问题

已查看 48 次
跳至第一个未读帖子

ball...@yahoo.com.cn

未读,
2006年5月18日 02:15:552006/5/18
收件人 高性能网络编程邮件列表
现在有这么一个项目,数据量非常之多,每秒钟上来的数据有上千条,而且每条数据都需要保存到数据库中,数据库用于存放这种数据的表一个月数据上十亿条,数据库采用SqlServer。
我现在采用的架构采用数据库群的方式,每个客户的数据单独存在一台数据库服务器上,所有的客户根据一定的规则安排存放的数据库服务器,在主数据库服务器上有一张索引表保存客户与数据库服务器的对应关系,每台数据库服务器中用于存放这些数据的表按照月份分成12张,每张存放当月的全部客户的数据,目前计算出单台服务器单表需要容纳9亿条数据,并且每台服务器在这种方式下可以容纳10000个客户的数据,以后客户数量增加时只需要增加数据库服务器即可。
请问大家这样的结构合理么?谢谢!

zhang yin

未读,
2006年5月18日 02:58:192006/5/18
收件人 dev4s...@googlegroups.com
我是不敢说合不合理,因为有这么多的高手会看到这个问题,我只说一下我听说的方案:
 
 
(1)你的主数据库作为所有访问的入口,他的压力如何被负载均衡?
(2)SqlServer提供了联合数据库服务器的功能,通过设置分布视图对数据表进行联合以达到负载均衡的目的,而在接入点上,使用DNS服务器集群进行大并发的负载分摊。
不知说的对不对。

 

MStar

未读,
2006年5月18日 02:59:122006/5/18
收件人 高性能网络编程邮件列表
一条数据有多大?十几字节? 还是几K?
另外恐怕sqlserver难以承担重任啊。

phus

未读,
2006年5月18日 03:09:162006/5/18
收件人 高性能网络编程邮件列表

无线业务吧? 只能用oracle了.

SevenCat

未读,
2006年5月18日 03:14:542006/5/18
收件人 高性能网络编程邮件列表
我觉得比较合理啊。看不出什么问题。

simon

未读,
2006年5月18日 03:24:462006/5/18
收件人 dev4s...@googlegroups.com
好像有些数据库商业数据库自己有更高级的集群方案,具体那个我不知道。

在Java编程中有个c-jdbc,他可以把後端的数据库做的和RAID差不多,通过配置可以所
有后台数据库都有所有的表,或者根据你的配置不同的数据库拥有不同的表。当然所
有请求也会在在一个集中的前端进行处理,应该同样有瓶颈效应的,但具体的性能就
要看实现的能力了。

我想这个应该是模拟某些高端数据库集群的类似的功能吧。

还有就是规则的那个数据库感可以不用Sqlserver,实际上我门应该根据具体需要选用
数据库,甚至不用数据库,第一那个用户规则配置应该不大,所以也可以做成配置一
次Load到内存中。或者可以使用BerkeleyDB这样的使用键值--》数据的非关系数据
库,应该可以加速你的查询,它还可以配置内存缓存数据大小,缓存经常访问的数
据,在访问速度和数据量方面有个好的平衡。

对于海量数据和高并发的到最后检验架构的还是在实际的应用中。当然如果现在你们
就能很接近的模拟真实情况也是非常有帮助的。

在 Thu, 18 May 2006 14:59:12 +0800,MStar <msn...@gmail.com> 写道:

> 一条数据有多大?十几字节? 还是几K?
> 另外恐怕sqlserver难以承担重任啊。
>
> >


SevenCat

未读,
2006年5月18日 03:29:462006/5/18
收件人 高性能网络编程邮件列表
楼主的分表和分数据库是最常用的办法了。数据库自身的集群从来没用过,而且觉得在很多情况下不如这种做法清爽。

simon

未读,
2006年5月18日 03:49:152006/5/18
收件人 dev4s...@googlegroups.com

这样做倒是没有问题,就是自己的程序要直接处理这些逻辑,而如果能利用数据库的
高级集群功能(如果有的话),那么对你的程序来讲是通明的。

在 Thu, 18 May 2006 15:29:46 +0800,SevenCat <BastE...@gmail.com> 写道:

> 楼主的分表和分数据库是最常用的办法了。数据库自身的集群从来没用过,而且觉
> 得在很多情况下不如这种做法清爽。
>
> >


ball...@yahoo.com.cn

未读,
2006年5月18日 05:00:392006/5/18
收件人 高性能网络编程邮件列表
非常感谢各位的意见

程序逻辑,我采用业务逻辑层的概念,对外提供应用服务器接口,全部的客户端通过应用服务器接口进行业务运算,应用服务器我也采用服务器群的概念,有一个主的应用服务器,有几个副应用服务器,全部客户端只知道该主应用服务器的地址,上线时登陆主应用服务器,然后主应用服务器根据各台应用服务器的负载情况返回给客户端真正的登陆地址(副应用服务器的地址),然后客户端再登陆到上面进行业务处理,每台应用服务器都能够访问各台数据服务器进行数据提取。

请问在这种架构合理么,需要每台应用服务器都配备一个公网ip么,还是有其他的方式可以只需要一个公网ip可以给全部的服务器公用?Nat能够实现么?

或者能否进行更好的负载均衡,就是客户端的各种业务都可以在不同的服务器上运算?谢谢各位的帮忙!!

已删除帖子

ball...@yahoo.com.cn

未读,
2006年5月18日 05:03:122006/5/18
收件人 高性能网络编程邮件列表
这个我也比较担心,一条数据几十字节
已删除帖子

ball...@yahoo.com.cn

未读,
2006年5月18日 05:05:052006/5/18
收件人 高性能网络编程邮件列表
类似的,Oracle好贵啊!!呵呵,能用我也想用!

ball...@yahoo.com.cn

未读,
2006年5月18日 05:11:172006/5/18
收件人 高性能网络编程邮件列表
to zhang yin

主数据库不是所有访问的入口,要想获得具体客户的资料只能到相应的数据库中获取,我想他的压力跟其他非主数据库的压力应该查不多。
你的第二点意见,有没有相关的资料可以给我参考一下?
谢谢!

小土豆

未读,
2006年5月18日 11:01:402006/5/18
收件人 高性能网络编程邮件列表
如此大数据量的项目竟不用Oracle,实在让人费解。我现在的月数据量大概2。5亿,用了3台HP
SUPERDEMO,9个CUSTERMOR
DB。其中一个CATALOG数据库,相当于你的客户索引。

你的插入操作很多,所以建议你少建几个索引,其实一些业务完全可以在数据库中完成,通过触发器,约束和存储过程,这样性能会有大的提高。大数据的表,分区的确是必须的,当然,还需要更完善的维护计划,否则很容易,你的业务可能就会因为性能问题挂起了。

永恒白天

未读,
2006年5月19日 09:24:542006/5/19
收件人 高性能网络编程邮件列表
一个ip,不同端口

可以将同种逻辑业务放置在一个单一服务器上,这样服务器就可以为这种逻辑作特殊优化
比如web业务中,经常将图片作为单一服务器或服务器组来存放

BrillyWu

未读,
2006年5月22日 05:29:392006/5/22
收件人 dev4s...@googlegroups.com
如果数据表不复杂,可以试试 berkeley DB

wangw...@gmail.com

未读,
2006年6月4日 21:52:062006/6/4
收件人 高性能网络编程邮件列表
做此类项目还会嫌Oracle贵???

ball...@yahoo.com.cn 写道:

> 类似的,Oracle好贵啊!!呵呵,能用我也想用!

jack

未读,
2006年6月6日 22:56:442006/6/6
收件人 高性能网络编程邮件列表
Oracle现在我也在用,但觉得也不怎么样,只是觉得因为操作系统原因,根本同数据库没什么关系,在windows同Linux对比下的原因而Linux的确更快,但在win下Oracle也就是哪样子。如果你要用Oracle就必须更换操作系统才行,不然不会有较大的提升。
另外我还看过别人做过的系统,的确厉害就是用(数据库+文件)方式进行数据存储,非常酷。
回复全部
回复作者
转发
0 个新帖子