对于处理大数据量的应用,该使用何种数据库?

jn_liran 2002-06-02 09:04:29
当然也要考虑处理过程的速度和稳定安全性。请大侠分析一下?
...全文
670 39 打赏 收藏 转发到动态 举报
写回复
用AI写文章
39 条回复
切换为时间正序
请发表友善的回复…
发表回复
kingoftiger 2002-06-12
  • 打赏
  • 举报
回复
谢谢帮助
hcgui 2002-06-11
  • 打赏
  • 举报
回复
gz
lwglucky 2002-06-11
  • 打赏
  • 举报
回复
开玩笑,什么上10G ,100 G , 上 T 啊。。。
如果不采用别的技术,这么大的数据量,oracle一样玩死悄悄,定期轧帐,定期倒表,好好设计业务模型是关键,指望什么数据库在10G ,100G还能正常运行。
ozzzzzz 2002-06-11
  • 打赏
  • 举报
回复
怎么这么乱 一个小东西要用那么贵的东西干吗 大家看好需求在发言
那么小的东西 用SQL server之类的东西是浪费 要是这样的情况用interbase
的open版就可以了
badbird 2002-06-11
  • 打赏
  • 举报
回复
小型数据库就够用了

~~用盗版的就行了~~注意备份数据~~嘿嘿~~

只用过informix,sybase,oracle的东西

象其他的db2等,没有接触过,
arronzhou 2002-06-11
  • 打赏
  • 举报
回复
biny(技术为王):
就事论事地说,分表设计确实会增加应用的复杂程度,但这主要局限于sql层次,是可以控制的,安排得当的话,基本不会影响事务的完整性。
类似计费结算的项目我做过不少,应用调整的余地很大,不必一条道走到底,把过多的责任推到数据库上。事实上越是高档的基础软硬件,越是依赖应用设计,只有这样才能充分发挥其能力。
用户对基础软硬件的选择多少参考了软件开发者的意见,投资一旦付出,就相对固定了,所以应用必须根据现实情况,更多地立足于现有设备进行调整。我过去曾有过迷信基础软硬件、忽视应用设计的想法,这使我付出了相当沉重的代价,对客户也不好交待,由此逐渐明白一个好的应用设计确实有起死回生的力量。这一点我赞同c_l_o_u_d的观点。
KingSunSha 2002-06-10
  • 打赏
  • 举报
回复
天哪!这么小的一个东西搞到这么复杂!还要用到T级的数据库?

说实话,规划得好一点、代码优化经验丰富一点,这样的项目用ACCESS足够了。
biny 2002-06-09
  • 打赏
  • 举报
回复
To arronzhou(阿隆)

大业务系统中单表记录数量过亿是很正常的,尤其是计费结算相关的业务中,分表设计会使系统开发非常复杂烦琐,而且会使事务完整性和可靠性降低。
数据库系统有处理应付这样大数据量表的方法,
硬件也不想你想像的那么不中用。
c_l_o_u_d 2002-06-09
  • 打赏
  • 举报
回复
我做的最大的一个项目数据库数量是50G(用informix数据库,IBM RIS6000四个节点),有某几张报表的生成时间在10小时以上。我们曾经就数据库的优化问题请教了informix和oracle的专家,结论是没有办法——如果应用系统要求做如此复杂的查询的话!
所以数据库访问效率还得看你的应用系统设计。虽然很多数据库的设计上都支持单表TB级的数据,但这并没有考虑应用的复杂度.
现在成天讨论数据仓库,有没有人认真分析过对如此大的数据量要做一些什么样的软件和硬件优化?不要以为用户的耐心很好。何况要看这种分析结果的人往往都是上层,时间格外宝贵。
arronzhou 2002-06-09
  • 打赏
  • 举报
回复
单表记录过亿某种程度上说明应用设计有问题,就算使用极为厉害的软硬件也是解决掉现在而应付不了将来
biny 2002-06-08
  • 打赏
  • 举报
回复
如果数据库事务量很大,负载很高,数据库服务器一般需要使用小型机,可选择DB2或Oracle。
如果数据库应用程序开发比较复杂,建议使用Oracle,开发接口做的是最好的,易于上手。
至于大数据量的应用系统,比比皆是。一般电信、银行系统每天都有上百万的事务量,单表数据过亿条很普通。

To kingoftiger(留心!)
你给出的那些SQL语句,缺乏最基本的SQL优化概念,还是先看一些介绍SQL的书籍最好。
sunbn 2002-06-07
  • 打赏
  • 举报
回复
>国内正在用teradata的就两个:上交所跟民航客服。按每天几百M的数据量,>我猜应该是上交所。单表记录条数2亿这不希奇,随便一家省行积累的帐户交>易信息都不止这个数。

>teradata的好处是按节点买,扩容方便。典型的数据仓库产品,居然是连自>
>己硬件带自己软件一起买的。

长知识啊,以前都不知道。
bluehope2003 2002-06-07
  • 打赏
  • 举报
