1 ～ 7 日後の時系列データTTLs(ユースケースによって異なります)。データは不変で、タイムスタンプ順 ( cluster by timestamp) - データは「書き込み時」にタイムスタンプが付けられます (したがって、新しいデータのタイムスタンプは常にプログレッシブである必要があります)。
パーティションのサイズは 10,000 個のアイテムを超えてはなりません - 通常はそれよりもはるかに小さくなります (10MB完全な 10,000 個のアイテムの場合は最大で ~)。
圧縮戦略の構成方法 (考慮すべきパラメーター) に関する適切なドキュメントが見つからなかったので、次のようにすることにしました。
compaction = {'class': 'TimeWindowCompactionStrategy', 'compaction_window_size': '7', 'compaction_window_unit': 'DAYS'}
これが正しいかどうかは確かにわかりません
KPI考慮すべきことは何ですか?
唯一の正解はありません。
構成の結果、過去 7 日間に挿入されたデータはまとめて圧縮されます。TWCS の最大の利点は、SSTable 内のすべてのデータがすでに期限切れになっていることを認識しているため、SSTable 全体を読み取らずに期限切れにできることです。
この場合、1 日で TTL 処理したデータは、7 日間のウィンドウにまとめられるため、まだ期限切れになることはありません。最悪の場合、7 日間のウィンドウの終わりに挿入されたばかりのミューテーションが SSTable に含まれるため、その 1 つのミューテーションが期限切れになるまで、SSTable 全体がさらに 7 日間保持されます。
これは最適ではないように思えますが、少なくとも、単一の SSTable からそのウィンドウ内のデータのすべての読み取りを提供できます。逆に、たとえばウィンドウを 1 日に設定します。これにより、データの有効期限が大幅に短縮されますが、7 日間有効なデータの場合、1 つではなく 7 つの SSTable にアクセスすることになります。
概要：
時間枠が大きい: 有効期限が遅くなり、ライブ データの読み取りが速くなります。時間枠が小さい: 有効期限が短くなり、ライブ データの読み取りが遅くなります。
人生のほとんどのことと同様に、真実は真ん中にあります! 両方のオプションが機能しますが、これでトレードオフが理解できましたが、最適なウィンドウはおそらく 1 と 7 の中間です。