道冲而用之，或不利，深如万物之宗。

-老子

引言

作为业务系统技术开发学生，面对现在：

首先要快速搭建业务渠道，让线上业务跑起来，快速试错，解决生存问题；第二步，在环节顺畅、业务基本跑通的基础上，解决快速增长的问题。第三步，在完成配套业务快速增长的基础上，需要进行精细化升级。通过在支撑业务快速运行过程中挤时间打磨系统功能和体验，需要时间抽象能力，沉淀产品，提升效率；同时也要面向未来，如何在抽象能力和沉淀产品的基础上，快速输出所承载和沉淀的商业能力，贡献给整个行业，或者为整个社会商业生态提供一个基地支撑。面向未来，将平台产品升级为SaaS，真正开放能力，是我们提前布局的核心方向。

将平台产品进行SaaS输出，需要解决,那些和问题呢？在这里试图列出核心问题：

如何根据不同的用户需求按需调度和分配计算能力？(IaaS/PaaS)如何满足用户数据安全需求，严格隔离不同用户的数据，让用户只能看到自己的数据？(PaaS)如何支持不同用户在标准数据对象/数据模型上添加定制的数据对象/扩展模型？(PaaSSaaS)如何根据不同用户按需组合功能，满足从基础到专业级不同业务场景下不同用户的需求？(SaaS)如何在不影响用户现有数据和功能的情况下，统一升级平台产品？(IaaS、PaaS、SaaS)从以上问题可以看出，产品面向SaaS输出的关键是如何通过标准的扩展能力，根据不同用户的需求有效定制计算能力、数据、安全和功能，支持多用户的共性和个性问题，即多租户问题，这也涉及到计费、服务水平等相关问题。先说解决以上问题的关键和思路：

第一个计算问题的核心是调度问题。灵活计算在IaaS级别提供统一的计算调度能力，而无服务器可以在PaaS级别提供更高级别的计算调度能力。第四个问题的核心是业务流程的抽象和业务功能的分离。领域驱动的设计和服务(微服务)在平台功能的抽象分离上提供了相对成熟的思路，催化了基于垂直业务功能细分的服务方案和组织架构。主要诉求是根据需要快速灵活地组合细分的业务功能和服务，从而支持不同的业务模型，提供业务敏捷性，支持业务创新和变革。当然，另一方面，由于垂直的功能细分，业务功能域数量增加，整个业务链条上的咬合力点越来越多，会导致越来越多的冗余或缺失数据源，功能出现重叠和发散，或者缺失，最终会给整个业务带来更多的数据和功能不一致风险。这样不仅横向端到端的服务串联成本高，关键路径的风险收敛成本也比较高，冲突点集中在各个垂直领域的功能和数据的交汇处，具体表现为：

数据上：

无业主数据，有数据需求又无业主；大量重复和不一致的数据；功能上：

部分业务功能缺失；域之间存在重复的业务功能和不一致的行为。这个问题没有标准答案，更谈不上最佳答案，无论是纵向划分领域，还是横向拉平商业模式。只有根据不同的业务发展阶段及时动态调整试错，换言之，这是一个不断寻找相对最优解的动态过程。

弹性计算和无服务器解决了计算能力的问题，域驱动的服务设计解决了功能拆分和按需组合的问题，那么剩下的核心问题就是数据：如何使用统一的数据架构来支持多租户的数据安全需求和通用数据存储，以及用户自定义的数据对象定义和模型变化，同时保证数据定义级别的扩展和变化不会影响自身和其他租户的业务功能可用性。我们来分析一下可能的解决方案(暂时不考虑按服务边界进行数据库拆分):

统一数据库、标准数据模型、扩展数据模型直接映射到物理表和索引：显然无法支持不同租户定制的数据对象和数据模型的需求，物理数据模型之间会相互干扰、相互冲突，直至难以为继。即使对于所有租户完全标准的功能和数据存储，平台本身的标准模型升级的DDL也会对用户的易用性造成很大影响，所以显然不可行。如果为每个租户创建一个单独的数据库会怎么样？每个租户都有自己的数据库，可以满足用户数据安全和隔离的需求，也可以满足每个租户的自定义数据需求。这似乎是一个合理的SaaS数据解决方案。但是，仔细分析后，我们会发现两个明显的问题：如果用户需要修改或扩展现有的物理数据模型，DDL操作必然会影响在线服务的整体可用性，还可能影响标准数据模型，从而影响在线功能的使用。如果用户可以自己对物理模型进行扩展和定制，那么当平台对模型进行升级时，就非常容易与物理模型发生冲突，导致新旧之间功能异常。由于用户在各自的数据库中有自己定义的扩展和定制，平台数据模型和功能升级需要针对不同的租户分别进行验证，升级验证存在很大的工作量和风险。以上两种方案可行性较低，我们从中发现的问题是平台业务系统逻辑模型到物理模型的直接映射是造成问题的主要因素。既然物理模型的变化是平台不稳定的原因，那么是否可以尝试通过解耦业务逻辑模型和物理模型的映射关系来解决这个问题？

现在问题已经明确了，怎么解决？通常，其中一个& quot万能& quot解决架构问题的方法是添加。

加一个层次，我们也来套用一次，增加一个层次（元数据层）来解耦逻辑模型到物理模型强映射的问题。

