冷热分离常见问题

Lindorm通过compaction机制异步将冷数据从热存储归档至冷存储，系统触发时间默认为冷热分界线的一半，最小为1天，最大为major compaction周期的一半，major compaction周期默认为20天。例如，冷热分界线为3天，则默认1.5天就会自动触发一次compaction归档任务；如果冷热分界线为1天，则1天触发一次compaction。

可以。您可以通过HBase Shell对表执行major_compact 'tableName'来强制触发compaction，将热存储中的冷数据归档至冷存储中。

这是因为您写入的数据可能还未写入磁盘。请先执行flush操作将数据刷写至磁盘上，再执行compaction操作，即可将数据存储至冷存储中。compaction操作说明如下：

• HBase Shell使用方式，请执行major_compact命令。

• Lindorm-cli连接使用方式，使用语法请参见ALTER TABLE。

• 如果出现compaction积压，则会影响热数据进入冷存储的速度。此时需要通过扩容或升级配置来增加CPU资源，以解决compaction积压的问题。

  说明

  是否出现compaction积压可以通过查看实例监控信息中的宽表引擎指标——集群负载 > Compaction队列长度(个)来确定。如果持续大于0且个数不断增加，则说明已出现compaction积压。如何查看监控信息，请参见查看监控信息。

• 如果您的宽表引擎不是最新版本，请升级到最新的版本，新版本优化了冷数据归档的速度。如何查看或升级当前版本，请参见宽表引擎版本说明和升级小版本。

• 如果还有其他疑问，请联系技术支持。

如果更新的冷数据不是自定义时间列，那么更新后的数据依旧是冷数据；如果更新的是自定义时间列中的数据，则需要根据新写入的时间内容来重新划分冷热数据。假设一个表的主键列为p1，p2， 非主键列为c1， c2，某一行为p1=row1， p2=2023.1.28日， c1=”c1“， c2=”c2“，冷热分界线CHS=1天，当前时间为2023.1.30日，此时这一行为冷数据。如果更新这一行中的c1，c2列的值，那么这一行仍然为冷数据；如果将这一行中p2的值更新为2023.1.30日，那么这一行将变为热数据，直到2023年2月1日（2天后），才会重新变为冷数据。

不会。自定义时间列是系统对数据冷热分离存储的依据。如果一行数据未写入时间，那么这行数据会被保留在热存储区。

不是。由于更新后的数据重新记录了时间戳，因此冷数据更新后变为热数据。

查询语句可以通过设置HOT_ONLY/_l_hot_only_仅查询热数据。但由于数据归档至冷存储的操作是周期性触发的，因此有部分冷数据可能会滞留在热存储，导致查询结果中包含了冷数据。可以在查询条件中添加热数据时间范围，避免出现此类问题。示例如下：

// 您需要设置_l_ts_min_(当前时间-冷热分界线), _l_ts_max_(当前时间), 注意时间单位统一
SELECT /*+ _l_hot_only_(true), _l_ts_min_(1000), _l_ts_max_(2001) */ * FROM test WHERE p1>1;

这种情况一般发生在数据迁移或者修改表属性为冷热分离表后。此时系统尚未触发数据归档至冷存储，因此大量的冷数据滞留于热存储中，数据量的增大导致了查询效率的降低。需要对表执行major compaction操作来解决这一问题。具体语法，请参见ALTER TABLE。

这是因为主表和索引表的冷数据归档过程是独立的，并且归档主表和索引表冷数据的操作是周期性触发的，导致了主表和索引表滞留在热存储的数据不一致，进而出现查询到的冷数据不一致的现象。 您可以在查询条件中添加热数据的时间范围，避免此类问题的出现。

当前时间减去最旧的文件的生成时间大于冷数据归档周期时，则会触发冷数据转存。是否立刻触发compaction，取决于当前时间与最旧文件生成时间的差值。

支持，您可以参考按时间戳冷热分离的数据查询和按自定义时间列冷热分离的范围查询Scan，在查询时指定时间范围来实现冷数据的查询。需注意的是，容量型云存储和归档型云存储的读IOPS能力相对较低，因此查询可能会比较慢。