[解決済み] スケーラビリティを考えるとき、なぜ結合はよくないのか？

質問

なぜ結合は悪いのか、遅いのか。私はこれを何度も聞いたことがあります。私はこの引用を見つけた

問題は、結合が比較的 特に非常に大きなデータセットでは 遅い場合、ウェブサイトも遅くなります。 ウェブサイトが遅くなることです。そのため をディスクから取り出して ディスクから情報を取り出し、それらを また一緒にするのに長い時間がかかります。

ソース

私はいつも、特にPKを調べるときに速いと思っていました。なぜ「遅い」のでしょうか？

どのように解決するのですか？

スケーラビリティとは、作業単位あたりのリソースの使用を最小限に抑えるために、事前計算 (キャッシュ)、分散、または繰り返される作業の必要最低限への縮小をすべて意味します。うまくスケーリングするには、大量に必要でないことは何もせず、実際に行うことはできるだけ効率的に行うようにします。

この文脈では、もちろん、2つの別々のデータソースを結合することは、少なくとも結合しない場合と比較して、比較的遅いです。

しかし、その代わりに、2 つの別々のデータをまったく持たなくなることを忘れないでください。2つの異なるデータを組み合わせることは、どこかで結果を伴わないので、トレードオフを理解していることを確認してください。

良い知らせは、最新のリレーショナル データベースは 良い であることです。優れたデータベースをうまく使えば、結合が遅いと考える必要はないでしょう。スケーラビリティに適した方法はいくつもあります。 多くの より速くなります。

• 自然キーではなく、サロゲートキー（autonumer/identityカラム）で結合します。これは、結合操作中の比較の規模が小さくなる (したがって速くなる) ことを意味します。
• インデックス
• マテリアライズド/インデックス付きビュー (これは事前計算されたジョインまたは マネージド 正規化解除)
• 計算されたカラム。これを使用して、Joinのキーカラムをハッシュ化したり、その他の方法で事前計算することができます。Joinでは複雑な比較になるものが、はるかに小さくなり、事前インデックスが付く可能性があります。
• テーブル・パーティション (複数のディスクに負荷を分散させることで、大規模なデータセットに役立ちます。また、テーブル・スキャンをパーティション・スキャンに制限することもできます)
• OLAP (特定の種類のクエリー/結合の結果を事前に計算する。とは言えないが、次のように考えることができる。 汎用 非正規化)
• レプリケーション、可用性グループ、ログシッピング、または複数のサーバーが同じデータベースの読み取りクエリに応答するためのその他のメカニズムにより、ワークロードを複数のサーバー間でスケールアウトします。
• Redis のようなキャッシュ層を使用し、複雑な結合を必要とするクエリの再実行を回避します。

私はここまで言って リレーショナルデータベースが存在する主な理由は、効率的に結合を行うことができるようにするためです。 ^* . 構造化されたデータを保存するためだけではありません（csvやxmlのようなフラットファイル構造でも可能です）。私がリストアップしたオプションのいくつかは、事前に結合を完全に構築することも可能です。

もし結合が遅いのであれば、おそらくデータベースを正しく使用していないのでしょう。

正規化解除は、これらの他の手法が失敗した後にのみ行われるべきです。そして、本当に"失敗"を判断できる唯一の方法は、意味のあるパフォーマンス目標を設定し、その目標に対して測定することです。 測定していないのであれば、非正規化について考えるのは時期尚早です。

_{* つまり、単なるテーブルのコレクションとは異なるエンティティとして存在することです。 本物のRDBMSのもう一つの理由は、安全な同時アクセスです。}