5 Tungsten

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

跳至解决方案

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

0 项奖励
1 解答

已接受的解答
4 Beryllium

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

跳至解决方案

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

在原帖中查看解决方案

0 项奖励
5 回复数
4 Beryllium

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

跳至解决方案

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

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

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

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

5 Tungsten

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

跳至解决方案

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

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

0 项奖励
4 Beryllium

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

跳至解决方案

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

在原帖中查看解决方案

0 项奖励
5 Tungsten

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

跳至解决方案

谢谢 前辈

0 项奖励
3 Silver

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

跳至解决方案

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

0 项奖励