对于数据库服务器来讲,是不是所有的磁盘都适合放在闪存上? Redo日志盘,数据盘,仲裁盘等。Redo盘适合么?如果用软件定义的方式,那么将闪存和一般存储共享的方式利用,一方面可以平衡性能的差异,节省存储成本的投入。另外一方面,是不是所有的应用都适合呢?会不会有负面的影响呢?
以善用资源的原则下,其实只要空间足够,可以先将性能好的存储资源充分利用。资源闲着也是闲着,不用也浪费。
但在资源有限的情况下,需要考虑扩容或另行采购的情况下,就要考虑钱的问题和整体性能的问题了,自动分层技术也好,数据人为分类也好,最好有科学的依据进行高低性能资源的搭配,以达到整体系统性能最优。
收起个人认为,主要有几个方面的考量因素,供参考:
1. SSD适应场景。SSD最适合随机读场景,OLTP类应用最适合不过;顺序对写场景不是SSD的强项,比如OLAP等分析类应用,大量的顺序读写并没有优势;Oracle的redo是一种特殊的类型,属于100%写操作,理论上不适合用SSD,但是SSD相对于机械硬盘的响应时间有明显优势,因此redo可以选择SSD,解决Oracle redo瓶颈问题。
2. 成本。核心问题是性价比,如果是土豪,全部采用SSD也无妨
3. 管理。灾备功能等高级功能,不论是AFA还是存储的软件定义存储(scale io等)都不够完善
收起这个问题比较开放,什么是正确的存储空间?什么是正确的数据?
首先得确定数据的架构,数据的生命周期,数据的使用标准。
其次是确定存储的服务目录。根据数据的架构要求,结合服务目录,来确定闪存的使用环境。
最后是通过一些监控或管理手段,确保数据的存储使用符合设计初衷。
有一种比较偷懒的作法,就是配置存储资源池,把分配机制交给自动分层去完成,不管是什么性质的数据,都遵循数据分层的规律,热点数据移动到闪存层。当然,这样的初始分配有点笼统。
针对这个问题,如果有条件,redo盘和数据最好放在闪存上,但如果这两者放在闪存上,还要考虑到存储规划的问题,如果不通过虚拟化网关统一管理,如果配置两种或两种以上存储,会加大管理难度,多路径软件等也不好统一,所以也最好一致。
至于规划成虚拟资源池统一管理,很多时候闪存自带的特性就发挥不出来了。
收起Redo,Active 都不适合放在闪存盘上。这个数据库厂家的官方测试有明确的记载。其实闪存更适合随机读写比率很高的应用场合,对于其他特点读写的应用,其实没那么大吸引力。
别人用了不该用的方式,就证明这种方式是正确的,这个逻辑不合理。
如果把错误的应用放在了闪存上,有可能造成性能的底下。
收起传统关系型数据库(非分布式数据库),我个人认为这些数据文件均可以放置在闪存阵列上。只要闪存阵列稳定可靠,它的随机读写,顺序读写的能力都能超越传统机械磁盘存储,为何不能应用呢?
您提到了软件定义,狭隘的说,把通用x86硬件加上万兆以上的网络连接加上分布式文件系统,搭建的软件定义存储,这种架构我个人认为闪存的角色并不是直接存取I/O,这种架构的性能主要由这种分布式架构来体现。目前通常在非结构化数据的查询方面表现比较好。
广义的说,存储虚拟化范畴也能算作软件定义,那么通过这种存储虚拟化网关,将异构存储和闪存阵列统筹管理,加之自动分层功能,将热点数据迁移到闪存阵列,提高I/O性能。目前这种架构对现阶段很多IT场景的改动都较少,适用的场景也比较多。
收起