共计 1373 个字符，预计需要花费 4 分钟才能阅读完成。
Trafodion 在 IoT（物联网）空间、电信和网络安全中的一个常见应用场景是用一个非常大的单表，记录实时事件。用户希望快速摄取新数据，查询数据，并清理过时的数据。
对于这种情况，我们一般建议客户使用一种设计模式。该模式包含三个要素：Salting、分块和 Stripe 合并。
Salting
第一个要素是 salting，在集群中平均分布数据。通过 salting 不仅平均分布全部数据，而且在集群中的所有节点均匀分布热（最新）数据。Salting 基于哈希散列，运用哈希散列函数计算每一行的 region 号。一般情况下，这是基于运营型查询中使用的一列或多列，比如客户 id 或设备 id。
Trafodion 自动管理 salt。计算哈希散列函数，并自动对 Salt 列执行条件判断。SQL 的 Insert、Select 和 Delete 语句不需要任何特殊的操作。
数据均匀分布之后，我们面临下一个问题——选择一个恰当的行键。为了让数据查询、过时数据清理和合并更容易，我们需要在每个 region 的末尾添加新行，但并不是随机添加。我们还希望按日期范围对时间序列的数据进行查询，并对其他重要的列（例如，customer id 或 device id）进行查询。
为了实现以上两个目标，我们紧接着在 salt 后面采用了另一个键前缀——分块标识（divisionid）。分块是一个时间范围，比如一天、一周或一个月。它将该时间范围内所有的行全部归并在一起，以便我们选择一列（例如，customer id）作为主键列。
这类情景中典型的运营型查询如下所示：
SELECT * FROM t
WHERE cust_id = x AND transaction_timestamp BETWEEN y AND z
在 cust_id 上做 Salting 可确保用户 x 的所有行均放在同一个 HBase region 中。Trafodion 通过对该 salt 列进行条件判断，确保查询仅访问该 region 服务器。
分块
按列分块确保我们只需要读取相关时间范围中的数据，而非多年的历史数据。此外，我们能够使用 cust_id 作为主键列，从而在数百万用户数据中迅速为我们的用户锁定所需数据。
有时我们想要查询多位用户的数据和多天的数据。Trafodion 采用独特的多维访问方法（MDAM）将多个复杂的条件判断分离，只扫描相关范围，略过中间不需要的数据，从而有效地实现该目标。
我们已经证明，通过 salting 和分块，很容易在时间结构表中插入数据，并且在查询时仅需要访问特定时间范围和关键列中的所需的数据。
Stripe 合并
还有两个容易忽视的问题：数据过时处理和 HBase 主合并。为此，HBase 的 stripe 合并可以起到很大的作用。将 HBase region 中的数据分成多个 stripe，每个 Strip 对应一个键的范围（比如每个 stripe 中存储一个月的数据）。只合并这些 stripe 内的文件。这意味着数月不曾改变的历史数据不需要通过压缩重复改写。这些数据保持原状，直到过时（即删除）。到那时，一些“stripe”中的数据清空，然后与更新的非空 stripe 合并。
总之：Trafodion 和 HBase 提供了三个强大的设计要素，使您能够在一个表中存储大量基于时间的数据。对于 SQL 查询，salting、分块和 stripe 合并是透明的。通过这三个要素可以有效地实现数据摄取、查询和过时处理。
