可扩展数据架构浅析

上篇讲了一点用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

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