首先，我们需要对业务进行建模，对业务进行抽象，定义出业务逻辑模型，然后对模型进行二次抽象，定义出逻辑模型的定义数据，实现业务模型的数据化，即模型的元数据(TheMetadataoftheLogicModel)，将模型结构存储为数据，而不是直接对应的物理存储结构。

其次根据定义出的元数据进行统一抽象，形成元数据逻辑模型。

将元数据逻辑模型映射到元数据物理模型，对应实际存储结构。

通过对业务模型的变更，形成对元数据层的数据变更，而不是物理结构的变更，从而实现业务逻辑模型同物理模型的解耦。

很多事情说起来好像挺简单，实际上是一个非常巨大的系统工程，将其付诸实践是挑战非常大的事情，而取得踏踏实实的成功则更难。上述问题的解题思路是Salesforce的解题思路，而且Salesforce不仅取得了成功，也接近将其做到了极致，下面我们站在巨人的肩膀上来看看Salesforce如何通过元数据驱动的架构（核心是基础数据架构）来支撑多租户的SaaS业务平台。
注意：由于Salesforce并未有对核心实现逻辑进行完全公开和说明，所以本文所整理的部分核心逻辑包含了作者的逻辑推理和解读，但是确实进行了逻辑验证和场景验证，如有纰漏和不全面的地方，欢迎讨论及指正。

元数据驱动的多租户架构

Salesforce将Force.com定义为PaaS平台，Force.com的基础就是元数据驱动的软件架构来支撑多租户应用。首先我来解释下什么是以元数据驱动的软件架构为核心。

一、多租户意味着什么

多租户的含义用一句话来描述就是：一个云平台，无数多个客户。

一个云平台的含义是：一个代码库，一个数据库，一整套共享的可扩展服务，包括数据服务、应用服务以及Web服务。

无数多个客户的含义是：每个客户都被分配一个唯一的租户OrgID，所有的数据存储都是按照租户OrgID隔离的，所有的数据访问必须包含OrgID，所有的操作也都是包含租户OrgID的，也就是所有的客户数据和行为都是被安全的通过唯一的租户Org进行严格隔离的。

每个租户/组织只能看到和定义按照自己租户OrgID隔离的自己版本的元数据和数据，而且只能执行自己租户OrgID所授权的行为，这样每个租户就拥有各自版本的SaaS方案。

二、元数据驱动意味着什么

元数据对于平台意味着平台数据的数据，对于租户意味着是关于租户数据的数据。

当用户定义一个新的用户表的时候，用户创建的不是数据库中的物理表，而是在系统态的元数据表中添加了一条记录，这个记录描述的是用户表的逻辑定义，是虚拟的，这个表并不在数据库中物理存在，而这条记录代表就是用户态的数据表。

当用户定义了用户表的一个新的字段时，用户并没有在物理表中创建物理字段，而是在系统态的元数据表中添加了一个记录，这个记录描述的用户表的字段组成的逻辑结构，是虚拟的，这个字段也不在数据库表结构中物理存在，而这条记录代表的就是用户态的用户表字段。

也就是通过存储在系统态的元数据表中的元数据记录作为虚拟用户的数据库结构。

三、元数据驱动的多租户整体架构

我们先来大概了解下元数据驱动的多租户的整体架构，整体架构大概分为5个逻辑层次：

底层数据架构分为三个层次：最底层是数据层，存储了离散的系统和用户的业务数据，业务日常运营的数据存储在这里。公共元数据层，存储了应用系统标准的对象和标准的字段定义，对底层数据的结构进行定义说明。租户特定元数据，存储了租户自动的对象和自定义的字段定义，用于对底层的数据结构进行定义说明。通用数据字典UDD(UniversalDataDictionary)运行引擎层实现了应用对象到底层数据存储的映射，包含对象模型操作、SOQL语言解析、查询优化，全文搜索等功能，我们常说的ORM功能也是其核心功能，但比其复杂的多。平台服务层提供PaaS层平台服务，提供应用对象模型的创建，权限模型创建，逻辑和工作流程创建以及用户界面的创建，包括屏幕布局、数据项、报表等。标准应用层提供端到端的标准的业务应用功能。租户虚拟应用层，用户可以在标准应用层或者平台服务层之上定义自己特有的业务应用功能，满足自己特定的业务场景需要。

其中，底层数据架构是最为关键的平台基石(TheCornerStone)，其核心运行引擎也是基于强大的底层数据架构基础上构建的。本文则以元数据驱动的多租户数据架构为核心来一一展开。

四、元数据驱动的多租户数据架构

下面我们具体来看下系统态的数据模型，基于Salesforce加上个人推理的元数据驱动的多租户数据模型。
注意：由于Salesforce并未有对核心逻辑进行完全公开和说明，所以本文所整理的部分核心模型包含了个人的逻辑推理和解读，但是确实进行了逻辑验证和场景验证，如有纰漏和不全面的地方，欢迎讨论及指正。

Salesforce云服务平台遵循的是面向对象的设计理念，所有的实体、实体关系以及实体的CRUD均是以对象的视角进行的，所以其元数据驱动的多租户数据模型的存储基本元素也是按照对象的颗粒度进行存储，源自于OO的对象间引用，同普通关系数据库主外键关系异曲同工，只是细节处理上不尽相同，请大家注意这一点。

1.元数据驱动的多租户数据架构概览

首先，我们先来大概了解下元数据驱动的多租户模型的核心内容，元数据驱动的多租户的数据模型主要分为三个部分：元数据表、数据表和功能透视表。

