底层打散的 hypervolume是否有利于数据库的rebalance

[liulei_it]

     目前拜读了oracle与DB2 在EMC的一些文档，发现datafile或者容器的 rebalance 和  hypervolume 有着巧妙地关系。如果 hypervolume是比较好的打散的话，那么当这些datafile或者容器之间成员需要进行balance的时候可以看成存储级别上元数据的交换，而不真正的数据文件或者容器之间物理上的rebalance了。不知各位大牛们怎么看？

[o17Uu33DCF12520]

高端存储用来支持数据库是很典型的应用案例。

数据库层面的datafile和tablespace（也就是“容器”）完全是逻辑定义的，在这一层面向下直到物理磁盘层，中间往往还有人为定义的许多层。例如：OS上的逻辑卷->卷组->物理卷，存储上的hypervolume 或者LUN->RAID->物理磁盘。

补充说明的就是： 1. OS上也可以直接用裸设备 2. 物理卷也很可能是通过多路径软件映射到主机HBA的，而且还可能既有本地磁盘也可能有来自不同整列的。

在这样的架构下，数据库上的datafile和tablespace这一层面是不会发生物理上的rebalance的。最终的物理磁盘的rebalance做的好不好要看这中间的这些层定义的够不够balance了。

[liulei_it]

谢谢前辈的见解，如果正如您所说的那样，那些个看起来还在OS上能看到的datafile与真正物理上的相去甚远啦。

如果这样的话，在划分数据库的时候，stripe to stripe 还有必要吗？

[o17Uu33DCF12520 · Accepted solution]

stripe这个东西每家厂商都会在自己的产品中提供实现方式，不管是逻辑实现还是物理实现。可以在数据库、主机、存储等层面上都能实现。我的理解是没有必要在每一层上都去做，只需要把这每一层都布局合理，在底层实现stripe就可以了，毕竟真正的数据操作还是在底层进行的。 透过现象就能看到本质了。

[liulei_it]

谢谢 前辈

[chrsi_wang]

对头，从数据库到存储disk，很多层级可以设置balance的机制。具体如何优化，还要具体情况具体应用具体分析。