查看: 34539|回复: 136

【有奖话题讨论】CPU核越多:数据库就跑得越快吗?(已公布获奖名单)

[复制链接]
认证徽章
论坛徽章:
127
茶鸡蛋
日期:2012-01-16 14:24:41鲜花蛋
日期:2012-06-06 14:48:18双黄蛋
日期:2013-01-07 21:07:482013年新春福章
日期:2013-02-25 14:51:24优秀写手
日期:2013-12-18 09:29:082014年新春福章
日期:2014-02-18 16:44:08马上有对象
日期:2014-02-18 16:44:08马上加薪
日期:2014-03-18 09:57:11马上有车
日期:2014-03-20 16:13:24马上有房
日期:2014-03-20 16:14:11
发表于 2014-6-17 09:44 | 显示全部楼层 |阅读模式

谈到OLTP数据库,大家不会觉得陌生,比如飞机订票、网上交易、银行系统都会用到OLTP数据库。OLTP数据库的最大优点在于支持即时处理输入的数据,衡量OLTP数据库好坏的一个重要的性能指标是实时响应时间,因此有人把高性能OLTP数据库是数据库界的珠穆朗玛。只是CPU核越多,数据库就一定跑得越快吗?与主流商业数据库相比,国产数据库、开源数据库差距明显。过去的一年里,神舟通用成功地将同步技术应用于神通数据库的多个关键设计中,并在OLTP高性能领域取得了长足的进步。


本期话题:

1.对于SQL开发人员来将,有必要了解开发的数据库应用属于哪种类型。而主流的数据库应用类型有两种,即OLTP与OLAP,请谈谈OLTP数据库与OLAP数据库的区别。

2.通过对神通数据库的上一版本经过测试,测试基准表明(参见附件图),当处理器从1路4核调整为2路6核时,神通数据库的交易响应速度提高了100%;当处理器从2路6核提高到4路8核时,神通数据库的交易响应速度提高了25%;而当处理器从4路8核增加到8路10核时,神通数据库的交易响应速度反而降低了60%;这到底是为什么?是并发协议出了问题?还是同步原语出了问题?或者其它原因?

3.从实战的角度来讲,要想提高数据库的高性能并发响应速度,有专家建议优化设计的关键点是锁和日志,您是否赞同,为什么?请分析下锁与日志的优缺点。

4.通过将同步技术应用于神通数据库的多个关键设计后,神通数据库新版本的测试基准表明(参见附件图),当处理器从1路4核不断增加到8路10核时,数据库的交易响应速度也在直线上线,这是否意味着处理器的核越多,神通数据库跑得越快?是一劳永逸还是可能会出现新的拐点?


活动时间:6月17-7月1日

活动奖励:欢迎大家针对以上任意问题回帖,我们将根据大家的表现,选取特等奖一名,赠送精美神舟探月模型1个,选取积极回帖活跃会员10名,赠送50元京东购物礼品卡。


1.jpg 22.jpg

获奖名单:恭喜以下会员获奖,请获奖会员及时以短消息联系我,以便发送奖品。


50元京东购物礼品卡10名

gzmt

imybsd

zcl32

foreverlove2011

songmingliang

wmxcn2000

陌路巨额投入

pure_lotus

T-McGrady1

logo111

特等奖1名

leonarding


探月模型.jpg
论坛徽章:
5
2010新春纪念徽章
日期:2010-03-01 11:21:01ITPUB9周年纪念徽章
日期:2010-10-08 09:31:22优秀写手
日期:2014-07-01 06:00:12懒羊羊
日期:2015-03-04 14:52:112015年新春福章
日期:2015-03-06 11:58:18
发表于 2014-6-17 10:08 | 显示全部楼层
CPU肯定对数据库性能有着巨大的影响。还是要一分为二的看问题。
1.系统的瓶颈确实是在CPU上吗?I/O,memory,网络都有可能成为瓶颈。
2.在OLTP的情况下,对于大并发,每秒事务数极高的情况下,CPU是很容易出现瓶颈的。比如Oracle,只有一个LGWR进程,大并发的情况下,所有事务都需要提交,都要写日志。这种情况,CPU极易成为瓶颈,会看到大量的log file sync等待。还有就是逻辑读,latch的获取,都是消耗CPU的操作。

结论:对于大并发情况下的OLTP系统,CPU很容易成为系统瓶颈,这种情况下,增加CPU的核数能提高数据库的性能。

使用道具 举报

