1つの大きなテーブルといくつかの小さなテーブル

Question

以下の例は単なる例であり、私のシナリオはもっと複雑であり、私がそれをモデル化しようとしている方法は本当に理にかなっていることに注意してください

アプリの1つで監査イベントのテーブルを作成しているとしましょう。「event_created」、「user_created」などすべての種類のものです。テーブルにはいくつかの列が含まれており、それらのいくつかは他のテーブルへの外部キーです。時間の経過とともに、この単一のテーブルは数百万のレコードに成長する可能性があります。

パフォーマンスの観点から、それらすべてに単一のテーブルを使用するのか、またはイベントの種類ごとに個別のテーブルを使用して個別のテーブルで操作するのがより速く、より高性能ですか？それともそれほど違いはありませんか？イベントの種類ごとに個別のテーブルを作成するのはばかげているように聞こえるかもしれませんが、私の現実のシナリオでは、それは本当に理にかなっていると私を信頼する必要があります。

Basil Bourque · Accepted Answer

最後の手段としてのみ非正規化

架空のパフォーマンスの問題のために、テーブル設計を非正規化しないでください。時期尚早の最適化に陥らないようにしてください。

適切な構造を設計します。偽のデータを生成してテーブルに入力します。展開シナリオに類似した状況でテストを実行します。重大なパフォーマンスの問題が証明された場合：

EXPLAIN＆ANALYZE機能を使用して問題の性質を調査する.
- index の使用を調べます。既存のインデックスが期待どおりにクエリで使用されたことを確認します。そうでない場合は、別の方法でクエリを書き直してください。必要に応じてインデックスを追加します。
Postgresのチューニング方法を研究してください。
- サイズのキャッシュを学びます。
- Postgresサーバーをチューニングする他の方法を学ぶ。
- オンラインビデオまたはスライドを使用して、いくつかの会議の講演を確認します。
- 公式の Postgresメーリングリストを検索してください。
- Postgresユーザーグループ会議、または Postgres会議に参加します。
- 検索DBAスタック交換。
partitioning を使用してストレージ内の行を物理的に分離することを検討してください。エンタープライズ品質のソリッドステートストレージなどのより高速なストレージを追加することを検討してください。このストレージには、最も頻繁にアクセスするデータを保存するか、 Big Cheese 。
一部のロジックをアプリからデータベースサーバーに移動しようとしています PL/pgSQL などの言語で関数を記述して、すべてのデータを実行コードに対してローカル。
[〜＃〜] raid [〜＃〜] デバイスに、より大きなキャッシュユニットをインストールします。状況に応じて、キャッシュを調整して、読み取りと書き込みにより多くの割り当てを行うことを検討してください。多くの場合、デフォルトは50〜50です。
（ちなみに、データベースや他のファイルの破壊を避けるために、RAIDの write-cacheがバッテリーでバックアップされていることを確認してください）。
- または、RAIDの代わりに [〜＃〜] zfs [〜＃〜] を使用する場合は、より高速なドライブでデータベースを優先するようにチューニングする方法を学びます。
Postgresの専門家を雇って、テストとチューニングに関する相談を受けてください。

実証済みのパフォーマンス問題を修正するための手段をすべて使い果たした後でのみ、非正規化を検討する必要があります。

Postgresは強力なエンタープライズ品質のデータベースシステムです。十分なRAMおよび最新のハードウェアで数百万行があり、賢明なインデックス付けはまったく問題ありません。

一方、異なるタイプのイベントが異なるエンティティを表す場合、それらは別々のテーブルに保持する必要があります。類似した種類の行が異なるエンティティであるかどうかをどのようにして知ることができますか？手がかりは、「セマンティクスが同じでほとんど同じ列を持っていますか？」ユーザーが一緒に表示またはレポートしたいと思ったことはありますか？一緒に集計（カウント、平均、中央値などを計算）したいと思ったことはありませんか？

コンピュータハードウェアの機能と構成が今日のハードウェアよりもはるかに制限されていた時代にさかのぼる長い歴史を持つ製品として、Postgresのデフォルトの設定はかなり保守的です初期インストール時。たとえば、デフォルトでは、Postgresは古い Raspberry Pi ！したがって、より高性能なハードウェアでより大きなデータベースを実行している人は、何らかの調整を行う必要があります。