3

Postgres を分析 (スター スキーマ) に使用します。数秒ごとに、約 500 種類のメトリクスに関するレポートが取得されます。最も単純なスキーマは次のとおりです。

timestamp      metric_type     value
78930890       FOO              80.9
78930890       ZOO              20

当社の DBA は、同じ 5 秒間のすべてのレポートを次のように平坦化することを提案しました。

timestamp   metric1     metric2     ...  metric500
78930890    90.9        20          ...

一部の開発者はこれに反論し、これにより開発が非常に複雑になり (データをバッチ処理して 1 回で書き込む)、保守性が低下します (テーブルを確認したり、フィールドを追加したりするのはより複雑です)。

DBA モデルはそのようなシステムの標準的な方法ですか、それとも元のモデルが明らかに十分にスケーラブルでない場合の最後の手段ですか?

編集: 最終的な目標は、ユーザーの折れ線グラフを描画することです。したがって、クエリはほとんどの場合、いくつかのメトリックを選択し、それらを時間単位で折り畳み、1 時間 (またはその他の期間) ごとに最小/最大/平均を選択します。

編集: DBA 引数は次のとおりです。

  1. これは 1 日目から関連していますが (以下を参照)、そうでなかったとしても、システムが最終的に行う必要があるものであり、別のスキーマからの移行は面倒です。

  2. 行数を 500 倍減らすと、より効率的なインデックスとメモリが可能になります (この最適化前のテーブルには数億行が含まれます)。

  3. 複数のメトリックを選択する場合、提案されたスキーマでは、メトリックごとに個別のクエリ (または OR と GroupBY の複雑な組み合わせ) の代わりに、データを 1 回渡すことができます。

編集: 500 メトリクスは「上限」ですが、実際にはほとんどの場合、5 秒あたり ~40 メトリクスしか報告されません (ただし、同じ 40 ではありません)。

4

1 に答える 1