55

HTML ページ、画像、PDF などのファイルを PostgreSQL のテーブルに保存しても問題ありませんか?それとも遅いですか? これは推奨されないという記事をいくつか読みましたが、本当かどうかはわかりません。

私が念頭に置いている列の型はBLOB(ファイルに格納されていることがわかっている限り) またはbytea型ですが、他の型も適用できます。

4

2 に答える 2

79

基本的に2つの選択肢があります。データを行に直接格納することも、ラージオブジェクト機能を使用することもできます。PostgreSQLはTOASTと呼ばれるものを使用して大きなフィールドをテーブルから移動するようになったため、大きなデータを行に直接格納することに関連するパフォーマンスの低下はありません。フィールドのサイズには1GBの制限が残っています。これが制限されすぎている場合、またはストリーミングAPIが必要な場合は、データベース内のファイル記述子のようなものを提供するラージオブジェクト機能を使用できます。LO IDを列に格納し、そのIDから読み取りおよび書き込みを行うことができます。

個人的には、どうしても必要な場合を除いて、ラージオブジェクト機能は避けることをお勧めします。TOASTを使用すると、ほとんどのユースケースは、データベースを期待どおりに使用するだけでカバーされます。大きなオブジェクトの場合、使用したLO IDを追跡し、使用されなくなったとき（以前は使用されなかったとき）に必ずリンクを解除する必要があるため、メンテナンスの負担が増えます。永久にスペースを占めるデータディレクトリ。また、周囲に並外れた振る舞いをする施設もたくさんありますが、使用したことがないので細部が気になりません。

ほとんどの人にとって、データベースにビッグデータを保存することに関連する大きなパフォーマンスの低下は、特に指示しない限り、ORMソフトウェアがすべてのクエリでビッグデータを引き出すことです。Hibernateまたはこれらの列を大きいものとして扱うために使用しているものはすべて、特に要求された場合にのみフェッチするように注意する必要があります。

于 2012-03-07T17:09:38.150 に答える
17

BLOB (LO) タイプは、標準の PostgreSQL ヒープ ページ内の 2KB のチャンクにデータを格納します。デフォルトのサイズは 8KB です。それらはファイル システムに独立したまとまりのあるファイルとして保存されません。 Postgres ヒープ ページ ヘッダーと、チャンクを区切る構造も存在するため、データベースにロードされます。

アプリケーションがバイナリ データを頻繁に更新する必要がある場合、特に PostgreSQL が同時実行制御 (MVCC) を実装する方法が原因で、小規模なランダム アクセス書き込みが多数含まれる場合は、Large Object (LO) インターフェイスの使用を避ける必要があります。データベースを VACUUM するまで、使用されるディスク容量が爆発的に増加する可能性があります。同じ結果は、おそらくbytea型または TOASTされた列にインラインで格納されたデータにも当てはまります。

ただし、データが Write-Once-Read-Many パターンに従っている場合 (たとえば、PNG 画像をアップロードし、後で変更しない場合)、ディスク使用の観点からは問題ありません。

詳細については、この pgsql-general メーリング リスト スレッドを参照してください。

于 2014-11-21T00:16:22.450 に答える