Lindorm:コールド・ホットデータ分離 よくある質問

Lindorm は、コンパクション プロセスを通じて、ホットストレージからコールドストレージへコールドデータを非同期でアーカイブします。デフォルトでは、システムがこのプロセスを「ホット／コールドデータ境界期間」の半分の間隔で自動的にトリガーします。最小間隔は 1 日、最大間隔は メジャーコンパクション の実行間隔の半分です。デフォルトの メジャーコンパクション 間隔は 20 日です。たとえば、ホット／コールドデータ境界が 3 日の場合、コンパクション アーカイブタスクは 1.5 日ごとに自動的に実行されます。境界が 1 日の場合は、コンパクション タスクが 1 日に 1 回実行されます。

はい。HBase Shell で major_compact 'tableName' コマンドを実行することで、コンパクション を強制的に実行できます。これにより、ホットストレージからコールドストレージへコールドデータがアーカイブされます。

これは、書き込んだデータがまだディスクにフラッシュされていない場合に発生します。まず flush 操作を実行してデータをディスクに書き込み、その後 compaction 操作を実行してデータをコールドストレージへ移動してください。コンパクション 操作は以下の方法で実行できます：

• HBase Shell で major_compact コマンドを実行します。

• Lindorm-cli を使用している場合は、正しい構文については ALTER TABLE をご参照ください。

• コンパクション のバックログが発生すると、ホットデータのコールドストレージへの移動速度に影響します。この場合、スケーリングまたは構成のスペックアップにより CPU リソースを増強し、コンパクション のバックログを解消する必要があります。

  説明

  コンパクション のバックログは、インスタンスモニタリングページで確認できます。テーブルメトリクス - クラスタ負荷 セクションに移動し、「Compaction Queue Size(count)」メトリックを確認してください。値が継続的に 0 より大きく、増加傾向にある場合、コンパクション のバックログが発生しています。詳細については、「モニタリング情報の表示」をご参照ください。

• LindormTable の最新バージョンを使用していない場合は、最新バージョンへアップグレードしてください。新しいバージョンでは、コールドデータのアーカイブが高速化されています。現在のバージョンの確認やアップグレード手順については、「LindormTable のリリースノート」および「マイナーバージョンの更新」をご参照ください。

• その他のご質問がある場合は、テクニカルサポート までお問い合わせください。

更新によってカスタム時刻列の値が変更されない限り、データは引き続きコールドのままです。一方、カスタム時刻列の値を更新した場合、システムは新しい時刻値に基づいて、そのデータがホットかコールドかを再評価します。たとえば、プライマリキー列が p1 および p2、非プライマリキー列が c1 および c2 であるテーブルを考えます。ある行の値が p1=row1、p2=2023-01-28、c1="c1"、c2="c2" であり、ホット／コールドデータ境界が 1 日、現在日付が 2023-01-30 の場合、この行はコールドデータと見なされます。c1 および c2 の値を更新しても、行は引き続きコールドデータのままです。ただし、p2 の値を 2023-01-30 に更新すると、その行はホットデータになります。その後、2023 年 2 月 1 日に、そのデータの経過時間が 1 日の境界を超えると、再びコールドデータとして再分類されます。

いいえ。システムは、ホット／コールドデータの分離にカスタム時刻列に依存しています。この列の値が欠落している行は、常にホットストレージに残ります。

いいえ。データを更新すると、そのタイムスタンプも更新されるため、データはホットデータになります。

クエリでホットデータのみを取得するには、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」をご参照ください。

これは、プライマリテーブルとインデックステーブルがそれぞれ独立したコールドデータアーカイブプロセスを持つためです。両テーブルともアーカイブは定期的に行われるため、各テーブルのホットストレージに残留しているコールドデータの量が異なる場合があります。その結果、クエリ結果が不一致になることがあります。この問題を回避するには、クエリ条件にホットデータの時間範囲フィルターを追加してください。

システムは、最も古いデータファイルの経過時間が設定されたアーカイブ期間を超えた時点で、コールドデータをアーカイブするための コンパクション をトリガーします。即座に実行されるかどうかは、現在時刻と最も古いファイルの作成時刻との差異によって決まります。

はい。スキャン操作で時間範囲を指定することで、コールドデータをクエリできます。詳細については、「タイムスタンプによるデータ分離のクエリ」および「カスタム時刻列によるデータ分離のスキャンおよびクエリ」をご参照ください。なお、キャパシティ最適化ストレージおよびアーカイブストレージタイプにおける読み取り IOPS は比較的低いため、これらのクエリは遅くなる可能性があります。