楼主: myth8860

[每周一议]应用是否应该使用大量的数据库特性?

[复制链接]
认证徽章
论坛徽章:
2
迷宫蛋
日期:2012-02-03 08:33:382012新春纪念徽章
日期:2012-02-07 09:59:35
发表于 2012-1-16 16:21 | 显示全部楼层
学习中。。。。。。

使用道具 举报

回复
招聘 : 系统架构师
认证徽章
论坛徽章:
369
秀才
日期:2015-08-10 09:03:20巨蟹座
日期:2015-09-09 14:25:25巨蟹座
日期:2015-09-10 09:03:46秀才
日期:2015-09-11 10:43:06摩羯座
日期:2015-09-20 17:10:27秀才
日期:2015-09-21 09:46:16秀才
日期:2015-09-21 11:16:42秀才
日期:2015-10-08 17:57:58天枰座
日期:2015-10-28 18:28:29秀才
日期:2015-09-06 10:42:32
发表于 2012-1-16 16:45 | 显示全部楼层
该用的还是用吧,已经花了那么多钱,其实这些应该从架构和开发角度来看.
但是个人不建议那么用,因为对oracle sga的特别是share pool的overhead,如果遇到高并发各种问题都会出来了...

使用道具 举报

回复
论坛徽章:
540
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
发表于 2012-1-16 22:41 | 显示全部楼层
fsm 发表于 2012-1-16 15:34
每种数据库都有自己在技术上的壁垒,提供给自己的死党fans的性能和提供给可能迁移到其他种类数据库的应用的 ...

LEFT JOIN 和 (+) 的例子能举一个吗?

使用道具 举报

回复
论坛徽章:
540
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
发表于 2012-1-16 22:43 | 显示全部楼层
yanggq 发表于 2012-1-16 16:45
该用的还是用吧,已经花了那么多钱,其实这些应该从架构和开发角度来看.
但是个人不建议那么用,因为对oracle ...

举个例子说明不建议那么用?建议的用法又是如何?
恰恰相反,你说的问题往往是因为不善用数据库特性引起的,比如试图用标准SQL来实现分析函数的功能。

使用道具 举报

回复
招聘 : 系统架构师
认证徽章
论坛徽章:
369
秀才
日期:2015-08-10 09:03:20巨蟹座
日期:2015-09-09 14:25:25巨蟹座
日期:2015-09-10 09:03:46秀才
日期:2015-09-11 10:43:06摩羯座
日期:2015-09-20 17:10:27秀才
日期:2015-09-21 09:46:16秀才
日期:2015-09-21 11:16:42秀才
日期:2015-10-08 17:57:58天枰座
日期:2015-10-28 18:28:29秀才
日期:2015-09-06 10:42:32
发表于 2012-1-17 09:17 | 显示全部楼层
newkid 发表于 2012-1-16 22:43
举个例子说明不建议那么用?建议的用法又是如何?
恰恰相反,你说的问题往往是因为不善用数据库特性引起 ...

我们的数据库并发一般都有30000,任何复杂点的SQL,或者耗费资源多一些的都会成为瓶颈..
你说只是一般情况,我说的是我们的情况,你可以把DW/oltp放一起,如果你的系统不够繁忙,但是不表示别人的都和你一样.
我们不用不表示我们不善用,使用一个特性的时候首先考虑运营维护团队是不是被overburden, 是的,在开发期间是很快乐,你的程序准备用多久?都是自己维护?

使用道具 举报

回复
招聘 : 系统架构师
认证徽章
论坛徽章:
369
秀才
日期:2015-08-10 09:03:20巨蟹座
日期:2015-09-09 14:25:25巨蟹座
日期:2015-09-10 09:03:46秀才
日期:2015-09-11 10:43:06摩羯座
日期:2015-09-20 17:10:27秀才
日期:2015-09-21 09:46:16秀才
日期:2015-09-21 11:16:42秀才
日期:2015-10-08 17:57:58天枰座
日期:2015-10-28 18:28:29秀才
日期:2015-09-06 10:42:32
发表于 2012-1-17 09:17 | 显示全部楼层
我们的机器可能没有你的好,才128 cpu+128G RAM,应该换好机器了.

使用道具 举报

回复
论坛徽章:
8
ITPUB十周年纪念徽章
日期:2011-11-01 16:25:512012新春纪念徽章
日期:2012-01-04 11:56:19现代
日期:2013-11-28 11:01:14马上加薪
日期:2014-03-31 10:53:18马上有钱
日期:2014-03-31 15:05:51优秀写手
日期:2014-04-26 05:59:55暖羊羊
日期:2015-03-04 14:53:002015年新春福章
日期:2015-03-06 11:58:18
发表于 2012-1-17 11:48 | 显示全部楼层
主要是软件对数据库的兼容长期规划,如果做一套DRP,只是定位中小企业,可以用mysql及其特性,如果想“通用”在软件的初期就应该把业务逻辑放到应用的DAO层,为后期切换数据库准备

使用道具 举报

回复
论坛徽章:
0
发表于 2012-1-17 14:29 | 显示全部楼层
yanggq 发表于 2012-1-17 09:17
我们的数据库并发一般都有30000,任何复杂点的SQL,或者耗费资源多一些的都会成为瓶颈..
你说只是一般情况 ...

支持楼主的观点。

使用道具 举报

回复
论坛徽章:
540
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
发表于 2012-1-17 23:59 | 显示全部楼层
yanggq 发表于 2012-1-17 09:17
我们的数据库并发一般都有30000,任何复杂点的SQL,或者耗费资源多一些的都会成为瓶颈..
你说只是一般情况 ...

我很好奇什么样的SQL算“复杂点的SQL”?你又是怎样拆分成简单的SQL? 这些简单SQL最终不还是得执行,你绕得过吗?如果这样做能奏效,CBO也会替你“拆分”,生成相应的计划。不管你是300个并发还是30000个,尽量不让数据库做多余的动作,这个原则不变。
除非这个复杂SQL里面有部分中间结果是可以缓存到数据库之外的。但那样意味着这部分数据必须是静态的,而且你要自己合并结果,代价就是应用复杂化。
复杂SQL和运营维护团队也不是对立的。如果你的做法仅仅是把复杂性从SQL层面剥离到应用开发层,只不过把皮球踢给另一个团队而已,如果是这样你也可以要求开发团队对复杂SQL负责嘛。

使用道具 举报

回复
招聘 : 系统架构师
认证徽章
论坛徽章:
369
秀才
日期:2015-08-10 09:03:20巨蟹座
日期:2015-09-09 14:25:25巨蟹座
日期:2015-09-10 09:03:46秀才
日期:2015-09-11 10:43:06摩羯座
日期:2015-09-20 17:10:27秀才
日期:2015-09-21 09:46:16秀才
日期:2015-09-21 11:16:42秀才
日期:2015-10-08 17:57:58天枰座
日期:2015-10-28 18:28:29秀才
日期:2015-09-06 10:42:32
发表于 2012-1-18 10:54 | 显示全部楼层
newkid 发表于 2012-1-17 23:59
我很好奇什么样的SQL算“复杂点的SQL”?你又是怎样拆分成简单的SQL? 这些简单SQL最终不还是得执行,你绕 ...

除了单表select/insert/update/delete以外的sql,
因为db和各种编译器均快到极限了
确实cache了很多到不同的层面,所以我们dal层非常强悍.即便这样db很多时候还是撑不住,只能拆分,从app层面早就拆了,每个应用都拆到不同的db,同一个应用也被迫分到不同的db.

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表