PCIE SSD对数据库架构的影响巨大？参与讨论得派克金笔！（获奖名单已公布-2014-6-27）

goallist

建议直接把数据放上去，缓冲不是个好方案。

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

2009532140

回复 41# goallist


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

goallist

恰恰相反，对MySQL来说，log是高性能下得瓶颈点，把log放在高速存储设备上有助于性能的提高。
回复 42# 2009532140


   

2009532140

回复 43# goallist


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

ylky_2000

没有用过ssd，有台笔记本配了ssd固态硬盘，但是不知道有什么作用。。

manULinux

路过，lollollol

to407

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，

to407

回复 42# 2009532140


    日志的话

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

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


  

to407

回复 16# 2009532140


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

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

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

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

mike79

to407 发表于 2014-05-15 00:43
像redo log这些需要大量随机读的

redo log是随机读的？Oracle要哭了......