有奖讨论：DB2多分区系统如何决定分区数量

wolfop

我笨故我在 发表于 2012-4-17 15:09
如果io-intensive操作是非co-location的那么带来的问题会很大，如果跨LPAR系统比较大的，那么这种情况下远不 ...

这个是所有MPP架构数据库无法避免的问题。最后看到没有办法的办法就是一个表复制多份，不同的分区键，或者在用非分区键关联的时候再导入导出成在分区键关联。

wolfop

我笨故我在 发表于 2012-4-17 14:35
是否实现co-localtion，与数据规模无关，只与应用复杂度有关。
核心常用功能实现co-localtion DPF就是有效 ...

怎么做？DB2又没有ASM那种能东西，实现IO性能而不仅仅是容量的在线扩展。
GPFS我并不清楚是否在新增加LUN的时候会自动rebalance，似乎不行。
3PAR/XIV吧，局限在单个存储内部，容量超过单个存储怎么办？而且3PAR还有条带过大的缺陷。

wolfop

我笨故我在 发表于 2012-4-17 09:57
DPF中只有co-localtion和local bypass（分析系统中很少）才能提升性能，这不取决于DPF本身而是数据库和应 ...

local bypass根本不现实。除非应用做得非常非常仔细，而且功能极其简单。
这也导致了IBM明确定位db2 企业版本不再有DPF功能，DPF功能变成infosphere专有的。
而且一般OLTP系统都是更加关键任务的，要求计划外停机更少，MPP架构随便一个节点DOWN就要做HA切换，切换时间还不短。最后OLTP还是要走回到DB2 for ZOS，RAC那样的share disk架构，IBM才做purescale。
做olap用DPF还有一个很重要的作用，不是谁都买得起P795，也不是谁的数据量也计算量都是一台X3860M4能处理的。

我笨故我在

wolfop 发表于 2012-4-17 17:07
这个是所有MPP架构数据库无法避免的问题。最后看到没有办法的办法就是一个表复制多份，不同的分区键，或者 ...

呵呵 一个表复制多份是对小表，避免broadcat
对关键大表动辄几十G，几百G的大表不可能挨个复制吧

我笨故我在

wolfop 发表于 2012-4-17 17:10
怎么做？DB2又没有ASM那种能东西，实现IO性能而不仅仅是容量的在线扩展。
GPFS我并不清楚是否在新增加LU ...

这是数据库设计问题不但是硬件功能问题，设计开始时即要考虑如果扩展：
1 冷然数据区分
2 新增RAID-新的tablespace存储相应数据
3 现有存储RAID的扩展：新增-》迁移-》删除 数据迁移方法：lv mirror，tablespce container。。。

方法很多，只要我们真的想做。如果不想做随便找一个理由就可以了

我笨故我在

wolfop 发表于 2012-4-17 17:27
local bypass根本不现实。除非应用做得非常非常仔细，而且功能极其简单。
这也导致了IBM明确定位db2 企业 ...

local bypass的要求前面都说过很多次了，要求是比较高，只有在OLTP中才有这么强的要求。
大规模OLTP导致一台设备不能支撑（优先scale out）时才考虑DPF,这种需求本身就很少.典型案例：银联，TPCC（极端优化，需要漂亮的成绩，与一般生产环境差异较大，仅借鉴其理念）
之前也说过DPF在一台设备不能支撑，需要使用多台设备的时候是使用DPF的最好理由
前面反复说的技术理论是让大家明白：不是做了DPF就能提升性能，如果使用不当硬件加了也是白瞎。正确的理解和使用才是王道。DPF与高性能不能化等号

wolfop

我笨故我在 发表于 2012-4-17 18:09
呵呵 一个表复制多份是对小表，避免broadcat
对关键大表动辄几十G，几百G的大表不可能挨个复制吧

错了，小表是做replicate。
大表的确是按照原样复制多一份，用不同的分区键。很多生产系统这么做，没办法的办法。
比如电信行业的话单表，如果关联是主叫号码和被叫号码。

wolfop

我笨故我在 发表于 2012-4-17 18:18
这是数据库设计问题不但是硬件功能问题，设计开始时即要考虑如果扩展：
1 冷然数据区分
2 新增RAID-新的 ...

你的这些都不是自动的，都需要很复杂的设计和手工处理。
最后就是一个可能性和现实性的问题。最后结果就是不具备可操作性。我看到任何一个数据库，在初期设计也许还按照了均衡设计方法论来考虑设计和实施，等到扩容的时候，谁还管得了那么多。能做点基于存储的热点数据搬迁就不错了。
就象DB2 DPF的的HA，均衡式分担HA理论上看起来最好，最后都不具备可行性，结果连ISAS都是用专门的冷备节点。

wolfop

我笨故我在 发表于 2012-4-17 18:33
local bypass的要求前面都说过很多次了，要求是比较高，只有在OLTP中才有这么强的要求。
大规模OLTP导致 ...

银联的核心OLTP是否用了DPF我不知道，但是TPCC那个就别逗了。三台64 CORE的780测出一个1000万TPMC，属于搞笑，每台只有330万？
local by pass要求操作的所有记录在本节点，你的应用能分么？DPF可是靠hash key来分布的，你怎么保证事务操作的所有记录在本地？也是一个只存在理论性，根本不存在现实性的方案。
理论就不用探讨了，如果LOCAL BY PASS管用，IBM也不会要做purescale。
最后的结论必然就是DPF不可能做什么OLTP的SCALE out。

我笨故我在

local bypass也没有大家想象的那么可怕和复杂。
取得hash值和partition map就知道了是哪个分区，平衡考虑一下其他应用，相关表用同样的hash值。
OLTP中可以与OLAP相反考虑low cardinality的字段做hash，如部门，子公司。。实现local bypass反而相对简单
系统在scale out完成后剩下的也是功能比较一的子系统了考虑相对简单，不过绝大多数系统scale out之后硬件就不是瓶颈或者再对硬件scale up之后就没问题了，这种情况下就没必要非要自己锻炼技术使用DPF了