元数据表（MetadataTables）

元数据表用于存放系统标准对象以及用户自定义对象和字段定义的元数据，也就是系统和用户对象的逻辑结构，即对应于关系数据库中的虚拟表结构。元数据表主要包括Objects表以及Fields表，是系统标准对象和用户对象定义数据的仓库，即元数据仓库。

数据表（DataTables）

数据表用户存放系统以及用户对象和字段的实际数据，实际的用户业务数据以及应用系统相关数据存放在这里。数据表包括Data表和存放大文本数据的Clob表，数据表存储了绝大部分用户的实际数据，是一个巨大的用户业务数据仓库。

功能透视表（SpecializedPivotTables）

功能透视表包含了非常关键的关系表、索引表、关系表以及其他特定用途表。例如关系表定义了对象间的关系，索引表解决虚拟结构索引的问题，这部分后续将进行详尽的介绍。

2.元数据驱动的多租户数据架构详解

上一节粗略地描述了元数据驱动的多租户模型三大部分模型实体和基本作用，大家可能会比较疑惑，这么简单一个实体模型，怎么就起了这么个牛逼的名字，而且支撑了“一个云平台，无数个客户”。我们下面就对此模型的核心逻辑进行详细展开和推理说明，同时详细阐述以此模型为中心的服务来说明整个元数据层或者说UDD(UniversalDataDictionary)层的设计。

土话说：“没有对比，就没有伤害”。道理是相通的，用相似的事物进行对比是对理解客观事物比较好的方法，找出其相同点和共性的地方，找出其不同点和异样的地方，同时识别出是否有不可对比的方面。从各个方面去对比，则能更全面、更深入的了解客观事物。

下面我按照普通应用设计思路方式来定义一个简单直观的多租户SaaS数据架构方案示例，作为元数据驱动多租户数据架构方案的对比基准方案，用对比来更好的帮大家了解元数据驱动多租户数据模型及架构的设计逻辑。

普通多租户SaaS数据架构方案示例（仅做示例）

多租户基本思路：每个租户一个数据库，提供数据库级别的租户数据隔离，平台提供标准应用功能模型，用户可以在各自数据库内定义以及修改各自的定义模型，所有模型采用数据库物理表、索引、主外键实现。不同的租户通过路由到不同的数据库来实现隔离。域模型样例采用大家都熟悉的最小集的订单模型实现，包含商品、用户、订单和订单详情表。注意：此简化模型仅用做示意说明，和意图无关的大多数字段均省略，非严谨定义。

示例模型数据

数据库物理表数据：Customer

数据库物理表数据：Product

数据库物理表数据：Order

数据库物理表数据：OrderItem

实体表关系
Order表同OrderItem为父子表，通过OrderID进行主外键关联；Customer表同Order表为父子表，通过CustomerID进行主外键关联；Product表同OrderItem表为父子表，通过ProductID进行主外键关联。用户自定制
用户有执行DDL权限，可以在自己租户数据库内在进行扩展模型自定义，建立自定义的物理表，索引，关系等。问题和风险
用户具有执行DDL权限，可以自定义数据库物理模型，会带来各租户的自定义数据模型大爆炸，会给后续平台模型定义升级冲突，造成模型升级的巨大的障碍

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

当用户执行DDL时，通常会锁定数据库物理资源，当数据库数量非常巨大时可能会带来不可控的downtime，对应用系统的可用性造成巨大的影响。如果数据库是每个租户各自独占，还只会影响到单个租户；如果是多租户共享数据库，则可能会影响到其他租户，影响是灾难性的。作为云平台服务商，不管是用户操作还是系统行为，我们都不期望我们的设计对用户系统的可用性造成影响，所以用户执行DDL的行为是否允许确实有待商榷，但是如果不允许，用户可扩展性在这种设计环境中必然受到一定程度的限制。

元数据驱动的多租户数据模型(MetadataTables)

前面章节描述了元数据驱动的多租户模型简单模型图，本小节详细解说下每个核心实体表的核心结构，同时已知资料部分较为简略，无法描述模型全貌和核心细节，为了模型完整性，整体数据模型包含了作者思路推理部分，用以来完整清晰地定义模型。当然由于所有模型都是主观的(subjective)，仅代表个人观点，欢迎大家的不同的观点，一起讨论改进。

正如前面介绍“一个云平台”时提到，通过一个统一的数据库来支撑无数个租户，所以元数据驱动的多租户模型是基于一个共享数据库的前提。当然多租户实现设计多种多样，大家可以不拘泥此种。

1）元数据表之对象定义表：Objects表

Object系统表存储了每个租户为它的扩展应用对象定义的元数据，包含如下核心字段:

ObjID：应用对象唯一标识，具有固定长度和格式。OrgID：应用对象所归属的租户ID，用于统一共享数据库内的多租户数据隔离，通常和租户定义的域名对应。ObjName/Name：对象名称，用于系统配置和开发(developername)。Label:对象的显示名称。

除了用户自定义对象，系统的标准对象也是采用相同的方式进行定义的。

2）元数据表之字段与关系定义表：Fields表

Fields系统表存储了每个租户为他的扩展应用对象字段定义的元数据，包含了其所归属的应用对象的租户OrgID，字段所属对象的ObjID，字段定义标识FieldID，字段名称FieldName，字段存储位置定义FieldNum，数据类型DataType。数据类型重要补充关联字段(DigitLeft,Scale,TextLength,RelatedTo,ChildRelationshipName)以及是否必选、唯一、索引标记，还有部分标准字段。Fields表非常关键，其不仅定义了普通的应用对象字段，包括基本信息和数据类型信息，而且通过特殊关系字段对不同应用对象之间的关系进行定义，详细说明如下：

