免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: send_linux

[其他] PCIE SSD对数据库架构的影响巨大?参与讨论得派克金笔!(获奖名单已公布-2014-6-27) [复制链接]

论坛徽章:
0
发表于 2014-05-13 15:38 |显示全部楼层
建议直接把数据放上去,缓冲不是个好方案。

2009532140 发表于 2014-05-12 18:46
回复 32# goallist

论坛徽章:
459
亥猪
日期:2014-05-31 12:08:03亥猪
日期:2014-05-31 12:07:38亥猪
日期:2014-05-31 12:08:04亥猪
日期:2014-05-31 12:07:43亥猪
日期:2014-05-31 12:07:52亥猪
日期:2014-05-31 12:08:09亥猪
日期:2014-05-31 12:07:51亥猪
日期:2014-05-31 12:08:02亥猪
日期:2014-05-31 12:07:59亥猪
日期:2014-05-31 12:07:37亥猪
日期:2014-05-31 12:07:50亥猪
日期:2014-05-31 12:07:39
发表于 2014-05-13 16:16 |显示全部楼层
回复 41# goallist


    日志文件呢?
日志是循环写的,对SSD 盘子是否是硬伤

论坛徽章:
0
发表于 2014-05-13 16:20 |显示全部楼层
恰恰相反,对MySQL来说,log是高性能下得瓶颈点,把log放在高速存储设备上有助于性能的提高。
回复 42# 2009532140


   

论坛徽章:
459
亥猪
日期:2014-05-31 12:08:03亥猪
日期:2014-05-31 12:07:38亥猪
日期:2014-05-31 12:08:04亥猪
日期:2014-05-31 12:07:43亥猪
日期:2014-05-31 12:07:52亥猪
日期:2014-05-31 12:08:09亥猪
日期:2014-05-31 12:07:51亥猪
日期:2014-05-31 12:08:02亥猪
日期:2014-05-31 12:07:59亥猪
日期:2014-05-31 12:07:37亥猪
日期:2014-05-31 12:07:50亥猪
日期:2014-05-31 12:07:39
发表于 2014-05-13 16:27 |显示全部楼层
回复 43# goallist


   
学习了,有时间研究一下mysql

论坛徽章:
3
季节之章:冬
日期:2015-01-15 10:36:57IT运维版块每日发帖之星
日期:2015-09-24 06:20:00IT运维版块每日发帖之星
日期:2015-10-24 06:20:00
发表于 2014-05-13 17:13 |显示全部楼层
没有用过ssd,有台笔记本配了ssd固态硬盘,但是不知道有什么作用。。

论坛徽章:
1
技术图书徽章
日期:2014-07-11 16:30:58
发表于 2014-05-14 14:10 |显示全部楼层
路过,lollollol

论坛徽章:
2
午马
日期:2015-01-27 11:22:392015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2014-05-15 00:43 |显示全部楼层

1, 我们应该怎么才能充分利用PCIE SSD这些出色的性能来优化我们的数据库架构和性能呢?

从ORACLE数据库的角度讲,SSD的作用无非是存储层。这就需要考虑哪些文件要同存储打交道
     1. 数据库软件,RAC, grid
  数据库软件目录通常安装在本地目录,或者共享目录。这些目录 其实并不需要ssd, 因为大多数文件没有更新的需求,运行时也不会在目录下有大量临时文件的读写。

     2. ASM
       ASM基本上已经成了ORACLE的存储标准。要玩好SSD,那么对ASM需要有了解,比如现在ASM支持用作votingdisk, ocr location, data diskgroup, ACFS for DBHome, redo/fb logs...
       像放置votingdisk的ASM盘,可以用SSD,但必须明白这边的瓶颈不只在于SSD的读写速度,有两个 一是磁盘心跳,一是网络心跳。 如果网络不给力,那么存储读写再好也于事无补。这边的SSD一是要满足大量小数据量的随机读写,也要对shared disk架构有很好的支持,这都需要很多客户长时间地验证才能做好。
       放置数据文件的盘,不必要用SSD。因为瓶颈一般不在这里。但这边如果容量比较大的话,尽量避免RAID5之类的配置。
       像redo log这些需要大量随机读的, 完全可以用SSD。但这边要注意的,一是避免传统硬盘的错误,不要大量使用相同规格的硬盘, 不要盲目使用RAID,如果是硬件级别的multipath,这种技术每个厂商都有自己的办法, 像EMC, DELL, Marvel之类的,都会同oracle合作进行大量测试,确保其解决方案同oracle db的兼容性。
       要防止重复作RAID,如硬件级别做了RAID,ASM层再做redundancy,那么性能可能没什么提升,反而会降低可靠性。 这在SSD上特别明显。
       基本上 理解ASM, 就是理解ORACLE 和SSD的解决方案大部分了。 各位有兴趣,可以google看看ASM+SSD的一些文档,也可以看看Linux上如 RHEL storage mgmt guide(Red_Hat_Enterprise_Linux-6-Storage_Administration_Guide-en-US.pdf)

     
    要充分发挥SSD的性能,还是要多看全局。
    先要看SSD同操作系统之间的联系,比如Linux上,这一款SSD产品的支持程度如何,决定了客户是否会考虑购买。那么在做产品同oracle兼容测试的时候,同样也要做os级别的兼容测试。
     SSD固然是快,但传统硬盘仍有较好的生命力,SATA+SSD混合硬盘也大行其道。 最大的原因,SSD并没有对 连续读写 有较好的提升。 那么 就需要 扬长避短,像DATAFILE之类的存储,就没有必要用SSD,如果用传统的,有较多成功案例的方案,可能对数据来说,更安全可靠了。
     还有就是要看应用环境,SSD固然不让存储本身成为短板,但其周围很可能有其他的瓶颈, 就如上面提到的放votingdisk的盘,严重依赖稳定高速的共享网络连接,如果一款SSD产品,有很好的网络解决方案集成,那无疑是加增了客户的信心。
     另外的问题,也是根本的问题,SSD比传统硬盘更快了, 但是否更安全了? 这个问题本身值得商榷,我们认为,只有经过检验的产品方案才可以称为安全。
      