回复
论坛徽章:
18
技术图书徽章
日期:2014-06-18 14:20:102014年世界杯参赛球队: 希腊
日期:2014-06-20 16:01:122014年世界杯参赛球队: 加纳
日期:2014-06-26 23:51:20马上有对象
日期:2014-07-21 11:36:292014年世界杯参赛球队: 比利时
日期:2014-08-05 11:35:38
发表于 2014-6-17 11:08 | 显示全部楼层
本帖最后由 gzmt 于 2014-6-25 10:36 编辑

这次的话题确实不怎么好回答呀,感觉问题很广,我来回答第2个问题吧。

是并发协议出了问题?

    并发协议是整个并行系统的基础,测试中使用的三个厂商的数据库均支持MVCC。通过使用MVCC(多版本并发控制)算法,能够维持一个数据的多个版本使读写操作没有冲突,它优化了数据库并发系统,使系统在有大量并发用户时得到最高的性能,并且可以不用关闭服务器就直接进行热备份。像MVCC这样读写并行的优秀的并发协议,对高性能的OLTP数据库是至关重要的,但是有好的协议并不等于数据库就会有好的实现。所以问题不是处在并发协议之上。

同步原语出了问题?
    同步原语实现的目标,在于减少了同步本身的开销,在临界区执行路径较短时,可以发挥很大作用,如类Latch的实现,Atomic原子操作,Lock-Free结构,Memory Barriers,RCU等等。以数据库为代表的复杂并行系统,真正决定并发性能的,往往是一些逻辑复杂、执行路径较长的临界区,优化同步本身对性能的帮助有限。所以,问题也不是出在同步原语上。

问题出在哪?
    数据库中主要的热点临界区有日志、锁、事物、SGA、字典缓存……。从现象描述来看,是因为关键临界区争用剧烈,部分临界区出现“越并发性能越差”的问题。解决问题的关键在于优化同步设计,减少临界区争用。因此同步设计将是神通数据库的主攻方向。

使用道具 举报

回复
论坛徽章:
18
技术图书徽章
日期:2014-06-18 14:20:102014年世界杯参赛球队: 希腊
日期:2014-06-20 16:01:122014年世界杯参赛球队: 加纳
日期:2014-06-26 23:51:20马上有对象
日期:2014-07-21 11:36:292014年世界杯参赛球队: 比利时
日期:2014-08-05 11:35:38
发表于 2014-6-17 12:04 | 显示全部楼层
本帖最后由 gzmt 于 2014-6-17 12:06 编辑

拐点主要会出现在数据库设计和CPU设计这两方面。

数据库设计方面主要涉及对CPU高速缓存以及内存的使用算法,但是我对神通数据库不怎么熟悉,就不多说了;

CPU设计方面,每个CPU内核共享使用高速缓存以及内存总线,这其中需要CPU厂商设计合理的算法。即便算法合理,当内核越多时,所有的内核都在通过相同的管道向存储器发出请求,这就像1个、2个、4个或8个人在同时说“我等着要这个东西”,一直等着回复。

使用道具 举报

回复
论坛徽章:
51
2012新春纪念徽章
日期:2012-08-24 17:06:04马上有对象
日期:2014-10-31 15:14:43马上有车
日期:2014-12-17 16:04:37马上有房
日期:2014-12-29 08:11:41马上有车
日期:2015-01-16 16:56:11马上加薪
日期:2015-02-05 11:24:51沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:312015年新春福章
日期:2015-05-08 10:02:59喜羊羊
日期:2015-06-11 08:58:52
发表于 2014-6-17 14:04 | 显示全部楼层
1.OLTP通常是时间短,数据量小的事务处理,OLAP通常是大量数据的处理,汇总分析,时间长,数据量大.
2.处理器核数越多,数据库的处理能力越高,当达到一定核数后,数据库的瓶颈已经不在CPU的处理能力上了,所以更多的CPU反而在性能上得不到提升.
3.赞同优化锁和日志提升性能,锁和日志是保证数据库安全稳定可靠的核心.所有的数据库处理都必须经过这一环节,缺点就是过多的竞争和等待造成性能下降
4.神通应用同步技术,具体的我们不了解,能分享下更多的同步技术原理是如何提高性能并且保证数据可靠性的吗?

使用道具 举报