FieldID：此对象字段的唯一标识，具有固定长度和格式OrgID：其所归属的应用对象所归属的租户OrgIDObjID：字段所属对象的ObjIDFieldName/Name：字段名，用于系统配置和开发(developername)。Label：字段展示名称，用以展示给最终用户。FieldNum：对应到Data数据表的数据存储字段映射，暨Data表中ValueX字段中的X。DataType：指定此对象字段的数据类型包含普通类型：Number、TEXT、AutoNumber、Date/Time、Email、TextArea等，也包含特殊的关系类型如：Lookup关系类型、Master-Detail关系类型等。DigitLeft和Scale：用于Number、Currency、Geolocation等数字数据类型的关联设定，例如定义了一个字段的DateType为Number，则需要指定其整数部分的最大位数DigitLeft和小数部分的最大位数Scale，两部分长度总和不超过18位。TextLength：当数据类型为TEXT时启用，用于指定TEXT类型的字符的长度限制。RelatedTo和ChildRelationshipName：这两个字段当DateType为关系类型(Lookup,Master-Detail等)时会启用，其中RelatedTo保存关联的应用对象ID，ChildRelationshipName用于保存父子关系中子方的关系名称，同一个父对象的子方的关系名称唯一，用于关系的反向查询。IsRequired：此字段数据保存时，是否校验值的存在。IsUnique：是否允许重复值。IsIndexed：此字段是否需要建索引。其他字段：此处仅列举了说明模型所需要的字段，其他字段暂不进行列举，不列举原因和其重要性并无直接关联。

3）数据表（DataTables）之关系数据表：Data表

MTData系统表存储了MTObjects和MT_Fields元数据表内定义的数据对象(表)所对应的数据，一一映射到不同的租户各自定义的表和表中的字段(对象和对象字段)。

GUID：数据表的主键，用于存放每个应用对象实例的标识ID。ObjID：其所归属的应用对象所归属的租户OrgID。Name：应用对象实例名称。Value0....Value500：用于存放对象实例字段的数据，其ValueX中X值对应到Fields表中FieldNum定义，ValueX存放的数据，不管原始数据类型、存储格式均为变长字符串格式。

4）数据表（DataTables）之非结构化数据表：CLobs

MT_Clobs用于存储大字符段的存储CLOB，同时CLOB也存储在数据库外的索引结构中，用于快速的Full-Text文本检索。

3.元数据模型核心实体关系图

我们在应用系统开发中，通常我们定义的数据结构包括数据表、表字段，索引通常都会直接定义在物理数据库中，创建物理的表和字段以及索引等。

但是在元数据驱动平台数据模型中，我们定义的用户表包括系统表都是逻辑表，其结构是虚拟的，用户表的定义存储在Objects表，对应的字段定义存储在Fields表中，实际用户数据存储在Data表中。特别注意的是，对象的引用关系定义也定义在Fields表中，以特殊数据类型方式来定义。(另：Relationships表后面章节进行描述)。

从每个租户视角来看，每个租户都在一个共享数据库内拥有一个基于租户标识OrgID来隔离的虚拟的租户数据库。

元数据实体包括Objects和Fileds实体以及实际数据Data实体都包含租户OrgID，这样就可以通过租户OrgID来天然隔离各租户的数据，当然不止这些实体，包括索引相关等透视表实体也使如此。

4.标准对象与标准字段

前面整体架构层次里提到了公共元数据层和标准应用层，公共元数据层提供了标准对象和标准字段的定义。

其中标准对象为每个租户提供公共端到端的应用的标准应用功能。

同时用户可以在标准的对象基础上扩展自定义的应用对象，满足自己的特定业务场景。__c后缀代表自定义，后续详解。

而标准字段则提供给每个对象包括自定义对象的共同的字段，包含部分业务字段和非业务字段。

用户也可以在标准对象和自定义对象内自定义不同的字段，以满足业务需要。__c后缀代表自定义，后续详解。

5.对象关系类型

应用对象关系类型主要分为Lookup和Master-Detail两种关系类型，其中Lookup为弱的父子关系类型，Master-Detail为强的父子关系类型，其特性对比如下。

6.元数据驱动的多租户数据架构示例

同样采用普通多租户SaaS数据架构方案中相同的域模型和示例数据作为参照进行说明，只不过在这里域模型不再对应到数据库的物理模型，而是对应到元数据所定义的虚拟数据库的逻辑模型。请前后对比两种模型对用户业务模型承载的差异和联系，以便深入了解元数据驱动的多租户数据架构。

对于Tenant租户A00001，需要支撑相同的业务逻辑，需要定义相同的域模型，和普通的方案不同的是，这里采用元数据驱动的多租户数据模型来定义订单域模型和对应示例数据，其中域模型定义在元数据表（MetadataTables）中，数据存储在DataTables表中。

1）用户自定义对象Product的定义

Product对象的基本信息定义在Objects表，作为Objects表的一条记录，通过OrgID进行不同租户数据隔离。Object中的每一条记录都代表一个不同的对象。Objects表的定义非常清晰，这里不做过多的解释，请参考Objects表介绍。