2, 在PCIE SSD的帮助下,我们自己是否可以在普通服务器甚至PC上配置出类似Oracle Exadata性能的架构呢? 如果可以的话,应该怎么配置?

做不到。
理解这个问题,我们应当理解,Exadata is Oracle Engineered system. 用户就算是照搬硬件,也搭不出Exadata一样的性能的。

Exadata上面确实用了类SSD,比如某款Marvel的Flash disk 在Exadata的cell node上采用。这些产品本身没什么大的特殊,但其优势在于,方案经过了大量原厂和客户的稳定测试,是其他款产品难以替代的。 此外 Exadata专门为其flash disk 写了不少的特性。

如"write back flash cache",  我们知道以前的exadata开始用flashdisk,主要是作Smart flash cache用,原则上是认为flash disk要比其他SATA/SAS盘更快。
而这个wbfc的特性,则是将flash层级的数据读写,同网卡速度相比了,换言之,就是将瓶颈本身又从硬盘读写速度 提升到infiniband网卡传输的速度层级。
http://www.oracle.com/technetwor ... -flash-2179184.html

这些特性,第三方的SSD产品没办法应用。 换句话说,尝试自己搭建Exadata架构是没意义的,倒不如说,搭建一个可靠的RAC+SSD的环境更为合理些,有很多这样的成熟方案可以参考, 作为一款SSD产品完全可以在这些已有的方案上得到客户的验证。以得突破。






3,  使用PCIE SSD来保存我们公司的关键数据足够安全吗?

安全不依赖于具体的产品,而是要靠整体的解决方案。
我们的数据安全依靠什么? 成熟的访问控制,冗余方案,备份策略, 容灾需求。


不能本末倒置,与其这么看  不如说SSD在整体方案中能否立身。
我认为是可行的,特别是在冗余,备份这一块,

冗余可以保证多路读写的瓶颈不出在SSD这一边, 而备份的话,可以提升备份的写速度(其实如果较长的连续读写,提升效果不大)

一款SSD产品完全可以在这些方案中提出自己的意见,然后立足。





4, 通常都是使用什么工具来评测PCIE SSD? 测试PCIE SSD应该关注哪些数据?
目前来讲,也就是看看读写io, 跑跑benchmark之类。
如前面第一问提到的, 对于不同的应用场景,可能我们要关心的不同, 有些要关心随机读, 有些要关心随机写。
要做一些压力测试,看在不同的环境当中SSD io是否会受影响。
也要做兼容性测试, 这个客观地讲,就要看SSD厂商的实力。  大厂的话会有大量的兼容/最佳实践文档,兼容os, db, app之类的都会有较好地文档参考。 如果是小厂的话,可以聚焦在linux/windows平台上,针对特定客户调优,慢慢积累一些best practise,

论坛徽章:
2
午马
日期:2015-01-27 11:22:392015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2014-05-15 00:46 |显示全部楼层
本帖最后由 to407 于 2014-05-15 15:13 编辑

回复 42# 2009532140


    日志的话

    高速的online  log 完全可以用ssd,
               如果使用ASM的话,注意不要重复配置冗余, 建议配置preferred read failgroup。 这种情况下小的随机读写,性能提升较大。

   如果是archivelog , 就没有这么紧的需求了, 配RAID,普通存储 读写速度快一点 一般不会有大问题, 当然如果容量特别大,就要避免使用RAID5


  

论坛徽章:
2
午马
日期:2015-01-27 11:22:392015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2014-05-15 00:52 |显示全部楼层
回复 16# 2009532140


    趋势 可以有很多, 但并不一定会来。

    至少几年内,取代传统硬盘的可能性不大。 想想 我们现在连磁带都没有消灭。

    硬盘越搞越块, 对应的SSD损坏后修复的成本更高,风险更高, 同时没有大企业敢过分依赖新存储。 基本上丢数据的公司,大多都在排队关门了。

     比如oracle的客户, 他们很清醒地明白, 就像ASM,本身就是给传统硬盘写的,你用了新的SSD,没有性能提升,没有额外的可靠性保障, 就不会有什么摧枯拉朽式的变革。
   

论坛徽章:
12
CU大牛徽章
日期:2013-09-18 15:20:4815-16赛季CBA联赛之同曦
日期:2016-02-01 20:28:25IT运维版块每日发帖之星
日期:2015-11-10 06:20:00操作系统版块每日发帖之星
日期:2015-10-28 06:20:002015亚冠之塔什干棉农
日期:2015-06-04 11:41:56丑牛
日期:2014-05-10 16:11:33技术图书徽章
日期:2013-09-23 13:25:58CU大牛徽章
日期:2013-09-18 15:21:17CU大牛徽章
日期:2013-09-18 15:21:12CU大牛徽章
日期:2013-09-18 15:21:06CU大牛徽章
日期:2013-09-18 15:20:58数据库技术版块每日发帖之星
日期:2016-02-08 06:20:00
发表于 2014-05-15 13:08 |显示全部楼层
to407 发表于 2014-05-15 00:43
像redo log这些需要大量随机读的

redo log是随机读的?Oracle要哭了......
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,8.5折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时8.5折扣期:2019年9月30日前


----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP