资源供给：IO子系统之六

       这个时候谈IO子系统，就不能不谈SSD，否则都没法生存了。可惜个人在ssd没有什么实践经验，甚至在知识上也非常欠缺。这里只能对于ssd的一些简单认识说些自己的看法，里面必然会有很多的缪论。这里要特别感谢@jametong的帮助，帮我理清了东西。
    
      为什么需要ssd，当然是磁盘系统不够让人满意，磁盘系统的顺序IO速度足够快，其问题主要在于机械设备导致的寻道和延迟。ssd作为数字电子设备，消除了机械设备的寻道和延迟，使其随机读的能力大幅度增强，即使具有非永久性存储介质的限制，也被业界开始大面积使用。

     从性能的角度出发，ssd，个人感觉要比较磁盘复杂，要获得一个优异的ssd性能，并不是把Oracle数据文件放到ssd上就可以的。
    下面的列表增加点感性认识，来自于新浪@明生78 刘明生的ppt：

     本文中不讲如何去选购SSD，而是在既定SSD的配置下的一些基本特性和变更。
     ssd的组织结构：
         page ==> PE Block ==> Plane ==> Die ==> Flash chip == > SSD Disk

       最小读写单元page，    page一般为4k或者8k，有设备决定
       最小擦除单元PE Block, 一般128page或者256 page，由设备决定
       控制操作单元plane,    每个plane同时只能有一个PE Block进行操作，一般有2048个PE Block
       plane是Die的组成单位，一般是两个。

      速度：
      目前的ONFI 2.0标准采用8bit位宽的133Mhz接口，单颗芯片带宽理论上可达到133MB/s。
      nand slc: 读取延迟：25us，写入延迟：250us 擦除延迟：2ms
    

      iops  达到几万甚至10几万，这是机械磁盘所无法想象的。
      至于吞吐量则可以说受限于主机接口。
     
     不同于机械磁盘，ssd在快速发展，其iops和吞吐量可能一年一变样。

      ssd不同于机械磁盘设备可以实现本地更新，由于其NAND特性无法进行本地更新，如果需要原地更新必须执行Earse操作，也就是擦除，可以看到擦除操作的速度很慢，甚至已经达到了机械磁盘的速度。ssd的内容组织结构为随机组织结构，页和页之间没有任何关联。
      /*所以其随机读和连续读没有太大的差异，随机写和连续写也没有太大的差异。*/
     修订：
     Very fast sequential read (up to 40 MB per second per flash chip).

• Very fast random read performance (high number of IOPS).

