それなりの量のイベントログに相当するデータを保存したいとなったときに、DynamoDBを使う場合にどうするのが良いのか調べた自分用のメモです。
設計メモ
テーブル設計
1つのテーブルにデータを投入すると検索などのWCUを意識する必要が出てくるので、保存期間ごとに分けてテーブルを作成していく、というやり方があるらしい。
例えば以下のような形。
- 2025/05/10 のデータを保持するテーブル
- 2025/05/09 のデータを保持するテーブル
- 2025/05/08 のデータを保持するテーブル
- :
リアルタイムに保存する場合だと、日付の境目のデータをどう保存するか考える必要がありそうだが、バッチ処理なら良さそう。
Lambdaとかで事前にテーブルを作るというやり方が紹介されている。
パーティションキー
パーティションキーはテーブルのデータが格納されている論理パーティションになる。 例えば日付yyyy-mm-ddをパーティションキーとした場合、2025-05-10のデータは、DynamoDBの裏側では同じところに保存されるようなイメージになる。そうなるとI/O リクエストが分散されない。
そのため、今日の日付を表すパーティションキーの場合は、1 と N の間の乱数を選択し、それをサフィックスとして日付に連結する、などにすると良い。
- 2025-05-10.1
- 2025-05-10.2
- :
- 2025-05-10.128
特定の日のすべての項目を読み込むには、 2025-05-10.1.N キー (ここで N は 1 〜 128) をQueryする必要があり、アプリケーションはすべての結果をマージする必要があるという手間は発生する。 ただ、こうすると、IOが特定のパーティションに集中せず、分散できる、というメリットがある。
参考
- DynamoDB で時系列データを処理するベストプラクティス。 - Amazon DynamoDB
- Best practices for designing and using partition keys effectively in DynamoDB - Amazon DynamoDB
- Amazon DynamoDB の大量の時系列データの設計パターン | Amazon Web Services ブログ
- Automatically Archive Items to S3 Using DynamoDB Time to Live (TTL) with AWS Lambda and Amazon Kinesis Firehose | AWS Database Blog
- Explore AWS re:Post content | AWS re:Post
