《元数据驱动的 SaaS 架构与背后的技术思考》分析笔记

《元数据驱动的 SaaS 架构与背后的技术思考》分析笔记

1、

由于系统标准模型和用户模型均为物理模型,未有做系统标准和自定义数据的有效隔离,如何保证平台应用的每一次升级必然会考虑对现有用户自定义模型的稳定性和可用性的影响,在自定义物理模型的情况下,不仅挑战巨大,而且包含巨大的回归验证的工作量,很难收敛。

2、

Object 系统表存储了每个租户为它的扩展应用对象定义的元数据,包含如下核心字段:OrgID:应用对象所归属的租户 ID,用于统一共享数据库内的多租户数据隔离,通常和租户定义的域名对应。

目前我们的元数据对象表中只有系统ID,没有租户ID。以后可以考虑去掉系统ID,增加租户ID。系统ID可以增加一个功能来选用对象。
3、

Value0....Value500:用于存放对象实例字段的数据,其 ValueX 中 X 值对应到 Fields 表中 FieldNum 定义,ValueX 存放的数据,不管原始数据类型、存储格式均为变长字符串格式。

我们用实际的物理表存储数据,这个使用统一的一个表,存储所有租户、所有表的数据。这样的好处就是元数据驱动开发,不好的一点是从数据库查表不能一眼知道字段存储的数据在哪里。
4、

FieldID 格式为字段定义的标识 ID,用于区分每个字段定义,对于标准字段,则采用标准字段 ID,如 Name,则直接采用 Name 作为字段标识 ID,对于自定义字段,则元数据引擎自动生成 15 位的标准格式的 FieldID。其他字段定义请参考前面的 Fields 元数据表详细介绍。
17b643407e4a4425b45dedb2ccfa3175.png

如图所示,自定义字段为15位不可识别的字段。这是与我们平时建表不同的地方。
5、

所以解决办法就是建立另外的透视表叫做 Indexes 索引表,并把数据拷贝出数据表并转换成原始的的数据类型,并存储到Indexes索引表列内,如原来是整形的数据以可变字符串的格式存储 在ValueX 列中,拷贝到 Indexes 表之前通过函数将其转换为原始的数据类型,在存储到 Indexes 对应的 NumValue 列内,以方便建立索引,Indexes 表包含强类型的索引类,像 StringValue,NumValue,DataValue,用来定位对应数据类型的字段数据

值得借鉴学习。
6、

当用户修改了一个表字段列的数据结构,从一种数据类型改成另外一种不同存储格式的数据类型时候,系统会重新分派一个新的弹性列给到这个字段列的数据,将数据从原来的存储弹性列批量拷贝到新的弹性列,然后才会更新此字段列的元数据,暨在 Fields 表中更新这个字段列的元数据,将数据类型更改为新的数据类型,并将 FieldNum 更新为新的 ValueX 列对应的X值。
同时,在如上对用户逻辑表结构调整生效过程中,原来的数据结构和对应的数据访问正常进行,直到逻辑表结构变更生效,对应用系统可用性不会造成影响,用户对此无感知。

牛逼PLUS。无感的对象结构变更(No DDL)

原文链接:https://developer.aliyun.com/article/781157

# 元数据 

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×