KVS(Key Value Store)における履歴データのキー設計
目次
- これは何？
- 履歴データのキー設計
- この設計をしない方が良いケース
- まとめ
これは何？
大量のデータを扱うようになったためDynamoDBやFirestoreなどのKVSを扱う機会が増えています。KVSであるDynamoDB、Cloud Firestore、Cloud Bigtableで大量データになりがちな履歴データの設計をする機会があったのでその時に考えた設計をまとめたもの。
履歴データのデータ設計
この記事で扱う履歴データとは、会員のログイン履歴や、行動履歴のような「時間+何らかのデータ」を新しい順 or 古い順に保持する時系列データのことを想定しています。
KVSにおいてまず最初に考えることは、「Keyを何にするか」だと思います。
KVSのKeyの特徴として大抵の場合、データはKeyの辞書順に並びます。（例えば、keyが a, 1, 2 という3つのデータがあった場合、ソートを指定せずに取得を行うと、1, 2, a という順番でデータが返ってくるということ）
この特性を使って履歴データを扱う際は、
のようにするとソートされた状態でデータを格納することができます。
これによりソートの指定をする必要がなくなり、複合Indexの設定を減らすことができる。
また、タイムスタンプだけでデータの登録をすると、データベースによっては読み込み&書き込みが一部のデータに偏りホットスポットができてしまうという問題があります。 親となるデータのID+タイムスタンプのようにすると処理するデータを分散し管理することができます。
データを絞り込んで表示したい場合は、DBによりクエリの指定方法は変わりますが文字列比較を行うKeyだけで絞り込むことができます。（Candidate_20200701 ≦ id < Candidate_20200801だと2020年の7月のデータを取得できる）
この設計はしない方が良いケース
時系列を使った絞り込みやソートを使わないケースでは、キーを有効活用できなくなるためこの設計はせずにデータの特性に合わせてキー設計をした方が良いです。
まとめ
- 履歴データを管理する際はTimestampを利用したキー設計にすると絞り込み、ソートが簡単に行える
- Prefixつけることでホットスポットになりづらいキー設計をすることができる
- 時系列で扱わない場合は別のキー設計にした方が良い
