「データベースに大きなblobを格納するとパフォーマンスが低下する」とはどういう意味ですか？

データベースの内部を知っている人にとって、これは簡単な質問かもしれませんが、データベースに大きなBLOB（たとえば、400 MBの映画）を格納するとパフォーマンスが低下することになっている理由を明確に説明できますか？これはインターネット全体でよく見られる申し立てですが、実際に説明されたことはありません。

具体的には、SharePoint / MSSQLのパフォーマンス、つまりファイルアップロードのパフォーマンス、サイトの閲覧、リストの表示、ドキュメントのオープンなどについて言及しています。データベースが大きくなりすぎると、動作が遅くなると言われています。ファイルシステムへのBlobの外部化（SharePointではリモートBlobストレージと呼ばれ、データベースからファイルを移動し、参照のみを残します）はこれをある程度解決するはずですが、正確には-最下位レベルで-違いは何ですか？データベースに巨大なファイルが保存されている場合、バックアップに時間がかかることは明らかです...しかし、どの操作が正確に影響を受け、その基本的なメカニズムは何ですか（つまり、データベースの外部のファイルシステムに保存されているファイルは、どのようにアクセスまたは保存されますか？）

列を含む単純なテーブルをID(guid, PK), FileName(string), Data(varbinary(max))考えてみてください-大きなData列は、Webサイトにファイルのリストを表示する（内部的には実行することを意味しますSELECT FileName FROM table）、または新しい行を挿入するなどの操作を本当に遅くしますか？実際のバイナリコンテンツの列にインデックスが付けられるのとは異なります。

このような質問が既に出されていることは知っていますが、十分な説明が見つかりません。

これは本当にDBシステムに依存しますが、BLOBで考慮しなければならない1つの主要なことはトランザクション処理です。ファイルシステムへの外部化により、トランザクションからバイナリデータへの変更を行います。これにより、DBが完全なロールバックメカニズムなどのACIDコンプライアンスを保証する状況とは対照的に、通常は書き込み操作が高速になります。

また、実際にはBLOBデータを選択せずにBLOBテーブルからデータベースからデータを取得すると、読み込み操作が遅くなる可能性もあります。これは、DBがディスクにローカライズされた残りの行を格納し、読み込みアクセスが高速になるためです（ただし、ほとんどの場合）最新のDBシステムは、実際のバイナリデータを別のディスク領域またはテーブルスペースに格納するのに十分に優れているため、これを実際のシナリオでテストしないと、ここで一般的な仮定を行うことはできません）。

これは通常、帯域幅の問題です。1時間に数百本のビデオを配信している場合、データベースの内外で帯域幅を占有し、主にバッファをコピーしています。テーブルからすべての列を選択するだけの単純なクエリ（ORMツールによって自動生成される可能性がある）がある場合も問題になります。また、ファイルシステムのように（この場合はレコードの断片化を除く）ファイルの断片化の影響を受けますが、（通常は）断片化を解消するためのツールがありません。BLOBも変更している場合（たとえば、何らかのビデオ編集をサポートしている場合）、データベースはBLOB全体をロールバックまたはREDOセグメントにコピーし、更新されたBLOBをデータベースに書き込みます。これで、数百メガバイトをコピーしています。

SQL ServerのFileTableを調べてください。アイデアは、ファイルシステムレベルのアクセスとパフォーマンス、データベースへのアクセス、統合されたセキュリティとサービスを提供することです。データベースには、場合によってはオーバーヘッドのパフォーマンスがあります。Webサーバー上のハードコードされたHTMLファイルを、データベースからコンテンツをフェッチする必要があるファイルと比較するだけです。

データベースにblobを格納することが見つからなかったアプリケーションがパフォーマンスの大きな制限であると想像してみてください。しかし、アプリはそれまでのところまで成長しました。FileTableを使用したコーディングの変更はほとんどありません。また、多くのコーディングを行わなくても、データベースレベルとファイルレベルでトランザクションを管理できます。ファイルとメタデータはSQLで利用できます。

Windows Serverでは、データベーストランザクションオーバーヘッドを使用せずにファイルにアクセスするための共有ドライブが作成されます。

これは、MicrosoftがSQL Server 2012で「そのまま」処理しようとした一般的な問題です。アップグレードを正当化するための悪い機能ではありません。

これが醜い理由を知るには、データベースがハードドライブに保存される方法（具体的には行）を知る必要があります。ディスクに保存された行の物理的な内容は、静的なものと動的なものに分けられます。固定長のint、byte、char（n）などのフィールドが最初にリストされます。以下は、固定長の数です。これは、従う可変長フィールドの数を指します。すべての可変フィールド（プログラマーに提示される列の順序に関係なく）が最後に追加され、可変長フィールドが占めるスペースの量を決定する固定長の数がそれぞれに追加されます。

具体的な例を挙げましょう。私のテーブルが次のとおりだとします：

char(3) A
varchar(4) B
int C

今、私がそうするとしますINSERT INTO mytable (A, B, C) VALUES ('AAA', 'B', 256)。データベースでは、その行はおそらく次のように格納されます。

フィールドAは期待どおりに保存されます。「A」を挿入した場合、最初の文字の後に文字列の途中の終わりを示す特殊文字が提供されますが、同じスペースを占有します。

フィールドCは、256に相当するバイナリとして保存されます。なぜBではなくCなのですか？Cは固定長の次の静的フィールドであるため、データベース行の他のすべての静的データと一緒にグループ化されます。

フィールドDはデータベースのメタ情報であり、次の可変長フィールドセクションでは、フィールドが1つだけあることを示しています。

フィールドEもデータベースのメタ情報であり、この特定のフィールドの場合、長さが最大1文字であることを示しています。そうでない場合、データベースはフィールドBが終了し、別の可変長フィールドが開始する場所を認識できないため、この情報は不可欠です。

これはすべて、データベースが可変長フィールドを保存する方法を示しています。BLOBは、この効果にとって非常に可変長のフィールドです。データベース構造では、1つの行にBLOBの小さい値と大きい値の両方を含めることができますが、ここでは他の要素が関係しています。ディスクは内容を気にせず、1つのチャンクに収まるかどうかに関係なく、データベースは通常、情報のチャンクを扱います。

データベースは、行を2つに分割する必要なく、同じ数の行を1つのチャンクに収めようとします。それ以外の場合、効果は、ハードドライブに断片化されたファイルがある場合と同じです。1つのチャンクがロードされると、行がその特定のチャンクをオーバーフローした場合、ハードドライブは残りのチャンクを別のチャンクで検索する必要があります。さらに悪いことに、行が可変長であるため、内容を完全に読み取らなければ、行がチャンクより多くを占めていることをデータベースが認識できないため、一度に両方のチャンクをフェッチして最適化することはできません。

このロジックに従って、静的な長さのBLOBを作成できたとしても、データベースはチャンクサイズが最小行サイズより大きいことを保証するだけなので、ほとんどの行が確実に実行されないため、この最適化の問題はありません。複数のチャンクに分割する必要があります。もちろん、データベースはこれを実行しません。なぜなら、おそらく必要ないときに貴重なスペースを専用にすることになるからです。

BLOBは、比較的少量を扱う場合には問題ありませんが、ビデオなどの大きなファイルの場合、一般的な回避策は、ファイルパスをデータベースに保存し、ソフトウェアがほとんど常にファイルのロードを処理するようにすることです効率的です。

それがそれを説明することを願っています。:)