データベース非正規化の利点の予測

私は常に、データベースの正規化の最高の正規形を追求するように教えられ、3NFを達成するためのバーンスタインの合成アルゴリズムを教えられました。これは非常によくできており、一貫性を維持しながらフィールドを変更できることを知って、データベースを正規化するのは良い感じです。

ただし、パフォーマンスが低下する可能性があります。ですから、非正規化時にスピードアップ/スローダウンを予測する方法があるのか​​と思います。このようにして、3NFを特徴とするFDのリストを作成し、可能な限り非正規化することができます。非正規化が多すぎると、スペースと時間が無駄になると思います。たとえば、巨大なブロブが複製されたり、トランザクションを使用して複数のフィールドを更新する必要があるために一貫性を維持することが困難になったりするためです。

概要：3NF FDセットと一連のクエリがある場合、非正規化のスピードアップ/スローダウンを予測するにはどうすればよいですか？論文へのリンクも高く評価されています。

DBモデルのパフォーマンスを確認するには、テーブル間のデータフローを知っている必要があります。それが得られたら、特定の非正規化のパフォーマンスの変化を計算できます（データを複製する場合など）。

いくつかの大まかな見積もりは、非正規化手順の後に必要になる新しいインデックスの数によって推定できます。新しいインデックスごとに個別に更新およびクエリを実行する必要があります。これにより、新しいインデックスの数に比例してパフォーマンスが低下します。

バイナリデータの大きなblobは、どのような場合でも別のテーブルに保存し、コピーしないでください。それらは（通常）照会されませんが、他のいくつかのテーブルセットに対するクエリの後に、最終結果セットの一部として返されます。

いつ非正規化が役立つかについての学術的研究があるかどうかはわかりません（IMHOは、DB正規化について教えられていることと実際にどのように機能するかの間にはかなり大きな違いがあります）。

ただし、これに関する興味深い記事やブログエントリがいくつかあります。JeffAtwoodは彼のブログでの正規化について語っています。また、高いスケーラビリティで彼への「返信」があります。

非正規化するとき、私はあなたに注意を払うことを勧めます

• 単位時間あたりのクエリの数とタイプ。読み取り以上の挿入や更新を使用する場合、非正規化はあまり役に立ちません。
• 複製された情報が更新される頻度
• 使用するDBMSの特性
• 情報が重複する回数。同じ情報が4〜5個のテーブルにある場合は、何度もコピーするよりも、別のテーブルに保持する方が速い場合があります。
• DBに保持されると予想されるデータ量。少量のデータで機能する可能性のあるものは、レコード数が増加すると障害につながる可能性があります。そしてその逆（私はKISSの原則を意味し、壊れていないものを修正しない）。

非正規化しすぎると、スペースと時間が無駄になると思います

ほとんどの中規模の基幹業務OLTPアプリケーションでは、スペースについて心配する必要はありません。したがって、スペースを確保してください。時間、そして私はあなたがクエリのパフォーマンスを意味すると仮定しますが、これは通常は強化することができ、設計が悪い、リソースが不十分、データベースが非常に大きい、トランザクションの数が非常に多い、またはすべてでない限り、実際の問題を引き起こしません上記。今日のデータベースを使用するほとんどのアプリケーションでは、データベースが正規化されているという理由だけでパフォーマンスの問題が発生することはほとんどありません。

巨大なブロブが重複しているか、トランザクションを使用して複数のフィールドを更新する必要があるため、一貫性を維持することが難しいためです。

データベースを正規化すると、設計で次のことが保証されます。

1. 冗長データはありません。

2. 膨大な数のログ腸炎が作成されないようにする（例：200万人の顧客のテーブル：UPDATE Customer Set Country = "USA" WHERE Country = "US"）

3. SQLクエリで完全にサポートされます。この点は非常に重要です。

4. クリーンなアプリケーションコードを実行します。

5. アプリケーションに負担をかけずに、データベースを介して高度なデータ整合性を強制します。

6. 異なるアプリケーションで同じコードをコーディングせずに、異なるアプリケーションによってデータベースで定義されたビジネスルールを共有します。

とはいえ、正規化はすべての列とテーブルに最適な構造を生成します。これは、特定のアプリケーションで常に必要とは限らない場合があります。ドメインとアプリケーションを理解した上で、速度のトレードオフとしてテーブル/列の一部を非正規化することを決定できます。ただし、それは見落としではなく意識的な決定です。

3NF FDセットと一連のクエリがある場合、非正規化のスピードアップ/スローダウンを予測するにはどうすればよいですか？

テストなしでパフォーマンスを正確に予測することはできません（アプリケーションコードを記述する前に行うことができます）。ただし、設計により、パフォーマンスの低下につながる要因を排除して検出できます。たとえば、次のように使用するインデックス戦略を特定できます（他の手法が存在する場合があります）。

1. クエリとそれらのクエリの影響を受ける列のマトリックスを作成します。

2. 最も使用されている列を見つけます。

3. それらの列にインデックスを作成することを検討してください。

これは主に、DBAが支援できる仕事です。パフォーマンスには、正規化以上のものがあります。ディスクボリュームへのデータ分散、垂直テーブル分割、パーティション化、インデックスタイプ、インデックスバッファリングなどの側面があります。このような手法はすべて、「データベースの設計」および「データベースのパフォーマンスチューニング」という主題の本やベン​​ダーのドキュメントで対処する必要があります。上記の説明はすべて、アプリケーションがOLTPアプリケーションであることを前提としています。

正規化するいくつかの主要な理由の1つは、一般的なユースケースに対して最適化する一方で、非正規化は特殊な​​ユースケースに対してパフォーマンスを最適化する傾向があることです（他のユースケースには大きなペナルティがあります）。これが、通常OLTPワークロードが主に正規化の恩恵を受ける理由の1つです（ここでは例外がありますが、まれです）。

利点を予測するために、あなたが本当に知っておくべきことは、あなたがどのワークフローに対してどのように非正規化しているのかということです。また、データセットのサイズと、キャッシュの影響がどのようなものになるかについての質問もあります。そのため、答えは、データベースのサイズ、メモリに残っている可能性のある部分、複雑なクエリのオーバーヘッドの計画など、非常に多くのことに依存する可能性があります。これは非常に複雑な実装固有の問題であり、データベースとRDBMSの両方に大きく依存します。これらの利点はOLAPワークロードで最大になり、通常、欠点はOLTPワークロードで最大になります。

したがって、クエリプランを監視する以外に、ここで単一の回答があることはわかりません。私の見解では、最善のアプローチは、比較的正規化されたOLTPデータベースを用意し、必要に応じてレポート目的で非正規化することです。

通常、データモデルを非正規化して、特定のユースケースのパフォーマンスを最適化します。これは通常、他のユースケースのパフォーマンスに悪影響を及ぼします。たとえば、複数の行でデータを繰り返すと、結合がなくなるためクエリ処理が速くなりますが、更新処理は遅くなります。

事実上、3NFはデータベースへの任意の数の任意のアクセスに対して最適なパフォーマンスを提供しますが、特定の結合と選択については、より良いモデルが存在する場合があります。

したがって、他の最適化と同様に非正規化を扱います。つまり、実際にパフォーマンスの問題がない限り、それを行わないでください。また、「修正」によって、解決する以上の問題が発生しないことを確認してください。