Product对象的字段结构定义在Fields表，同时通过ObjID同Order对象定义进行关联，通过OrgID进行多租户数据隔离。

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

下面详细描述一下Product对象中每个字段定义：

产品名称Name字段为标准字段，数据格式为TEXT，长度为80。产品编号ProductNo为自定义字段，数据格式为TEXT，长度为22，FieldNum为1对应Data表存储字段Value1，存储格式为变长字符串。产品价格ProductPrice为自定义字段，数据格式为Currentcy（此格式类似Number，不同是带币种），整数最大长度DigitLeft：16位，小数位最大精度Scale：2位，FieldNum为2对应Data表存储字段Value3，存储格式为变长字符串。状态ProductStatus为自定义字段，数据格式为TEXT，长度为20，FieldNum为3对应Data表存储字段Value3，存储格式为变长字符串。

2）用户自定义对象Customer的定义

Customer对象的基本信息定义在Objects表，作为Objects表的一条记录，通过OrgID进行不同租户数据隔离。Object中的每一条记录都代表一个不同的对象。Objects表的定义非常清晰，这里不做过多的解释，请参考Objects表介绍。

Customer对象的字段结构定义在Fields表，同时通过ObjID同Order对象定义进行关联，通过OrgID进行多租户数据隔离。

下面详细描述一下Customer对象中每个字段定义：

用户名称Name，必选标准字段，不过多解释。用户编号CustomerNo为自定义字段，数据类型为TEXT，长度为22，FieldNum为1对应Data表存储字段Value1，存储格式为变长字符串。FirstName和LastName为自定义字段，数据类型为TEXT，长度均为20，FieldNum为2，3对应Data表存储字段Value2和Value3，存储格式为变长字符串。用户昵称NickName为自定义字段，数据类型为TEXT，长度均为20，FieldNum为4对应Data表存储字段Value4，存储格式为变长字符串。用户登录名LoginName为自定义字段，数据类型为TEXT，长度均为20，FieldNum为5对应Data表存储字段Value5，存储格式为变长字符串。用户状态CustomerStatus为自定义字段，数据类型为TEXT或者PickList，长度为20，FieldNum为6对应Data表存储字段Value6。为简化起见，状态字段暂定义为TEXT，对应Data表存储字段Value4，存储格式为变长字符串。

3）用户订单Order逻辑表的定义

Order对象的基本信息定义在Objects表，作为Objects表的一条记录，通过OrgID进行多租户数据隔离。Objects表中的每一条记录都代表一个不同的对象。

Order对象的字段结构定义在Fields表，同时通过ObjID同Order对象定义进行关联，通过OrgID进行多租户数据隔离。

下面详细描述一下Order对象中每个字段定义：

订单编号OrderNo为自定义字段，DataType数据格式为TEXT，长度为22，FieldNum为1，对应Data表存储字段Value1，存储格式为变长字符串。关系字段Customer为自定义关系字段，DataType类型为弱类型Lookup关系，关联到父对象Customer，则RelatedTo列存储Customer的ObjID：01I2v000002zTEZ，对应的FieldNum为2，则Customer对象实例GUID存储在Data表的Value2列。ChildRelationshipName列存储对象父子关系中子关系名称：orders，用于对象关系中从父对象实例数据反查子对象实例数据。订单状态OrderStatus为自定义字段，DataType类型为TEXT，长度为20，FieldNum为3，则状态存储在Data表的Value3列。为简化起见，状态字段暂定义为TEXT。下单时间OrderTime为自定义字段，DataType类型为Date/Time，FieldNum为4，则下单时间存储在Data数据表的Value4列。

4）用户订单行OrderItem逻辑表定义同样的，OrderItem对象的基本信息也以一条记录的信息定义在Objects表，通过OrgID进行多租户数据隔离。Objects表中的每一条记录都代表一个不同的对象。

OrderItem的字段结构也定义在Fields表，通过ObjID同OrderItem对象关联，通过OrgID进行多租户数据隔离。

下面详细描述一下Order对象中每个字段定义：

关系字段Order为自定义关系字段，DataType类型为强类型的Master-Detail关系，关联到父对象Order，则RelatedTo列存储Order对象的ObjID：01I2v000002zTEj，对应的FieldNum为1，则Order对象实例GUID存储在Data表的Value1列。ChildRelationshipName列存储对象父子关系中子关系名称：OrderItem(s)，用于对象关系中从父对象Order实例数据反查子对象实例数据。关系字段Product为自定义关系字段，DataType类型为弱类型的Lookup关系，关联到父对象Product，则RelatedTo列存储Product对象的ObjID：01I2v000002zTEU，对应的FieldNum为2，则Product对象实例GUID存储在Data表的Value2列。ChildRelationshipName列存储对象父子关系中子关系名称：OrderItem(s)，用于对象关系中从父对象Product实例数据反查子对象实例数据。商品实际售价ItemPrice为自定义字段，DateType类型为Currentcy（此格式类似Number，不同是带币种），整数最大长度DigitLeft：16位，小数位最大精度Scale：2位，FieldNum为2对应Data表存储列Value3，存储格式为变长字符串。商品购买数量ItemQuantity为自定义字段，DataType类型为Number，整形长度为18位，无小数位数，FieldNum为4，对应Data数据表存储列Value4。订单明细状态OrderItemStatus为自定义字段，Datetype类型为TEXT，长度为20，对应FieldNum为5，对应Data数据表存储列Value5。为简化起见，状态字段暂定义为TEXT。

