博文
Force.com的多租户架构理解（二）
||
5. Force.com平台体系结构概述
Force.com的优化的元数据驱动架构提供了性能非凡的、可扩展的、按需定制的多租户应用（图3）。
图3：Force.com的元数据驱动的体系结构以最优的方式在运行时产生虚拟的应用程序组件。
在Force.com中，暴露给开发和应用程序用户的一切东西都内在地呈现为元数据。表格、报告、工作流、用户访问权限、租户特定的自定义和业务逻辑，甚至是基础数据表和索引的定义，所有这些都只是作为元数据在Force.com的通用数据字典（UDD）中被抽象和构建。例如，当一个开发人员建立一个新的自定义应用时，定义客户表，放置一个表单，或写一些程序代码，Force.com并不会在数据库中创建一个“实际”的表或编译任何代码。相反，Force.com只是简单地存储元数据，该平台的引擎可使用这些元数据在运行时生成“虚拟”的应用程序组件。当有人想修改或定制一些有关应用程序，所需要做的只是对相应元数据简单的无阻塞更新。
由于元数据是影响Force.com应用的关键成分，该平台的运行时引擎必须优化元数据的访问，否则，频繁访问元数据将会阻碍平台的可扩展性。考虑到这个潜在的瓶颈，Force.com使用元数据缓存，以将最近最多使用的元数据保持在内存中，从而避免性能受到磁盘I / O和代码重新编译的影响，并提高应用程序的响应时间。
Force.com将少数大型数据库虚表中的所有应用数据作为堆存储。然后考虑相应的元数据，该平台的引擎在运行时物化虚拟表中的数据。为了优化系统大表的数据存取，Force.com的引擎上依赖一组专门的数据透视表，来维护各种用途的非规范化的数据，如索引，唯一性，关系，等等。
Force.com的数据处理引擎通过透明地进行批量数据修改操作，精简了大型数据的加载开销和在线事务处理应用。该引擎内置故障恢复机制，自动在分析出导致错误的因素后重试批量保存操作。
为了进一步提升应用程序的响应时间，该平台采用外部搜索服务优化全文索引和搜索。应用程序更新数据时，搜索服务的后台进程近实时地异步更新租户和用户的索引。应用程序引擎和搜索服务之间的职责分离使平台应用可以有效地处理事务，而没有文本索引的更新开销，同时也为用户迅速提供准确的搜索结果。
由于Force.com的运行时应用程序生成器，针对特定的用户请求动态地建立应用程序，所以引擎在很大程度上依赖其“多租户感知”的查询优化器尽可能有效地执行内部操作。查询优化器首先考虑哪些用户正在执行给定的应用功能，然后利用维护在UDD中的相关租户的特定元数据以及内部的系统透视表，建立并执行数据访问操作，以优化数据库查询。
现在你有了一个关于构成的Force.com底层机制的关键架构组件的总体思路，以下章节将更详细地解释其结构和各种内部系统元素的构建目的。
6. Force.com的数据定义和存储
Force.com的存储模型不是试图管理一个庞大的、不断变化的、代表每个应用程序和租户的实际数据库结构集，而是使用一组元数据、数据集和数据透视表来管理“虚拟”数据库结构，如图4所示。
图4：Force.com的数据定义和存储模式包括一组元数据，数据集，数据透视表，
允许对 “虚拟”表中的实际数据进行功能上的访问。
当组织创建自定义应用对象（即自定义表），UDD不断追踪关于对象、字段、关系和其他对象定义特征的元数据。与此同时，一些大型数据库表为所有虚拟表存储结构化和非结构化数据，还有一组相关的专用透视表来维护非规范化数据，使数据极其功能化。
图5是一个Force.com元数据和数据结构的简化实体关系（ER）图的三个核心：对象（Object），字段（Field）和数据表（Data Table）。
注 ：为了简洁和清晰，Force.com的系统表和列的真实名字不一定在本文中出现。
6.1 对象元数据表（The Objects Metadata Table）
对象元数据表存储组织为其应用定义的自定义对象（又名表或实体）的信息，包括一个对象的唯一标识符（ObjID），拥有该对象的组织（OrgID），以及该对象的名称（ObjName）。
6.2 字段元数据表（The Fields Metadata Table）
字段元数据表存储组织自定义对象的自定义字段（又名列或属性），包括一个字段的唯一标识符（FieldID），拥有该对象的组织（OrgID），包含该字段的对象（ObjID），字段名称（FieldName），该字段的数据类型，表示如果该字段是否需要索引的Boolean值（IsIndexed）和在对象中相对于其他字段的位置（FieldNum）。
图5：Force.com使用对象和字段的元数据来定义应用对象和字段，
并映射为大型数据库表中存储的相应数据。
6.3 数据表（The Data Table）
数据表存储可供访问的应用程序数据，并通过对象和字段的元数据定义映射到自定义对象和字段。每一行包括一个标识字段如全局唯一标识符（GUID）、拥有该行的组织（OrgID）以及对象标识符（ObjID）。数据表中的每一行也有一个名称字段存储相应对象实例的“自然名”。例如，一个Account对象可以使用“Account Name”，一个Case对象可能会使用“Case Number”等等。这Value0 ...Value500列存储应用数据，这些列将对象和字段分别映射到在对象和字段表中声明过的对象和字段；所有“flex”列使用可变长度字符串数据类型，从而能够存储任何类型的应用程序数据（strings，numbers，dates等）。
自定义字段可以使用任何一种标准结构化数据类型，如text，number，date，和date/time以及特殊用途的结构化数据类型，如选择列表（枚举字段），自动编号（自动递增，系统生成的序列数），公式（只读的派生值），主从关系（外键），复选框（布尔），电子邮件，网址等。自定义字段也可能是必须的（不为空），或者包含自定义的验证规则（例如，一个字段的值必须比其他字段更大），两者都是通过该平台的应用服务器来实现的。
当一个组织声明或修改自定义应用程序的对象，Force.com管理对象元数据表中定义对象的一行。同样，对于每个自定义字段，Force.com管理字段表中的一行，包括将这个字段映射到数据表中的一个存储相应字段数据的flex列的元数据。因为Force.com将对象和字段定义作为元数据而不是实际的数据库结构来管理，所以平台可以容忍多租户应用模式的维护活动，而不阻碍其他租户和用户的并发活动。
同一个对象不会有两个字段映射到数据表中同一个的flex列（槽）存储；然而，一个flex列可以管理多个字段的信息，但每个字段来自于不同的对象。
图6：一个flex列可以存储来自不同对象的属性的数据，它们拥有不同的数据类型。
如图6所示的数据表的简化表示，flex列拥有一种通用数据类型（变长字符串类型），允许Force.com在多个字段间共享一个flex列，使用各种结构化的数据类型（strings，numbers，dates等）。
Force.com使用统一的格式存储所有flex列数据，而且当应用程序从flex列读取和写入数据时，必要时候使用底层数据库系统的数据类型转换函数（例如，TO_NUMBER，TO_DATE，TO_CHAR）。
虽然没有显示在图5中，但是数据表中还包含其他列。例如，有4个用于管理审计数据的列，包括何时和哪些用户创造了对象实例（行），以及何时和哪些用户最后更改了对象的实例。数据表还包含isDeleted字段来说明对象实例是否已被删除。
6.4 Clobs表（The Clobs Table）
Force.com支持将字段作为字符大对象（CLOBs）声明，以允许存储多达32,000个字符的长文本字段。对于每一个在数据表含有CLOB字段的行，Force.com会在一个称为Clobs的透视表中存储CLOB超行，系统可以必要时通过它与数据表中相应的行进行连接运算。
注：Force.com还将CLOBs以索引形式存储在数据库外部，以方便快速的文本搜索。
6.5 索引透视表（The Indexes Pivot Table）
传统的数据库系统依赖索引迅速定位数据库表中的字段满足特定匹配条件的行。但是，为数据表的flex列创建本地索引是不切合实际的，因为Force.com可能用一个flex列来存储很多字段的数据，且它们的数据结构类型各不相同。所以，Force.com通过同步复制有标记的字段来管理数据表的索引，这些标记字段数据被索引到一个称为Indexes的数据透视表中相应的列，如图7简化ER图的描述。
该Indexes表包含强类型的索引列，如StringValue，NumValue和DateValue，Force.com借此查找相应数据类型的字段数据。例如，Force.com将复制一个数据表中flex列的字符串值到Indexes表的stringValue的字段，将日期值复制到DateValue字段，等等。Indexes表的底层索引是标准的非唯一数据库索引。当包含一个查询参数内部系统查询引用了自定义对象中的一个结构化字段，该平台的查询优化器就使用索引表，以帮助优化相关的数据访问操作。
图7：Force.com使用数据透视表来索引存储在flex列的数据。
注 ：Force.com可以处理多语言搜索，因为该平台的应用服务器使用大小写折叠算法将字符串值转换成一个普遍的、大小写不敏感的格式。Indexes表的StringValue列以这种格式存储字符串。在运行时，查询优化器自动生成数据访问操作，从而使得对于字面上给定的搜索请求，优化后的SQL语句可以做些相应大小写折叠后的StringValue的过滤。
6.6 唯一域的数据透视表（The UniqueFields Pivot Table）
Force.com允许组织指出何时一个对象中的字段必须包含唯一值（区分大小写或不区分大小写）。考虑到数据表值列上共享使用自定义的字段数据，为表创建唯一的数据库索引是不切实际的，这与前面部分讨论过的非唯一索引问题类似。
为了支持自定义字段的唯一性，Force.com使用称为UniqueFields的数据透视表来实现，这表与Indexes数据透视表非常相似，只不过UniqueFields数据透视表的底层数据库索引强制唯一性。当一个应用程序试图在需要唯一性的字段上插入重复值，或者管理员试图在包含重复值的已有字段上强制唯一性时，Force.com中转一个适当的错误消息给应用程序。
6.7 关系数据透视表（The Relationships Pivot Table）
Force.com提供了组织声明其应用对象间关系的“关系”数据类型（参照完整性）。当一个组织将对象的字段声明为关系类型时，平台将该字段映射到数据表中的一个值字段，然后使用该字段来存储相关对象ObjID。
为了优化连接操作，Force.com维护一个称为关系（Relationships）的数据透视表，如图8所示。
图8：关系表可帮助优化对象连接。
关系索引表（The Relationships Index table）有两个底层数据库的唯一联合索引，即OrgID +GUID，和OrgID + ObjID + RelationID + TargetObjID，从而保证必要时对象双向遍历的高效性。
6.8 FallbackIndex表（The FallbackIndex Table）
在极少数情况下，平台的外部搜索引擎可能超载或不可用，或可能无法及时响应搜索请求。用户提交一个查询请求后，该平台的用户服务器进入后备的二级搜索机制，返回合理的搜索结果，而不是返回一个令人失望的错误。
后备搜索是数据库查询的直接实现，它参照目标应用对象的名称字段进行搜索。为了不必执行潜在的昂贵的Union查询，实现优化搜索全局对象（跨对象搜索），Force.com维护一个称为FallbackIndex的数据透视表来记录所有对象的名称。当事务修改对象时，FallbackIndex同步更新，后备搜索总可以访问到最新的数据库信息。
6.9 NameDenorm表（The NameDenorm Table）
该表是一个精简的数据表，存储ObjID和数据表中每个对象实例的名称。当应用需要给出一个父子关系的对象实例的超链接列表时，Force.com使用NameDenorm表来执行一个相对简单的查询，检索每个引用对象的名称以得到超链接的列表。
6.10 历史跟踪表（History Tracking Table）
Force.com容易实现对任何字段的历史跟踪。当组织审计特定的字段，系统将使用一个用于审计跟踪的内部透视表异步记录该字段的变化信息（旧值，新值，改变的日期等）。
6.11 数据和元数据的分区
所有Force.com的数据、元数据和数据透视表结构，包括底层数据库索引，都是使用本地数据库的分区机制并按OrgID进行物理分区的。数据分割是一个成熟的技术，数据库系统将较大的逻辑数据结构物理上划分为更小、更易于管理的块。
分区还可以改善诸如多租户环境大型数据库系统的性能、可伸缩性和可用性。例如，每一个Force.com应用通过定义来查询一个特定的目标租户的资料，查询优化器只需要访问一个租户而不是整个表或索引的数据分区，这是一种常见的优化方法，有时也称为“partition pruning”。
https://blog.sciencenet.cn/blog-425672-319226.html
上一篇：Force.com的多租户架构理解（一）
下一篇：Force.com的多租户架构理解（三）
