可扩展数据架构浅析

上篇讲了一点用mysql架构saas数据库的观点，主要是节点向外扩展的思路，这篇再叨叨一下，主要是针对数据库存储再加以说明，现在大多数解决方案还是停留在类似阿里的解决方案上，弱化企业的逻辑流程，saas现在还是停留在共性化很强的中小企业应用上，我想saas再发展，她会慢慢的过渡到相对比较复杂的企业应用。所以做系统有一点就非常的重要，可扩展性，这个词在做并行计算系统和分布式系统的时候，是最重要的衡量参数。
可扩展不只是tenant可扩展，还要有其他可扩展，这里有这样几个概念：
第一：界面可扩展；
这个很容易理解，用户菜单可以定义，这个一般是程序实现和数据库的关系不是很大，如果按照面向界面编程的思路进行下去的话，这个非常简单，在面向界面编程的时候再说明清楚。
第二：功能可扩展；
这个主要是soa的思想和跨界迁移，理解起来也不是很复杂，核心是uddi。
第三：数据表结构可扩展；
数据表结构可扩展，很多人认为就自定义字段，这个只是表段扩展的初级阶，为什么呢？因为一个信息的属性到底有多少，开发人员是不可预测的，动态改变数据表结构是一作个非常危险的动，现在很多架构师提出来应该是独享表结构而共享数据库，但是你可以想象，举例：一个租户的两个用户，a用户insert数据，b 用户在alter表结构，这是一个高风险度的操作。所以建议不要这样做，而是采用视图进行行列装换的策略，这个应用最好的算是facebook，给每个被扩展的数据表，建立扩展数据表，表结构如果下：
被扩展数据表A

primaryid name
1 测试1

这个数据表很容易理解，就是信息的基础数据表，比如name。
数据表A的扩展记录表
A_extend

primaryid field
type length descript ......
1 number int 10 数量
2 addtime date 上架时间

这个数据表和基础数据表应该是一一对应的关系，记录扩展信息，简单的应用就是上边的这种，复杂的应用比如产品可能根据不同的分类所扩展的还有所不一样，这个数据表中就可以进行处理。
数据表A的扩展数据表
A_extend_data

Aid field int varchar date ......
1 number 1234
1 addtime 17:49:22

这个数据表是该思路的核心，列是field和数据类型的集合，一条扩展信息，根据属性划分成多行，这样避免数据表结构的更改，但是又有一个新的问题就是在这些扩展属性上进行检索的时候就非常困难，下边的视图解决这个问题。这里还有一个问题就是：为什么不设计成一个混合类型的字段，那样不是更加简单吗？还要按照类型进行分开存储，实际上每行只有一个存储有效单元，其他都是null，这个主要是为了提供更多的检索条件，因为数字123和字符123存储显然不一样的，数字123可以用>比较符，而字符123则是无意义的。同理在该表上建立的视图也就有清晰的类型，和应用系统中的类型相匹配，而不在需要转换。当然你的应用系统如果是php这样的弱类型语言，那就多余了。
在A_extend_data创建视图A_extend_data_view

primaryid number addtime
1 1234 17:49:22
2 2342 17:49:25

视图，这个就很清晰了，检索的时候也很方便，和一般的数据表检索是没有什么两样，在创建视图的时候，用一个存储过程，进行行列转换。
就大概说下，有兴趣的可以再进一步交流。

http://blog.csdn.net/netbug2009/archive/2010/03/04/5345012.aspx