5）对象Schema

定义好的用户应用对象Schema如下图

6）数据表Data表用户数据存储

前面提到了用户自定义的应用对象以虚拟结构的方式存储在Objects和Fields表中，那么用户定义的应用对象Product、Customer、Order和OrderItem里的数据存储在哪里呢？答案是Data表，用户定义的对象的数据均会存储在Data表中，每个用户定义对象实例（或者近似称为用户表记录）数据以Data表中一条记录的形式存在。Product、Customer、Order表的数据记录均存储在Data表，OrderItem也亦是如此。

其中，GUID作为每条数据记录暨是每个对象实例的全局唯一标识，OrgID进行多租户数据隔离，ObjID同Objects表关联代表具体哪个对象定义。这里重点提一下，Fields中定义的对象字段在Data表中的存储，其中Fields表中FieldNum非常关键，它对应了对象实例字段在Data表中的具体存储位置，FieldNum对应数字决定着数据存储在Data表中的哪个ValueX列。前面每个对象结构定义都对FieldNum对应Data的进行了说明，对象字段FieldNum可以不按照顺序来，只要FieldNum没有占用，可以任意对应，当然按照顺序是比较好的实践。

再举例来说：

Order对象的Customer关系字段定义在Fields表中，其FieldNum为1，则其在Data表中存储的位置，就是是Order对象实例在Data对应的记录中Value1这个字段所存储的值，存储的值为Customer对象实例GUID，也就是：a062v00001YXEKuAAP、a062v00001YXEKzAAP等。OrderItem对象的Product、ItemQuantity字段定义在Fields表中，其对应的FieldNum分别为2、4，则其在Data表中存储的位置，就是OrderItem对象在Data对应的记录中Value2、以及Value4所存储的数据，也就是：a052v00000jbgEQAAY、2以及a052v00000jbgMqAAI、3等记录。

7.通用的存储，按需转换—Data表数据类型与存储

我们看了元数据驱动的多租户模型的核心关系，明白了用户自定义表（包括应用系统表）以及表结构是在Objects和Fields进行虚拟定义的，也清楚的知道了系统以及用户表的数据是作为一条条记录存储在Data表中的，那么我们下面来看下不同的数据类型如何在Data中进行存储的呢？

在Fields表中，可以采用任何一种标准的结构化的数据类型，如text，number，date，以及date/time对用户表字段进行定义，也可以采用特殊结构的数据类型对字段类型进行定义，如下拉框picklist，系统自增字段autonumber，公式列（只读的公式推导列），布尔多选框，email，URL以及其他的类型，当然也可以通过系统应用来对Fields中的自定义字段进行强制约束包括是否必须非空以及掐校验规则（如符合特定格式，符合特定值范围等）。

上述的各种不同字段格式数据都是存储在Data表中的ValueX列中的，Data表中包含500个数据列，称为弹性列，用来存储用户数据和系统数据，也就是对应到Objects表和Fields表对应的虚拟表结构所要承载的数据。

特别的，所有弹性列都用了一个可变长度的字符串类型，以便于他们可以存储任何结构化类型的应用和用户数据（字符串，数字，日期等）。

正是因为弹性列把所有不同的数据类型拉平来存储，所以任一弹性列可以对存储任何对象的任何类型的属性来存储，用户可以指定不同的对象的不同属性对应的不同的存储弹性列，当然同属于相同对象的实例的属性对应的弹性列是一致的。一个弹性列可以存储来不同的格式的数据，前提条件是这些数据属于不同的对象的不同属性。例如：上一节示例中，Data表的Value2列可以存储Order表的日期格式的OrderTime数据，也可以存储OrderItem表的格式为字符串的OrderID数据。

如上所述，弹性列用通用数据类型暨可变长字符串来存储所有类型的数据，这样就可以在不同的用户表字段间共享相同弹性列，即便它们的数据类型各异。

既然所有的数据全部用通用的可变长字符串来存储，那么应用逻辑处理需要不同的数据格式时候怎么办呢？具体做法如下：

当应用系统需要从弹性列读取和写入数据时候，UDD(UniversalDataDictionary)层暨元数据运行引擎会用底层数据库系统数据转换函数（如Oracle数据库的TONUMBER,TODATE,TO_CHAR函数）按需对数据格式进行转换，将字符串格式转换成对应的数据格式（数字，日期等）。

如果存储非结构化的大文本块数据怎么办呢？模型支持对Clob大字段的定义，对于在Data表中具有CLob数据的每一行数据，系统将其存储在Clobs透视表中，并按照需要同Data表的对应数据对象实例记录进行关联。

8.多租户索引透视表(PivotTables)

1）Indexes透视表

大多数结构化的数据存储在Data表内，如前面提到的，所有这些不同类型数据都是以可变字符串的形式存在ValueX列里面如各种数字以及日期等全部都是以可变字符存储的，这样虽然对于对象实例各种字段的存储确实非常灵活，不同的列可以存储不同类型的数据，即使同一ValueX列不同的对象也可以存储类型的数据，但是这样带来一个巨大的问题，由于不同的数据类型以可变字符串的方式存储在同一列内，你没办法利用底层数据库索引的能力对其进行排序，ValueX列的数据都是一种按照离散的顺序来存储的。传统的数据库依赖原生的数据库索引来快速在数据表内定位到符合查询条件的记录。而按照Data表ValueX列的数据存储情况，在Data表建立ValueX列的索引来支撑数据快速查询是不现实的。

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

