多くのイベントを保存するデータベースを作成しています。それらはたくさんあり、それぞれに秒単位の正確な時間が関連付けられています。例として、次のようなものがあります。
Event
-----
Timestamp
ActionType (FK)
Source (FK)
Target (FK)
アクション、ソース、およびターゲットはすべて 6NF にあります。テーブルを正規化したままにしたいのですEvent
が、考えられるすべてのアプローチには問題があります。データに対する私の期待を明確にするために、大部分 (99.9%) のイベントは上記の 4 つのフィールドだけで一意になります (したがって、行全体を PK として使用できます)。ただし、いくつかの例外は無視できません。 .
代理キーを使用する: 4 バイトの整数を使用する場合、これは可能ですが、理由もなくテーブルを膨らませているように見えます。さらに、データベースを長期間使用してキースペースを使い果たすことも懸念しています。
カウント列をイベントに追加:カウントが小さいと予想されるため、より小さいデータ型を使用できます。これにより、データベース サイズへの影響が小さくなりますが、挿入前にアップサートまたはデータベース外でデータをプールする必要があります。どちらも複雑さが増し、データベース ソフトウェアの選択に影響を与えます (アップサートを行う Postgres を使用することを考えていましたが、喜んでではありませんでした)。
イベントを小さなグループに分割する:たとえば、同じ秒内のすべてのイベントは
Bundle
、グループの代理キーとその中の各イベントの代理キーを持つことができる の一部である可能性があります。これにより、抽象化とサイズの別のレイヤーがデータベースに追加されます。そうでなければ重複したイベントが一般的になれば良い考えですが、それ以外の場合はやり過ぎのように思えます。
これらはすべて実行可能ですが、私のデータにはあまり適していないように感じます。メインテーブルに一意性制約を適用せずに典型的なSnowflakeを実行することを考えていましたが、このEvent
ようなPerformanceDBAの回答を読んだ後、もっと良い方法があるのではないかと思いました.
では、正規化された少数の繰り返しイベントで時系列データを保持する正しい方法は何ですか?
編集:明確化 - データのソースはログで、ほとんどがフラット ファイルですが、いくつかはさまざまなデータベースにあります。このデータベースの 1 つの目標は、それらを統合することです。秒単位よりも正確な時間分解能を持つソースはありません。このデータは、「一定間隔でターゲットに対してアクションを実行した異なるソースの数は?」などの質問に使用されます。ここで、Interval は 1 時間以上です。