8. 内部查询优化

大多数现代数据库系统使用基于成本的查询优化器来决定最优的查询执行计划，考虑与目标表和索引数据相关的统计信息。然而，传统的基于成本的优化器的统计数据是为单一租户的应用而设计的，而多租户环境中为特定用户执行的查询给出数据访问特性时就失效了。例如，查询某一种对象的大量数据时，对可见度高的用户（如可以看见所有对象实例的经理）和可见度低的用户（如只能看见与自己相关的行数据的销售人员）采用不同的执行路径更加有效。

    为了提供足够的统计信息以确定多租户平台中最佳的查询执行计划，Force.com为每个虚拟的多租户对象维护了一套完整的优化器统计信息（tenant/group/user级别）。慎重考虑了整体的tenant-specific对象统计信息，以及更加细粒度的统计信息（一个特定权限的group或者最终用户潜在可访问的行数，等等），从而统计信息反映了一个特定查询潜在可访问的行数。

    Force.com还维护了有助于特定查询的其他类型的统计信息。例如，对所有自定义索引的统计信息揭示了相应字段非空和唯一值和总数，picklist字段的直方图表明每个list值的势（cardinality）。

    当已有的统计信息不合适或者帮助不大时，Force.com的优化器使用一些不同的策略来创建合理的最优查询。例如，当一个查询在对象的名称字段上过滤时，优化器可以使用FallbackIndex数据透视表来高效地找到请求对象实例。其他场合优化器在运行时动态地生成缺失的统计信息。

    按照串联使用顺序，Force.com的优化器还依赖于内部的与安全性相关的表（Groups，Members，GroupBlowout和CustomShare），它们维护用户域安全性相关的信息，包括对给定用户组的成员定制访问对象的权利。

图11：当数据请求发生时，Force.com执行预查询（pre-queries），

平台的查询优化器使用该结果建立和执行最佳的数据库查询

    图11所示的流程图描述了Force.com拦截一个对大型堆表（如数据表）的数据请求时所发生的事情。这个请求可能来自于任意资源，如来自应用框架应用程序的页面请求，或web服务API调用，或Apex脚本。平台首先根据多租户敏感的统计数据进行预查询（pre-query），然后根据其返回结果创建一个特定背景下的最优数据库查询以供执行。

表 1： Force.com查询执行的四种方式

    如表1所示，根据提交查询的用户和查询过滤条件的选择度不同，Force.com对于同一查询可以有四种不同的执行方式。

9. Force.com 全文搜索引擎

基于web应用的用户开始期待交互式的搜索能力，通过扫描整个应用数据或者选择的一部分数据，及时返回有序的结果，所有这些将在次秒级的响应时间内完成。为了向平台应用提供如此健壮的功能性，Force.com使用一种基于架构的外部搜索引擎，如图12所示。

    应用的文本型字段，如CLOBs，Name等，更新数据时，一个称为indexing servers的后台进程池，负责异步更新相应的indexes表，搜索引擎在核心数据库之外维护这些indexes。为了优化indexing过程，Force.com同步地将修改过的文本数据块复制到内部的“即将”索引的表中然后进行事务提交，因而提供了一个相对较小的数据源，减少了indexing servers必须从磁盘读取的数据量。搜索引擎为每个组织（即租户）自动维护单独的索引。

    由于indexing servers的现行负载和使用率，文本索引的更新可能显著性地落后于真实的事务。为了避免失效索引导致的不可预期的搜索结果，Force.com还维护了一个最近更改对象的MRU缓存，应用服务器将用它来物化全文搜索结果。平台按照每位用户和每个租户的原则维护这个MRU缓存，高效地支持可能的搜索范围。

图12： Force.com使用外部搜索引擎为多租户应用提供快速文本检索

Force.com使用多种不同的方法在搜索结果范围内优化记录排序。例如，系统根据执行查询的用户的安全域及当前用户可访问的对象权重比较来确定排序。另外，考虑特定对象的修改历史，将较经常更改的对象至于那些相对静态的对象之前。用户可以选择搜索结果的期望权值，如突出最近修改的对象等。

转载本文请联系原作者获取授权，同时请注明本文来自唐李洋科学网博客。
链接地址：https://blog.sciencenet.cn/blog-425672-319234.html

上一篇：Force.com的多租户架构理解（三）
下一篇：Force.com的多租户架构理解（五）