Indexes透视表的字段说明如下：

OrgID：其所归属的应用对象所归属的租户OrgIDObjID：字段所属应用对象唯一标识FieldNum：对象字段存储位置ObjInstanceGUID：对象实例唯一标识StringValue：强类型的字符串列NumValue：强类型的数字列DateValue：强类型的日期列

下面的Indexes表示例包含对字符、数字和日期性数据的索引需求支持，数据来源于前面的Data表数据。

Indexes表的底层索引是标准的，采用非唯一性的数据库索引。当做对象检索查询的时候，实际上不是在Data数据表上做查询，而是在Indexes索引表上做的查询，获取到OrgID，ObjectID以及GUID，然后再返回数据表获取数据。也就是当系统查询条件包含对象实例的结构化的字段时，系统查询优化器采用MT_Indexes来帮助优化相关的数据访问操作。

2）UniqueIndexes透视表

由于Data数据表的多数据类型的无差别存储，无法在Data数据表建唯一性的索引供用户来使用对对象字段值进行唯一性校验。为了支持用户对象自定义字段的唯一性校验，解决办法是采用了UniqueIndexes透视表；这个表非常类似于Indexes表，不过Uniqueindexes采用底层原生的数据库索引来强制唯一性校验。当一个用户尝试来插入一个重复的值到具有唯一性约束的对象字段时，或者当用户尝试去在一个现存的包含唯一性的字段进行强制唯一性时，系统会给出唯一性校验失败的提示，阻止用户的下一步操作。

UniqueIndexes透视表的核心字段说明如下：UniqueStringValue：唯一的字符串列UniqueNumValue：唯一的数字列UniqueDateValue：唯一的日期列其他字段定义请参考Indexes透视表

3）Relationships索引透视表

在元数据驱动的多租户模型中，提到了在Objects表以及Fields表中保存了用户对象结构和对象关系的定义，对象关系的定义是通过元数据模型Fields表字段数据类型提供了一个特殊的数据类型：“关系”(Relationship),来给用户用于声明不同的用户应用对象之间的关系，也就是我们通常说引用完整性。

对象之间的引用关系定义以及对象实例间的引用关系存储在元数据表Objects、Fields中和Data表中，关联查询关系复杂，为了提升对象之间查询的效率，特别是通过对象相互引用关系对对象实例数据进行检索，系统提供关系索引透视表Relationship来优化对象引用关联查询。

Relationships索引透视表的字段说明如下：

OrgID：其所归属的应用对象所归属的租户OrgIDObjID：子对象的对象标识GUID：子对象实例的唯一标识RelationID：子对象内关系字段定义的标识TargetObjInstanceID：父对象实例的唯一标识

关系透视表Relationship定义了两个底层数据库复合索引：

第一个索引字段：OrgID+GUID，用于从子对象到父对象的关联查询。第二个索引字段：OrgID+ObjID+RelationID+TargetObjInstanceID，用于父对象到子对象的关联查询。

Relationships索引透视表会在后面SOQL章节进行进一步描述验证。

4）其他索引透视表

其他索引透视表的逻辑类似，都是为了满足特定检索和查询需要，将数据同步到索引表，供应用系统使用。此处不再赘述，如确实有需要再补充。

五、SOQL与关系Relationships

SOQL是SalesforceObjectQueryLanguage的简称，具有SQL类似的语法结构，就像前面提到的一样，Salesforce是以应用对象（SalesforceObject，简称SObject）的视角管理业务数据和功能，SOQL类似对用于对应有对象数据进行查询的API。

1.从SQL到SOQL

SOQL也是采用类似表查询的结构，同SQL非常相似，也通过底层数据库索引来提供查询优化支撑。不同点如下：

没有select*没有视图概念SOQL是只读的由于底层元数据驱动的多租户数据模型的限制，索引是受限制的，没有原生数据库物理结构丰富的索引支持。对象到关系的映射(Object-RelationalMapping)是自动完成的。SObjects在多租户环境中并不是对应实际的物理数据表。SObjects包括SObjects之间的关系都是以元数据的方式存储在多租户环境中的。

2.SOQL示例&语法

下面我用示例来说明一下SOQL的用法，同时引出SOQL的特殊语法说明,SOQL大小写不敏感。

1）单个对象的查询及语法说明

selectid,productno__c,name,productprice__c,productstatus__cfromproduct__c

前面提到过系统提供了标准应用对象和标准字段定义，更大的优势在于支持用户自行自定义对象和字段。这里c代表的使用户自定义的含义,productc代表的用户自定义对象Product，而非系统标准对象和字段，系统标准对象和字段在SOQL无需c后缀，如ID，Name，CreatedBy等字段则为系统提供给每个对象的标准字段，而字段ProductNo为用户自定义字段，则SOQL中的语法表示为productnoc。这样的好处是讲标准和用户自定义对象和字段很容易区分开，系统可以定义标准Product对象，以product表示，用户也可以同样定义一个Product对象，不过SOQL用product__c表示用于区分。

2）子对象关联父对象(ChildtoParent)查询及语法说明

selectid,name,orderno__c,customer__c,customer__r.customerno__c,customer__r.name,orderstatus__c,ordertime__cfromorder__corderbyorderno__c

selectid,name,orderno__c,customer__c,customer__r.customerno__c,customer__r.name,orderstatus__c,ordertime__cfromorder__cwherecustomer__r.name='ChengYan'orderbyorderno__c