回复
论坛徽章:
151
授权会员
日期:2005-11-16 17:49:25世界杯纪念徽章
日期:2006-07-20 13:19:20ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44生肖徽章2007版:龙
日期:2008-11-25 11:15:28生肖徽章2007版:羊
日期:2009-06-02 18:18:38生肖徽章2007版:鼠
日期:2009-06-17 22:01:192010新春纪念徽章
日期:2010-03-01 11:04:582010年世界杯参赛球队:科特迪瓦
日期:2010-06-11 19:25:562010广州亚运会纪念徽章:网球
日期:2010-12-31 16:37:522010广州亚运会纪念徽章:藤球
日期:2011-01-02 15:47:20
发表于 2014-6-17 14:33 | 显示全部楼层
1OLTP是要实时处理交易数据,OLAP则是在后台进行数据仓库应用,提供决策支持所需要的分析数据。
2.神通数据库的交易响应速度与处理器核数非线性相关,甚至从4路8核增加到8路10核时交易响应速度反而降低了60%;与并发协议有关系不大,由于处理核数增加是会影响多线程并发处理的同步问题。

3.从实战的角度来讲,要想提高数据库的高性能并发响应速度,有专家建议优化设计的关键点是锁和日志,您是否赞同,为什么?请分析下锁与日志的优缺点。
设计优化不完全依赖锁和日志两个关键点,要看速度瓶颈,甚至优化一下SQL表达式、更新一下索引也可能见效大。锁确保数据一致性,能够按事务进行处理。日志优化则有利于事务回滚速度,避免不谓的磁盘IO。
4.通过将同步技术应用于神通数据库的多个关键设计后,神通数据库新版本的测试基准表明当处理器从1路4核不断增加到8路10核时,数据库的交易响应速度也在直线上线,这是否意味着处理器的核越多,神通数据库跑得越快?是一劳永逸还是可能会出现新的拐点?当然不会,当处理器资源相对需求过剰后,会出现新的拐点。

使用道具 举报

回复
认证徽章
论坛徽章:
39
2014年世界杯参赛球队: 英格兰
日期:2014-06-13 14:40:022013数据库大会纪念章
日期:2015-03-18 10:16:212014数据库大会纪念章
日期:2015-03-18 10:16:21秀才
日期:2015-06-24 13:05:36秀才
日期:2015-07-30 16:18:26秀才
日期:2015-08-06 13:55:21秀才
日期:2015-08-13 13:38:45知识
日期:2015-08-13 14:08:10秀才
日期:2015-08-24 09:48:07秀才
日期:2015-09-10 17:13:35
发表于 2014-6-17 14:38 | 显示全部楼层
首先来说说CPU核越多,数据库就一定跑得越快吗?

     我们都知道多核技术可以通过划分任务,线程应用能够充分利用多个执行内核,并可在特定的时间内执行更多任务。操作系统会利用所有相关的资源,将它的每个执行内核作为分立的逻辑处理器。通过在两个执行内核之间划分任务,多核处理器可在特定的时钟周期内执行更多任务。 多核架构能够使用的软件更出色地运行,并创建一个促进未来的软件编写更趋完善的架构。操作系统专为充分利用多个处理器而设计,且无需修改就可运行。为了充分利用多核技术,应用开发人员需要在程序设计中融入更多思路,但设计流程与对称多处理 (SMP) 系统的设计流程相同,并且单线程应用也继续运行。 得益于线程技术的应用在多核处理器上运行时将显示出卓越的性能可扩充性。但是在cup与数据库速度方面,并不是呈正比的。。
