架构优化最佳做法

表架构定义了表中所有列的名称和数据类型。表架构可以在表创建过程中设置，也可以通过修改适用的引入映射，作为数据引入过程的一部分进行设置。定义表架构的方式可能会极大影响查询性能。数据的理想架构取决于多个因素，包括用例、数据访问模式以及你计划存储的特定数据。本文介绍通过设计高效架构来优化性能的最佳做法。

数据类型

有关数据类型的通用信息，请参阅标量数据类型。

常用的字段应为类型化列，而不是动态类型。
动态列中经常搜索或合并的 JSON 属性应转换为表中的常规列，具有更具体的类型，例如 string、long 或 real。
使用 DropMappedFields 映射转换，将不常用于筛选和合并的稀疏列作为动态列中的属性包进行收集。
日期时间列应作为 datetime 数据类型键入，而不是 long 或其他数据类型。
- 例如，使用 Unix 转换映射中的 DateTime。DateTimeFromUnixMilliseconds 。
decimal 数据类型提供精确精度，这使得它最适合需要精确精度的财务和其他应用。但是，它比 real 数据类型慢得多。仅在需要时使用 decimal 数据类型。
所有 ID（标识）列都应作为 string 数据类型键入，而不是数字。此数据类型将使索引更加高效，并且能够显著缩短搜索时间。它还将启用分区，因为分区只能对字符串列定义。如果在此列上使用的查询筛选器只是相等，例如，如果该列包含 guid，则可以使用编码配置文件 Identifier。有关详细信息，请参阅编码策略。

针对窄表进行优化，这些表优先于包含数百个列的宽表。
为了避免在查询期间出现开销很高的联接，请通过在引入期间扩充维度数据来非规范化这些维度数据。如果用于扩充的维度表已更新，而且方案需要最新值，请使用具体化视图，仅保留最新值。
如果存在 20 个以上的稀疏列，这意味着很多值都是 null 值，而且这些列很少用于搜索或合并，则请使用 DropMappedFields 转换映射，将这些列分组为动态列中的 JSON 属性包。

从未搜索过的字段可以禁用索引。将编码策略与配置文件 BigObject 结合使用，禁用对字符串或动态类型化列的索引。