回复
在fldmk.jszl、flsfcyb.rq、fldmk.bm=flsfcyb.bm上建索引
select count(*) into :MCount from fldmk,flsfcyb
where fldmk.jszl=:fgr and flsfcyb.rq=:PreMDate and fldmk.bm=flsfcyb.bm;

INSERT INTO flsfcyb(bm, rq, byjc, hj, pjj, bygj, syjc, kfbmdm)
SELECT fldmk.bm, :EnDate, 0, 0, 0, 0, 0, :ckdm FROM fldmk,flsfcyb
WHERE kfbmdm=:ckdm and jszl=:fgr and flsfcyb.rq=:EnDate)
and (fldmk.bm = flsfcyb.bm(+) and (flsfcyb.bm is null);

kingoftiger 2002-06-06
  • 打赏
  • 举报
回复
下列语句如何优化,我在执行时竟要等待10分钟左右,太慢了
1、select count(*) into :MCount from fldmk,flsfcyb where
fldmk.bm=flsfcyb.bm and fldmk.jszl=:fgr and flsfcyb.rq=:PreMDate;

2、INSERT INTO flsfcyb(bm, rq, byjc, hj, pjj, bygj, syjc, kfbmdm)
SELECT fldmk.bm, :EnDate, 0, 0, 0, 0, isnull(fldmk.cskc,0), :ckdm FROM fldmk,flsfcyb WHERE fldmk.kfbmdm=:ckdm and fldmk.bm=flsfcyb.bm and fldmk.jszl=:fgr;

3、delete flsfcyb from fldmk where fldmk.bm=flsfcyb.bm and fldmk.jszl=:fgr and flsfcyb.kfbmdm=:ckdm and flsfcyb.rq=:EnDate;

4、insert into flsfcyb(bm,rq,syjc,bygj,hj,byjc,pjj,kfbmdm)
select flsfcyb.bm,:EnDate,isnull(flsfcyb.byjc,0),0,0,0,0,:ckdm from fldmk,flsfcyb where fldmk.bm=flsfcyb.bm and fldmk.jszl=:fgr and flsfcyb.kfbmdm=:ckdm and flsfcyb.rq=:PreMDate;

5、INSERT INTO flsfcyb(bm, rq, byjc, hj, pjj, bygj, syjc, kfbmdm)
SELECT fldmk.bm, :EnDate, 0, 0, 0, 0, 0, :ckdm FROM fldmk
WHERE kfbmdm=:ckdm and jszl=:fgr and bm not in(select bm from flsfcyb where rq=:EnDate) ;

6、update flsfcyb set
bygj = isnull((select sum(flrkd.sl) from flrkd
where bm=flsfcyb.bm and flrkd.jszl=:fgr and zdrq>=:BeginDate and zdrq<=:EnDate),0)  WHERE flsfcyb.kfbmdm=:ckdm and rq=:EnDate;
7、update flsfcyb set flsfcyb.byjc=round(isnull(flsfcyb.syjc,0) + isnull(flsfcyb.bygj,0) - isnull(flsfcyb.hj,0),5)
from fldmk WHERE flsfcyb.kfbmdm=:ckdm and fldmk.jszl=:fgr and flsfcyb.rq=:EnDate;

顺便说一下,上面7条语句是在一个事件中执行的,其执行速度可想而知,烦各位帮我整整
Tommy Chang 2002-06-06
  • 打赏
  • 举报
回复
国内正在用teradata的就两个:上交所跟民航客服。按每天几百M的数据量,我猜应该是上交所。单表记录条数2亿这不希奇,随便一家省行积累的帐户交易信息都不止这个数。

teradata的好处是按节点买,扩容方便。典型的数据仓库产品,居然是连自己硬件带自己软件一起买的。

:)
Tommy Chang 2002-06-06
  • 打赏
  • 举报
回复
teradata?那玩艺不是拿来做业务系统的

如果强调交易的速度,建议IMS(呵呵,好像不太合时宜)。目前rdbms的话,有db2(on 390),udb eee, oracle ops, informix xps等几个选择。量的话,这几个数据库都没问题

:)
Tommy Chang 2002-06-06
  • 打赏
  • 举报
回复
teradata?那玩艺不是拿来做业务系统的

如果强调交易的速度,建议IMS(呵呵,好像不太合时宜)。目前rdbms的话,有db2(on 390),udb eee, oracle ops, informix xps等几个选择。量的话,这几个数据库都没问题

:)
rick1976 2002-06-06
  • 打赏
  • 举报
回复
用Teradata吧,不过你可能找不到,我目前接触到的最庞大的数据库,中国XX就在用它,每天几百M的数据量,我接触的单表记录条数最大为2亿多.
kakiyawen 2002-06-06
  • 打赏
  • 举报
回复
不知道你的大量是多大?总之物尽其用,能用Access,fox就不要用SQL Server、Oracle、DB2。在能用的情况下尽量节约费用。用户是上帝。
nsgvb 2002-06-06
  • 打赏
  • 举报
回复
mysql不好吗?
加载更多回复(19)

34,575

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