時系列コンパクション (TSCS)
SSTable を固定時間ウィンドウでまとめ、最近のウィンドウは通常どおりコンパクションし、閉じたウィンドウはウィンドウごとに1つに凍結し、保存期間を過ぎたウィンドウはコンパクションなしで丸ごと削除するコンパクション戦略です。
TSCS はコンパクション戦略であり、階層型ストレージは テーブル拡張です。どちらか一方だけでも有効にでき、TSCS を先に有効にする方がリスクは低いです。
設定
ALTER TABLE pp.tm_tag_point WITH compaction = {
'class': 'TimeSeriesCompactionStrategy',
'window_size': '1d',
'freeze_after': '2d',
'retention': '3650d'
};
| オプション | デフォルト | 意味 |
|---|---|---|
window_size | 1h | ウィンドウ1つの幅。SSTable は最大タイムスタンプでウィンドウに割り当てられます |
freeze_after | 2h | ウィンドウが閉じてからこの時間が経過すると凍結対象。遅延データを受け入れる余裕です |
retention | なし | これより古いウィンドウは丸ごと削除。指定しないと何も期限切れになりません |
max_future_window | 1d | これより先の未来のウィンドウはすべての自動パスから除外 |
timestamp_resolution | MICROSECONDS | セルのタイムスタンプ単位。変更する必要はほとんどありません |
window_size はクエリパターンに合わせてくださいダッシュボードが日単位で見るなら 1d が自然です。ウィンドウが細かすぎると SSTable 数と
ウィンドウ管理コストだけが増えます — 10年保存で 1h ウィンドウならウィンドウが87,600個になります。
ウィンドウのライフサイクル
[현재 창] [닫힘, freeze_after 이내] [동결됨] [만료]
────────────────┼───────────────────────────┼─────────────────┼──────────────
UCS 에 위임 여전히 UCS 창당 1 SSTable 통째로 삭제
(평소 컴팩션) (지각 데이터 흡수) 이후 손대지 않음 (컴팩션 없음)
現在のウィンドウと閉じたばかりのウィンドウは内部の UnifiedCompactionStrategy に委任します — 書き込みが活発な
領域はアップストリーム UCS のまま動作します。
🔴 期限切れは retention が担当します — TTL ではありません
retention を指定しないと何も期限切れになりません。 行単位の TTL を設定していても
TSCS のウィンドウ削除とは別の話です。
ウィンドウ単位の削除が優れている理由は、コンパクションをせずにファイルを削除するからです。TTL で期限切れにすると トゥームストーンを作成し、コンパクションで除去する必要がありますが、時系列のように「古いものは丸ごと捨てる」データに そのコストは無駄です。
遅延データの隔離
通信が切断されていたエッジが数日分を一括でアップロードしても、フラッシュとストリーミングがウィンドウ境界で分岐します。 そのため遅延データは属する過去のウィンドウに別途配置され、最近のウィンドウに触れて再コンパクションを引き起こすことは ありません。ウィンドウをまたいでいる古い SSTable は自動的に分割されます。
パークされたウィンドウ — 進捗が出ないウィンドウ
ウィンドウが凍結に移行できずに停止している状態を「パーク」と呼びます。原因は1つ — ルーティングバッファのオーバーフロー です。診断と値の調整はオペレータードキュメントに記載されています。
確認
-- 지금 이 테이블에 걸린 컴팩션 설정
SELECT compaction FROM system_schema.tables
WHERE keyspace_name = 'pp' AND table_name = 'tm_tag_point';
関連項目
- 階層型ストレージ — 古いウィンドウを圧縮まで行う場合
- 時系列データベース概要