这里是从子对象Order关联到父对象Customer进行查询，其中：

from后面的对象order__c表示Order为用于自定义对象Id,name为Order对象内系统定义的标准字段Ordernoc,customerc,orderstatusc,ordertimec为用户自定义字段，这里需要说明的是customer__c自定义字段存储的是父对象实例IDcustomerr就特别有意思，其中r部分代表父对象关系引用，customer部分对应关系字段名，customerr代表从Order对象到Customer对象的一个应用关系，并通过customerr.customernoc,customerr.name获取到Customer对象的字段值。

3）父对象关联子对象(ParenttoChild)查询及语法说明

selectid,orderno__c,customer__r.name,ordertime__c,orderstatus__c,(selectid,product__r.productno__c,product__r.name,product__r.productprice__cfromorderitem__r)fromorder__corderbyorderno__c

这个语句稍微有些复杂，从Order对象关联到OrderItem对象，又从OrderItem关联到Product，同时还包含了Order对象到Customer对象的关联。

这里着重说一下从父对象到子对象的关联，父到子的关联是在父对象的主查询语句中在查询字段中用（）来封装到子对象的关联，其中

子句中fromorderitemr的orderitemr代表的是对子对象OrderItem的引用，orderitem对应的为前文关系字段中提到的ChildRelationshipName，并且同一个父对象的子方的关系名称唯一（父对象Name+ChildRelationshipName必须唯一），用作父对象到子对象的查询关联。子句中id,productr.productnoc,productr.name,productr.productpricec的上下文为orderitemr代表的子对象。

3.Relationships索引透视表

Relationships是为了SOQL的快速对象关联查询所定义的，子对象关联父对象(ChildtoParent)查询，复合索引（OrgID+GUID）在Join中起到较大作用，而需要从父对象关联子对象(ParenttoChild)查询，则复合索引（OrgID+ObjID+RelationID+TargetObjInstanceID）在Join中起到较大作用。

六、如何支撑多租户巨大数据量

前面我们提到Salesforce一个共享数据库的概念，那一个共享数据库怎么来支撑如此巨大的多租户数据库呢，同时不仅需要支持巨量数据，并且还可以支撑租户间的数据物理隔离，保证各租户的数据稳定性、可用性和数据安全？

Salesforce的做法是：分区。所有的Force.com的数据，元数据，透视表结构，包含底层数据库索引，都是通过对OrgID进行物理分区的，采用的是原生的数据库分区机制。所有的数据以及元数据通过你的OrgID（16digits）进行分片Hash。

数据分区是数据库系统提供的被验证过的技术，用以物理划分较大的逻辑数据结构到较小的可以管理的区块中。分区也可以帮助提升性能和扩展性，贴别是在多租户环境下一个巨大的数据系统的扩展性。根据定义，每一个SOQL的查询对应一个特别的租户信息，因此查询优化器，仅仅需要考虑访问包含对应租户的数据分区访问，而不是整个表或者索引。

七、无感的对象结构变更(NoDDL)

当一个应用系统或者服务组件需要对其数据模型进行升级的时候，通常会通过数据库DDL语言对数据库物理结构进行操作，如果涉及的数据量较大，则可能会造成较长时间的数据库变更时效，造成对应时间内的系统不可用，如果是多租户系统还会可能其他租户的可用性造成影响，抑或造成诸多的底层模型不一致产生。

在元数据驱动的数据架构中，所有的DDL语言操作对应的使元数据层的元数据的记录的更新，不涉及数据库物理结构的更新，不会造成变更期间的数据库物理结构耗时调整造成的不可用，同时系统平台提供了一个高效的机制来减少对平台多租户应用总体性能影响。

当用户修改了一个表字段列的数据结构，从一种数据类型改成另外一种不同存储格式的数据类型时候，系统会重新分派一个新的弹性列给到这个字段列的数据，将数据从原来的存储弹性列批量拷贝到新的弹性列，然后才会更新此字段列的元数据，暨在Fields表中更新这个字段列的元数据，将数据类型更改为新的数据类型，并将FieldNum更新为新的ValueX列对应的X值。

同时，在如上对用户逻辑表结构调整生效过程中，原来的数据结构和对应的数据访问正常进行，直到逻辑表结构变更生效，对应用系统可用性不会造成影响，用户对此无感知。

八、多租户架构对于研发人员意味着什么

对于研发人员来说，多租户结构最多意味着两个版本：当前版本，以及下一个版本。没有遗留版本需要维护。所有人不用操心旧的技术，旧的版本，所有只有最新的版本，只需要关心最新的版本。

这样就给敏捷开发带来极大的好处，每年做个位的发布，每次发布几百个新的特性新的版本也不会改变用户的体验，新的特性可以根据用户需要开启，通过特性管理来开关。

新版本发布前，提供沙箱环境来允许用户提前试用新版本的系统。如果做bug修复，则是在所有租户层面上进行统一修复的。

对于用户应用的发布进行严格管理，防止对其他租户产生影响，通过提供沙箱环境来让用户验证新应用发布，并通过成千上万的自动化测试保证用户的正常功能。

在运行期间，不作任何底层DDL操作，不会做表的创建，也不会做表的变更，只可能在极少数的更新周期时候进行。

作者简介：程彦，曾就职于阿里数字供应链事业部担任多年供应链计划域研发，目前在阿里数据中台负责相关商业化产品开发。