• Write is very slow and is done on a page level (usually 64 pages in a block, and current page size is 4 KB).
• Sequential write performance is fast (about 20 MB per second per flash chip).
• Random write is very slow.

       以上说明来自于： Mark Moshayedi, Patrick Wilkison的Enterprise SSDs的发布，http://queue.acm.org/detail.cfm?id=1413263。
       40m的数字是来自于第一代的ssd，不要太在意。

     这里说的快速的顺序写和可怜的随机写有些难以理解：
     ssd的组织不同于磁盘的堆组织，来自于主机的顺序写，比如写1MB,128个8k块，在ssd上不一定表现为连续性存在，似乎无法支持顺序写快的结论。

     我们来简单的看看，主机的逻辑数据块地址和ssd的物理地址需要通过ftl转换，我们来看最理想的情况：
   
     1M数据完全落在一个PE Block中，似乎也需要每次一个page的进行program或者写，如果确实如此，除了在空闲空间的搜索节省了时间将和随机写没有任何区别。特别是ssd很有可能所谓顺序写1M会落在很多个不同的PE Block中，在这种方式下更加看不出来顺序写和随机写会有什么区别。
     如果考虑没有并发情况下随机写和顺序写：
    顺序写：1次性写了1M，共128个8k Database Block，假设 ssd page也为为8k，则为128个page.
    随机写：按照次序写128次8k的page。
    在以上两种方式中，随机写多出的操作在于：FTL需要进行128次的操作陆续放置到ssd的dram中，而顺序写相信的优化ftl可以一次性的完成128个page放置到ssd dram中。两者之间的区别应该在于顺序写情况下ftl更加具有工作效率，一次一次的写不可避免的会引进在中间的上下文转换问题，最关键的问题可能是在于FTL对于顺序写只做一次Log Structured,对于随机写当然每次随机io就得做一次。 如果这个关于ftl的说法正确，似乎可以支持顺序写比较随机写快很多的说法。但Log structured似乎是针对每个页的寻址，似乎和顺序写和随机写也没有多大关系呀。另外的区别可能是来自于ftl对于顺序io并行的支持，每个颗粒一般有4个以上plane，每个plane可以发布io命令，如果ftl同时把顺序io同时忘这些plane送，则可以表现出比较随机写更好的性能。

      ssd由于设备性质导致其无法进行本地更新，在更新的时候总是读取该page更新后写到一个新的页中，老的页就被标记为无效页。而这个无效页要被重新使用必须进行擦除。为了提高擦除效率，擦除是基于PE Block进行的。
    
      从性能的角度考虑，我们可以认为earse为一种交换，体现为空闲空间不足的一种反应。earse操作不可避免，我们需要做的是尽可能使其对于前台业务操作不可见，也就是说在业务发起写操作的时候，让他总有空闲空间可用。降低影响业务写入
   
     当总是有空闲空间可用的情况下，ssd不会产生earse操作，也就是说我们需要给ssd磁盘足够的预留空间，或者可以认为ssd磁盘本身的缓存。
     即使预留再多的空间，随着写操作的不断进行总是会被写满，空闲空间将越来越少。

     为了保持性能，我们需要稳定的空闲空间，这个就需要依赖于gc清理来完成，也就是垃圾回收。
    可以看到，只要垃圾回收具有足够的效率，业务进程总能找到空闲空间，使业务进程避免擦除操作，避免擦除操作给业务带来的巨大性能冲击。

    SSD作为磁盘如何作用在数据库中：
   Online redo Log：如果是一个优秀的设计，Online Redo Log作用在独立的磁盘组上，SSD并不会带来多大的优势。遗憾的是很少有用户对于Online Redo Log采用独立磁盘组，而是和数据卷进行混合存放，导致Online Redo Log效率很差。从原理上讲，SSD不适合作为Online Redo Log的替代，采用独立的磁盘卷会更好。如果一定要放置在Online Redo Log之上，则需要保证以下两点：
   （1）、 足够的预留空间保证在Active期间不会产生擦除操作。
   （2）、在非Active期间对于Online Redo Log手工进行擦除。

    Undo Tablespace:
    /*Undo Tablespace是数据库中更新最为频繁的表空间之一，同时也是随机读相当频繁的表空间。足够的随机读可以使Undo Tablespace作为SSD的候选表空间，不过大量的随机写对于ssd是个考验。*/
     修订：
     Undo Tablespace是数据库中更新最为频繁的表空间之一，主要IO特征为随机读和顺序写。在Oracle buffer cache相对充分的情况下，绝大部分随机读都会被缓存在Buffer cache中，更新到磁盘的数据很少会被访问到。虽然在IO特征上以读为主，但是SSD Flash可以带来多大的收益还是有待考证。顺序写的IO ssd disk并不会带来多大优势。

    数据表空间：
    ssd适合大量的随机读和少量写的数据文件，大部分业务表空间都适合这种方案。

    日志类数据：
    日志类数据，比如电信的详单、实时话费等数据基本都更新一次，后续基本是读。会使一个比较好的ssd选择方案。

    事实上对于Oracle数据库而言，大部分情况下是不存在顺序写的，基本是随机写，也就是说即使进行擦除操作，进行了大规模的写放大，一般来说也会比较磁盘带来很大的性能提升。从这点上考虑而言，只有那些顺序写的设备对于是否采用ssd替代是需要考虑的，其他都可以采用ssd替代。
    Oracle数据库典型的顺序读写：
    Online Redo Log,Archive Log,Temporary Tablespace等等。
    顺序写：
    undo tablespace以及部分持续更新的Segment。
   事实上对于日志入库型表格虽然是顺序写也是ssd的良好候选之一，因为这些表格从来不进行更新。在足够Oracle buffer缓冲的前提下，基本可以保证很少进行更新写。

    FlashCache:
    相对于ssd用作磁盘，可能把ssd作为磁盘的缓存会是一种更好的选择，具有成本低廉，性能良好，通用性的特点。
    特别是Oracle自身，在Oracle Linux和Sun Solaries都提供了天然flashcache支持，使用户很方便就可以利用ssd完成性能改善。

   从我个人来说，比较推崇flashcache方案，或者说整体采用flashcache+个别的flashdisk。

   flashcache的wt和wb

   Oracle推荐是使用wt模式，主要是基于Oracle的一致化考虑，Oracle数据库的任何不一致都将会导致数据库无法打开，并不是简单的丢数据的问题。基于这个考虑能用wt就用wt吧，个别对于写很敏感的业务，可以加载ssd disk来避免wt所带来不良影响。

   wb方式具有最好的性能，换句话说，wb方式事实上等同于磁盘阵列的Cache。为什么Oracle可以认为写到磁盘阵列的cache就认为是写到磁盘上，而不认为写到flash disk上就写到磁盘上呢？估计是一下两个因素造成的：
   （1）、比较内存，flash chip更加容易损坏。
   （2）、flashcache体系可能还没有足够高的可靠性。

   对照磁盘阵列的体系，事实上也就是说flashcache的wb并非是不可用，而是目前的体系结构Oracle认为无法达到而已。采用wb模式，还要处理一些Oracle direct write的问题。不过对于temporary tablespace上的direct write还是建议wb模式，不同于内存结构，flashcache模式可以配置巨大的容量作为缓存，排序造成的干扰不会很大。排序造成干扰的最大问题是trim问题，如果不支持trim，在ssd disk上排序可能会造成很大的问题。
    只有实践才有话语权，flashcache的体系需要进一步实践和完善，我们将进行这方面的内部实践。

    另外关于混合读写负载的讨论，前面所讲很多是大量读少量写，或者大量写的负载特征。对于混合负载特征SSD会表现出什么特征呢？

    比如50%的读和50%的写。

    个人分析感觉混合读写是会带来比较大的问题的，主要的问题就来源于ssd随机读和随机写10倍左右的差距。

    每个plane每个时刻仅仅允许一个操作进行，大家想象一下当在执行写操作的时候，这个时候会涌进来大量的读IO，而这些读IO会被写IO堆积迅速的把ssd的dram充满，从而达到其性能拐点。也就是读会写阻塞，使读也降低到写的性能，甚至会更差（达到负载压力之后性能会迅速变差）。
    这个只是个猜测，但个人感觉具有一定的道理。也许ssd对于混合负载并不是十分的合适。
    

    对于Oracle数据库来说，另外一个大问题就是Drop,Truncate以及Temporary Segment的问题。
   Oracle是否可以让ssd知道发生了Drop操作，否则由于Drop等操作仅仅执行了元数据更新，ssd中依然把被drop的Segment作为有效数据，这样有可能会大幅度降低写性能，降低ssd的寿命。
   对于Undo Tablespace在某种程度上也存在同样问题，Undo Segment是一个循环使用的队列，频繁的更新会导致SSD不断的消耗空闲空间，相对的成本会比较其他数据表空间为大，结合上面描述的 Undo Tablespace的特性，undo tablespace是否适合作为ssd存储有些疑问。不过大量的搜索发现，他们都建议undo tablespace放置在ssd上，我估计很有可能都是些ssd应用早期的说法，从现在来说不一定正确。
    对于create tablespace和create datafile的疑问。

    create tablespace和create datafile都会进行数据块的格式化，这些格式化必然会在ssd磁盘上表现为已经使用的page。
   当在这些空闲的表空间上增加数据，就会导致在ssd上分配新的页面来存储这些变化。总感觉有些问题，就是空间的双倍浪费，尤其是在数据快速加载的时候。

    ssd对于我来说是个新课题，啰嗦了这么多，应该还有很多没有涉及。比如作为ssd核心ftl，也许那个东西需要专门阅读相关书籍。
      
   

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-777274/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-777274/