个人感觉CUP内核的增加,数据库并行处理能力确实能够大大增加。就拿英特尔上一代至强7400相比,与先推行的至强7500采用8核(据官方数据,处理器在数据方面的计算性能是上一代的2.5倍,而其中最显著的功效来源于4条QPI直连总线带来的超快通讯速度(可到6.4GT/s,远非以往FSB总线所能企及)、超大的L3缓存(多达24MB)和9倍于前的内存带宽(四通道DDR3)。。。但是还是觉得对于CUP内核数量来说,还是要考虑价格成本还有需要处理的数据总量来选择合适的CUP内核数吧。。

  
1.对于SQL开发人员来将,有必要了解开发的数据库应用属于哪种类型。而主流的数据库应用类型有两种,即OLTP与OLAP,请谈谈OLTP数据库与OLAP数据库的区别。
     
   OLTP一般注重高并发,各个内存的命中率,譬如SHARED POOL, BUFFER CACHE的命中率。在设计上也会注重这些方面。OLTP的数据可能会有个时间窗口,因此有时候设计上也会考虑归档的方便。由于数据量相对比较小,因此OLTP大部分都是集中式的。OLAP的并发量比较小,大部分查询可能运行一次可能很久不会在运行,因此SQL的重用意义也就不大,很多命中率指标对于OLAP意义不是很大了,对于数据量比较大,分区,并行操作,压缩,物化视图,全文索引等技术可能都会在OLAP中体现。
OLAP的数据量可能比较大,上TB的OLAP都算大库了,有的都几百TB,甚至PB,因此很多OLAP库可能都分成了N个库,以便于分布式处理。此外OLAP一般都是采用星星模式或者雪花模式的。
主要区别总结:
    1.sga,pga的设置不同
    2.统计信息收集,有些oltp可以用oracle提供的自动job去收集,olap一般都自己写
    3.olap很少绑定变量
    4.oltp一个sql跑超过10秒就觉得很慢了,olap一个sql跑10分钟都很正常
    5.olap有用到star transform和bitmap index
    6.执行计划中,oltp常见nl,olap基本只有hj
    7.业务上来说,oltp的dml很多,olap基本就只有select
    8.优化来说olap基本上就只有从sql入手,oltp很多其他因素
     

2.通过对神通数据库的上一版本经过测试,测试基准表明(参见附件图),当处理器从1路4核调整为2路6核时,神通数据库的交易响应速度提高了100%;当处理器从2路6核提高到4路8核时,神通数据库的交易响应速度提高了25%;而当处理器从4路8核增加到8路10核时,神通数据库的交易响应速度反而降低了60%;这到底是为什么?是并发协议出了问题?还是同步原语出了问题?或者其它原因?
  
    当处理器从1路4核调整为2路6核时,神通数据库的交易响应速度提高了100%;当处理器从2路6核提高到4路8核时,神通数据库的交易响应速度提高了25%这些数据就可以说明并发协议没有出问题,这些可能说明一味的提升CPU的路数和核数不一定能够达到加快数据库的处理响应速度,CPU与数据库响应速度有一个最佳的适配数,超过了反而会浪费CPU资源而且响应速度也不会得到提升。。
   

   
   

3.从实战的角度来讲,要想提高数据库的高性能并发响应速度,有专家建议优化设计的关键点是锁和日志,您是否赞同,为什么?请分析下锁与日志的优缺点。

     个人还是比较赞同这个的。。因为提高数据库的高性能并发响应速度确实是有软件方法,也有硬件方法,可以通过提高CUP内核的数量来提升,不过通过这个会增加许多不必要的成本还有浪费很多硬件资源。。多并发处理快了,高性能并发响应速度也提上去了。。但是这不是最优的方法。。锁与日志这个软件维护的方法只是占用内存的一点点资源,就可以完美解决我们的问题。。。
  关于锁与日志的优缺点:
     事务日志和锁具有以下特点:事务日志是一个单元的工作,要么全做,要么全不做,保证操作的一致性和可恢复性,在多服务器环境中,使用用户定义的分布式事务,保证操作的一致性 。
锁是保证并发控制的手段 可以锁定的资源包括行、页、簇、表和数据库,锁的类型主要包括共享锁和排它锁,特殊类型的锁包括意图锁、修改锁和模式锁 。共享锁允许其他事务继续,使用锁定的资源, 排它锁只允许一个事务访问数据 ,系统本身可以处理死锁 用户可以根据实际情况定制锁的一些特征
总的来说:日志的作用是记录所有对数据库数据的修改,主要是保护数据库以防止故障发生后,对数据库进行恢复;锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前,先向系统发出请求,对其加锁。加锁后事务就对该数据对象有了一定的控制,在该事务释放锁之前,其他的事务不能对此数据对象进行更新操作。

4.通过将同步技术应用于神通数据库的多个关键设计后,神通数据库新版本的测试基准表明(参见附件图),当处理器从1路4核不断增加到8路10核时,数据库的交易响应速度也在直线上线,这是否意味着处理器的核越多,神通数据库跑得越快?是一劳永逸还是可能会出现新的拐点?

   这个问题还是参照上面说的那些吧。。CUP内核的增加,数据库并行处理能力确实能够大大增加。就拿英特尔上一代至强7400相比,与先推行的至强7500采用8核(据官方数据,处理器在数据方面的计算性能是上一代的2.5倍,而其中最显著的功效来源于4条QPI直连总线带来的超快通讯速度(可到6.4GT/s,远非以往FSB总线所能企及)、超大的L3缓存(多达24MB)和9倍于前的内存带宽(四通道DDR3)。。。但是还是觉得对于CUP内核数量来说,还是要考虑价格成本还有需要处理的数据总量来选择合适的CUP内核数吧。。个人觉得不管什么事情都不会一劳永逸,这个可能会出现新的拐点吧。。

使用道具 举报

回复
认证徽章
论坛徽章:
764
2014年世界杯参赛球队: 加纳
日期:2014-05-20 17:24:592014年世界杯参赛球队:墨西哥
日期:2014-05-20 17:25:142014年世界杯参赛球队: 波黑
日期:2014-05-20 17:27:292014年世界杯参赛球队: 希腊
日期:2014-07-15 11:05:212014年世界杯参赛球队: 阿尔及利亚
日期:2014-07-15 11:05:212014年世界杯参赛球队: 厄瓜多尔
日期:2014-07-15 14:14:452014年世界杯参赛球队: 哥斯达黎加
日期:2014-06-16 15:29:332014年世界杯参赛球队: 智利
日期:2014-06-16 17:03:11 2014年世界杯参赛球队: 德国
日期:2014-06-16 17:10:512014年世界杯参赛球队: 葡萄牙
日期:2014-06-18 09:28:47
发表于 2014-6-18 09:13 | 显示全部楼层
3.从实战的角度来讲,要想提高数据库的高性能并发响应速度,有专家建议优化设计的关键点是锁和日志,您是否赞同,为什么?请分析下锁与日志的优缺点。

     赞同。因为提高数据库的高性能并发响应速度确实是有软件方法,也有硬件方法,可以通过提高CUP内核的数量来提升,不过通过这个会增加许多不必要的成本还有浪费很多硬件资源。。多并发处理快了,高性能并发响应速度也提上去了。。但是这不是最优的方法。。锁与日志这个软件维护的方法只是占用内存的一点点资源,就可以完美解决我们的问题。。。
  关于锁与日志的优缺点:
     事务日志和锁具有以下特点:事务日志是一个单元的工作,要么全做,要么全不做,保证操作的一致性和可恢复性,在多服务器环境中,使用用户定义的分布式事务,保证操作的一致性 。
锁是保证并发控制的手段 可以锁定的资源包括行、页、簇、表和数据库,锁的类型主要包括共享锁和排它锁,特殊类型的锁包括意图锁、修改锁和模式锁 。共享锁允许其他事务继续,使用锁定的资源, 排它锁只允许一个事务访问数据 ,系统本身可以处理死锁 用户可以根据实际情况定制锁的一些特征
总的来说:日志的作用是记录所有对数据库数据的修改,主要是保护数据库以防止故障发生后,对数据库进行恢复;锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前,先向系统发出请求,对其加锁。加锁后事务就对该数据对象有了一定的控制,在该事务释放锁之前,其他的事务不能对此数据对象进行更新操作。

使用道具 举报

回复
认证徽章
论坛徽章:
222
2010新春纪念徽章
日期:2010-03-01 11:20:51ITPUB元老
日期:2019-04-25 13:46:07至尊黑钻
日期:2015-02-15 09:47:47至尊黑钻
日期:2015-08-13 13:38:122015年中国系统架构师大会纪念徽章
日期:2015-07-31 17:48:202015中国数据库技术大会纪念徽章
日期:2015-05-15 14:08:23管理团队2007贡献徽章
日期:2015-01-19 09:48:27海蓝宝石
日期:2017-04-21 09:23:17红宝石
日期:2015-02-03 10:26:04海蓝宝石
日期:2015-02-03 10:23:39
发表于 2014-6-18 10:19 | 显示全部楼层
增加 CPU 在某些场合,就大大提高数据库的速度,但是到了一个某个特定值,就算再加 100 倍的 CPU 上来,也是白白的浪费。

倒底这个“某个特定值”是什么意思,我举一个例子:
我们每个人在公司都有办公位,大家都可能会觉得办公位比较小(CPU),桌上放几本书,放个水杯,放些花(个人对CPU的需求),再不断的添置新东西,这时根据个人的申请,公司又给了一个同样大小的桌子,可以把书搬过去,原来的桌子(CPU),就会显的空闲了许多(压力变小了),但是你还是觉得不够用,又申请一张桌子(增加第三个CPU),你一看好了,东西摆放的正好,所有的物品都离自己很近,使用方便(硬件设备已经满足,也就是上面提到的值)。这个时候再给你增加 1 张桌子(CPU)就已经是浪费了,就不要说再增加 100 张桌子(CPU)。

使用道具 举报

回复
论坛徽章:
0
发表于 2014-6-18 23:18 | 显示全部楼层
借用这话:
CPU肯定对数据库性能有着巨大的影响。还是要一分为二的看问题。
1.系统的瓶颈确实是在CPU上吗?I/O,memory,网络都有可能成为瓶颈。
2.在OLTP的情况下,对于大并发,每秒事务数极高的情况下,CPU是很容易出现瓶颈的。比如Oracle,只有一个LGWR进程,大并发的情况下,所有事务都需要提交,都要写日志。这种情况,CPU极易成为瓶颈,会看到大量的log file sync等待。还有就是逻辑读,latch的获取,都是消耗CPU的操作。

使用道具 举报

回复
求职 : 技术/实施/服务顾问
论坛徽章:
6
SQL大赛参与纪念
日期:2011-04-13 12:08:17ITPUB十周年纪念徽章
日期:2011-11-01 16:19:412012新春纪念徽章
日期:2012-01-04 11:49:54咸鸭蛋
日期:2012-04-05 14:04:082014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11
发表于 2014-6-19 20:39 | 显示全部楼层
1.对于SQL开发人员来将,有必要了解开发的数据库应用属于哪种类型。而主流的数据库应用类型有两种,即OLTP与OLAP,请谈谈OLTP数据库与OLAP数据库的区别。
OLTP数据库面向事务型,特点是并发用户多,sql语句简单,事务短,响应时间快,写操作相对来说比较多,数据库的设计一般采用第三范式;
OLAP则是分析型的数据库系统,特点是并发用户数量少,SQL语句比较复杂,通常是多个表的连接,响应时间可能比较长,基本上是读操作为主,写操作主要用于数据的批量装入,数据库的设计上基本采用星型模型和雪花型模型。

2.通过对神通数据库的上一版本经过测试,测试基准表明(参见附件图),当处理器从1路4核调整为2路6核时,神通数据库的交易响应速度提高了100%;当处理器从2路6核提高到4路8核时,神通数据库的交易响应速度提高了25%;而当处理器从4路8核增加到8路10核时,神通数据库的交易响应速度反而降低了60%;这到底是为什么?是并发协议出了问题?还是同步原语出了问题?或者其它原因?
这个原因应该不是底层的同步原语出问题,而应该属于系统再向上层的一些同步处理出现问题,比如数据库的数据和索引页面访问方面时候的latch,进行锁操作,日志缓存读写的自旋锁等,以及查找SQL执行SQL时候的内部锁等实现上,可能需要考虑一些多个内存节点的分区操作,利用NUMA非一致性内存访问等技术。
其实这个方面也是系统最难以调优的部分,只有数据库系统实现的时候提供了大量的运行时统计参数后才能真正分析了解系统的瓶颈,这也是目前主流的商业数据库其中的一个核心优势,像mysql等开源数据库在这个方面就有差距了。

3.从实战的角度来讲,要想提高数据库的高性能并发响应速度,有专家建议优化设计的关键点是锁和日志,您是否赞同,为什么?请分析下锁与日志的优缺点。
对于数据库系统自身来讲,可能优化设计的还不止基本的事务锁和日志,包括前面提到的latch, 自旋锁等内部并发机制。

4.通过将同步技术应用于神通数据库的多个关键设计后,神通数据库新版本的测试基准表明(参见附件图),当处理器从1路4核不断增加到8路10核时,数据库的交易响应速度也在直线上线,这是否意味着处理器的核越多,神通数据库跑得越快?是一劳永逸还是可能会出现新的拐点?
出现拐点是必然的,即使数据库本身设计得好,能处理很多的并发,操作系统在某些处理上也会跟不上,比如进程调度,内存管理等;当然在这之前,存储设备还需要能跟上IO的请求速度,单机上的HBA卡的性能毕竟是受限的。
即使不算硬盘IO的限制,从测试的图上可以看出来,虽然神通数据库的扩展性很好,但是还是不如oracle。oracle在256个核的系统上表现都有点吃力,神通可能更早出现问题。

使用道具 举报

回复
招聘 : Oracle 课程老师
认证徽章
论坛徽章:
47
火眼金睛
日期:2018-02-28 22:00:002010数据库技术大会纪念徽章
日期:2015-04-23 10:33:192014年世界杯参赛球队: 俄罗斯
日期:2014-07-17 17:21:42ITPUB伯乐
日期:2014-07-17 14:45:422014年世界杯参赛球队: 希腊
日期:2014-06-20 16:01:122014年世界杯参赛球队:克罗地亚
日期:2014-06-12 16:53:56马上加薪
日期:2014-04-25 14:18:13目光如炬
日期:2014-04-21 06:00:12马上有房
日期:2014-03-31 15:10:37目光如炬
日期:2014-03-17 06:00:11
发表于 2014-6-24 18:33 | 显示全部楼层
本帖最后由 leonarding 于 2014-7-9 22:45 编辑

1.开发工程师是需要了解所开发的系统是哪种类型和上面所跑的业务流程以及预测正式使用后工作负载情况
根据上述经验,不同类似可采用的调优方式与优化技巧是不同的,绑定变量、变量窥视、缓存结果集、压缩技术、并发技术、baseline、缓存执行计划、直接加载大对象等等技术是用在不同场景下的。
2.当今硬件水平下CPU已经不是性能提高的瓶颈了,CPU的多只是可以提高聚合运算的时间和并发处理时间,数据库里面都会有一个叫并发协调器工具,它来分配并行进程的运行情况,CPU多分配的子任务也多,在最后的整合汇总结果集的过程中反而性能下降,因为需要更多的资源去协调各个子任务相互关系。当我们的业务逻辑是一种线性的处理过程时,在多的CPU都是爱莫能助的。

3.提高OLTP类型的数据库应该重点考虑内存的容量和内存总线频率参数,让更多的数据缓存在内存中,减少硬盘访问次数,运用分隔技术尽量把热数据长期加载到内存中提高数据命中率。4.提高数据库高性能并发响应速度,数据库中要充分应用好lock和latch,lock解决的是资源争用问题,为了保证事物一致性必须要在某个时刻只允许某个session独占资源,latch解决的是并发资源的争用问题,优先获得latch的session才有资格去处理数据。

4.大并发下极易造成log file sync等待事件,但是这种争用最大的瓶颈在于IO资源,在异步IO情况下要比同步IO情况下效果要好些。神通数据库在实现并发特性上同步技术,当下很多数据库产品都使用同步技术,但不代表使用同步技术就可以实现大规模的并发场景,并发性能的好坏要从若干个层面上来分析,例如 底层存储的读写同步   内存同步   latch等资源同步   catch同步   CPU结果集聚合同步 等都是一个系统模式,需要的是整体的同步协议来调整好每一层的衔接,这样才能达到更好的并发效果




使用道具 举报

回复
论坛徽章:
0
发表于 2014-6-27 14:57 | 显示全部楼层
通过对神通数据库的上一版本经过测试,测试基准表明(参见附件图),当处理器从1路4核调整为2路6核时,神通数据库的交易响应速度提高了100%;当处理器从2路6核提高到4路8核时,神通数据库的交易响应速度提高了25%;而当处理器从4路8核增加到8路10核时,神通数据库的交易响应速度反而降低了60%;这到底是为什么?是并发协议出了问题?还是同步原语出了问题?或者其它原因?

并发协议是整个并行系统的基础,优秀的并发协议(如MVCC读写并行)对高性能OLTP数据库至关重要。但这并不意味着好的协议支持好的实现。而且从基准测试的结果来看,这三款数据库均支持MVCC并发协议,所以不是并发协议出的问题。
同步原语实现的目标,在于减少同步本身的开销,在临界区执行路径较短时,可以发挥很大作用。以数据库为代表的复杂并行系统,真正决定并发性能的,往往是一些逻辑复杂、执行路径较长的临界区,优化同步本身对性能的帮助有限。

关键临界区比如日志、锁、事务、SGA、字典缓存等争用 Top Wait: BMSQL tpcc 30分钟统计采样剧烈,部分临界区出现“越并发性能越差”问题,因此解决问题的关键在于优化同步设计,减少临界区争用。因此同步设计将是优化的关键。

使用道具 举报

回复
论坛徽章:
0
发表于 2014-6-27 15:53 | 显示全部楼层
单从CPU来说,除非一个SQL语句使用并行处理,才能同时用上多个CPU内核,这样的一半是进行大数据量分析的OLAP;对于OLTP这样的高并发,少量数据检索,并行处理对于单个的的SQL语句并不会带来多少益处。在OLTP环境,CPU内核的增加带来的一个益处是整个负载能里的提高,能承载更多的并发用户,但并不能提高单个SQL请求的反应速度。另一点楼主文中没有提到CPU变为8路10核,CPU的频率是否也提高了?一般情况下,为了保证功耗控制在一定范围,内核增加,主频应该下降了。主频下降,单个SQL语句的执行速度会减慢,也就是说整体反应速度下降,但并发用户的负载量增加。如果涉及到内存大小,IO,网络,就更复杂了。

从刚才的那个的测试基准图上看,神通数据库(老版本)在4路8核有一个拐点,整机负载能力突然下降了。这点感觉不太正常。说明数据库引擎不能很好的应对更多的CPU带来的硬件计算能力提升。那个O*是暗指ORACLE么?以前做过ORACLE和MySQL的压力测试对比,同一个硬件平台,同样的数据量,一个产品对于不同数据库的版本。结果ORACLE10明显胜出,MySQL5.0落败。很多人可能不理解,ORACLE那么庞大,MySQL那么小巧。我觉得主要原因就是SQL共享机制的问题。ORACLE在share sql 上做的非常好,所以减少了很多的硬解析。而mysql没有一个好的SQL共享机制,造成比较高的CPU占用率。神通数据库中数据库引擎,SQL解析,SQL优化器上做的怎么样呢?

使用道具 举报

回复
论坛徽章:
0
发表于 2014-6-17 09:47 | 显示全部楼层
占楼~学习

使用道具 举报

回复
论坛徽章:
401
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
发表于 2014-6-17 10:08 | 显示全部楼层
神通数据库,其他数据库呢?

使用道具 举报

回复
论坛徽章:
0
发表于 2014-6-17 10:16 | 显示全部楼层
数据库不是取决在cpu,相同配置cpu越高,是会提升数据库的运算能力。只能说是同等配置情况下。否则就不能这么说。

使用道具 举报

回复
招聘 : 系统分析师
论坛徽章:
484
马上有钱
日期:2014-02-19 11:55:14itpub13周年纪念徽章
日期:2014-09-29 01:14:14itpub13周年纪念徽章
日期:2014-10-08 15:15:25itpub13周年纪念徽章
日期:2014-10-08 15:15:25马上有对象
日期:2014-10-12 11:58:40马上有车
日期:2014-11-16 17:11:29慢羊羊
日期:2015-02-09 17:04:38沸羊羊
日期:2015-03-04 14:43:432015年新春福章
日期:2015-03-06 11:57:31ITPUB年度最佳版主
日期:2015-03-18 15:48:48
发表于 2014-6-17 10:16 | 显示全部楼层
具体问题太泛
反而是标题还好说一些:
1、核多了,如果协调处理能力不足,那就无法将各个核的作用发挥到最大
2、核的对称性如果不好,即与内存等的对称性不匹配,那么效用也无法发挥到最大
3、回到问题上,数据库的瓶颈如果不在CPU上,那么加那么多核除了花掉剩余的预算外,还有什么用呢?

使用道具 举报

回复
论坛徽章:
490
2014年世界杯参赛球队:喀麦隆
日期:2015-08-17 16:10:052014年世界杯参赛球队:墨西哥
日期:2015-08-17 16:10:052014年世界杯参赛球队: 波黑
日期:2015-08-17 16:09:252014年世界杯参赛球队: 阿尔及利亚
日期:2015-08-17 16:09:082014年世界杯参赛球队: 澳大利亚
日期:2015-08-17 16:09:522014年世界杯参赛球队: 智利
日期:2015-08-17 16:09:522014年世界杯参赛球队:巴西
日期:2015-08-17 16:10:052014年世界杯参赛球队: 智利
日期:2015-08-17 16:09:522014年世界杯参赛球队: 意大利
日期:2015-08-17 16:09:392014年世界杯参赛球队:巴西
日期:2015-08-17 16:10:05
发表于 2014-6-17 10:19 | 显示全部楼层
不单单是cpu,内存。在于,SQL语句合理性,磁盘IO,很多关系。。

使用道具 举报

回复
论坛徽章:
18
技术图书徽章
日期:2014-06-18 14:20:102014年世界杯参赛球队: 希腊
日期:2014-06-20 16:01:122014年世界杯参赛球队: 加纳
日期:2014-06-26 23:51:20马上有对象
日期:2014-07-21 11:36:292014年世界杯参赛球队: 比利时
日期:2014-08-05 11:35:38
发表于 2014-6-17 10:31 | 显示全部楼层
本帖最后由 gzmt 于 2014-6-17 10:56 编辑

OLTP主要是以业务处理为主,为用户的应用系统提供实时响应。OLAP是专门为支持复杂的分析操作而设计的,可以为管理者提供决策支持。
OLTP系统管理的数据通常很琐碎,难以用于决策,通常采用面向应用的数据库设计。OLAP系统将大量历史数据进行汇总和聚集,用于决策分析,通常采用面向主题的数据库设计。

使用道具 举报

回复
论坛徽章:
10
2010新春纪念徽章
日期:2010-03-01 11:06:22ITPUB十周年纪念徽章
日期:2011-11-01 16:24:04ITPUB 11周年纪念徽章
日期:2012-10-09 18:09:192013年新春福章
日期:2013-02-25 14:51:242014年新春福章
日期:2014-02-18 16:43:09马上有钱
日期:2014-02-18 16:43:09itpub13周年纪念徽章
日期:2014-09-28 10:55:55懒羊羊
日期:2015-03-04 14:52:112015年新春福章
日期:2015-03-06 11:58:18
发表于 2014-6-17 10:44 | 显示全部楼层
OLTP和OLAP,后者有个A,自然分析和数据挖掘是主要任务吧;前者自然跟末端用户直接交互,要快,准,狠;

CPU多,应该是增加并发处理,同时在线用户多自然CPU多多益善;

神通数据库是啥……查查

使用道具 举报

回复

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

本版积分规则 发表回复

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