この記事で扱う内容
時系列データの管理に関して、以下の２点について扱います。この二つの観点は関連しています。
- 分散環境における管理方法
- データ保存期間
分散環境における時系列データの管理方法
分散データベースでは、データのパーティショニング（あるいはシャーディング）が行われます。
このパーティショニングは、（明示的にであれ、潜在的にであれ）何らかの値をもとに行われます。
Apache Cassandraでは、明示的に、パーティションの基準とする値に用いるキーを指定します。
時系列データを管理する場合のパーティションキー設計のパターンとして「タイムバケッティング(time bucketing)」があります。
CREATE TABLE device (
deviceid INT,
monthbucket TEXT,
timestamp TIMESTAMP,
...
PRIMARY KEY ((deviceid,monthbucket),timestamp));
ここでmonthbucketには、例えば202308のようにtimestamp値を構成する年と月のデータを格納することが考えられます（これは、あくまで例であり、後述のデータ保存期間との関係で、異なる粒度を選択することが考えられます）。
このような設計にすることにより、以下の２点の効果があります。
- 検索性能
- データ分散
検索性能
データ検索時に限られたパーティション（/ノード/物理サーバ）にアクセスすれば済むため、検索性能があがります。
データ分散
上述の検索性能を実現するだけであれば、timestampカラム自体をパーティションキーにすることが考えられます。しかし、少し考えればわかるように、これはパーティションキーの種類が、すぎに膨大になり、無限に増殖することを意味します。一般にこのようにタイムスタンプ値自体をパーティショニングの基準にすることはアンチパターンといえます。「タイムバケッティング(time bucketing)」の手法を用いることで、このアンチパターンを回避しつつ、時系列情報を検索に用いることができます。
実例
以下は、クエリの例です。monthbucketを検索に用いると同時にtimestampでより詳細な時間を指定します。そのために、timestampカラムは検索可能なカラム（Cassandraにおけるクラスタリングキー）として設定されている必要があります。
SELECT * FROM device
WHERE deviceid='123' AND monthbucket='202303'
AND timestamp >= '2023-03-01 00:00:00-0500'
AND timestamp < '2023-03-16 00:00:00-0500';
分散環境における時系列データの保存方法
問題
時系列データの管理においては、データが持続的に増え続けることへの考慮が必要です。
つまり、特に何の配慮も行わない場合、検索性能は、（どれだけ技術的な最適化が行われていたとしても）論理的に下がり続けることになります。
ここでは、時系列データを管理するためのひとつのパターンについて紹介します。
データ管理において、よくある考え方としては、古いデータを退避する、というものがあります。このことによって、そのテーブルのデータの量は一定量に保たれ、検索性能について、一貫した性能を期待することができます。
よくある手法では、テーブルから古くなったデータを抽出し、オブジェクトストアなどの他の環境に保存し、元のテーブルから削除するという方法があります。この場合、以下の２点について考慮する必要があります。
- データの退避（移動）方法（ETLなどの活用）
- （退避先からの）データの検索方法（データベースとは別の検索方法）
これらは、時系列データを管理するデータベースとは、他の技術によって実現することになります。
TTL利用
Apache Cassandraのように、データベースにはテーブルのデータに有効期限/TTL(time to live)を指定することによって、一定期間の後に、有効期限が過ぎたデータを削除する機能があります。
データの格納時に、TTLが設定されたテーブルと、TTLが設定されていないテーブルの二つにデータを格納することによって、上述の二つの問題を同時に解決することができます。
この二つのテーブルは、以下のようなイメージになります。
LATEST_DATA_WITH_TTLHISTORICAL_DATA_WITHOUT_TTL
例えば、このテーブルへのクエリを行う要件の大部分（90%以上など）が、過去１か月のデータへのクエリである場合、TTLとして２か月程度（単純に現在時点から１か月前ではなく「先月のデータ」という要件も考慮すべき）を設定することが考えられます。このTTL期間設定は、クエリ要件と照らし合わせて、設計することになります。
この手法は、過去のデータをつねに（多少の検索性能は犠牲としても）アクティブな状態にしておきたいという要件を（オブジェクトストアへの別の検索手段を講じずに、たんに検索先テーブルを変更するだけで）満たすことができます。
また、このような手法と、従来の外部へのデータ退避とを組み合わせることも考えることができます。例えば、数か月前のデータをHISTORICAL_DATA_WITHOUT_TTLに移すことで、クエリの90%は、LATEST_DATA_WITH_TTLへのクエリとして予想された性能を確保します。その後、HISTORICAL_DATA_WITHOUT_TTLへのクエリ要件において、数年前のデータへのクエリ要件が例えば、1%以下であれば、その期間を超えるデータは、オブジェクトストアへ退避して、データベースの無制限のデータ容量を避けながら、1%以下のデータ検索の要件に対しては、マニュアル操作によるデータ復帰プロセスを含めて、例えばリクエストから一週間でデータ提供、といったサービスレベルを定めることが考えられます。
また、このことによりデータ退避処理期間中にテーブルへの検索性能が下がるといった問題についても、（検索要件の90%で）避けることができます。
参考情報