3

これはロングショットかもしれませんが、とにかくお願いしたいと思いました。

HerokuにデプロイしているアプリとHerokuの新しいCranePostgresDB（400 MB RAMキャッシュ）を組み合わせて使用​​することを検討しています。400 MBのキャッシュサイズは、私たちのニーズに十分なはずです...キャッシュされたPDFファイルを文字列として格納する1つのテーブルの1つの列を除きます。Herokuがキャッシュを使用している場合、PDFは400MBのRAMをすぐに使い果たす可能性があります。

実際のサーバーを使用している場合は、PDFをファイルとして保存するだけですが、Herokuのエフェメラルファイルシステムを考えると、S3への接続をリギングするのではなく、PDFをDBに保存するだけで、私の生活ははるかに簡単になります。これは1つです。（クライアントごとに1つずつ、複数のherokuインスタンスをデプロイすることを検討していることはさらに複雑です...したがって、DBを使用する方が、それぞれに新しいバケットを作成するよりも簡単です。）これの速度はあまり気にしません。人々がファイルを取得している場合、ほとんどのファイルのダウンロードが行われる方法であるため、ファイルシステムからのものであるかのように速度を期待します。この列をわざわざキャッシュしないようにPostGRESに指示する方法はありますか？

あるいは、私が間違った質問をしているのかもしれません。問題を解決したり、問題を無関係にする代替案を設計したりする他の方法があります。

4

3 に答える 3

4

何もする必要はありません。PostgreSQL は、8 kB を超える値に対して自動的に TOAST を使用します。

http://www.postgresql.org/docs/9.1/static/storage-toast.htmlから

PostgreSQL は固定ページ サイズ (通常は 8 kB) を使用し、タプルが複数のページにまたがることを許可しません。したがって、非常に大きなフィールド値を直接格納することはできません。この制限を克服するために、大きなフィールド値は圧縮されたり、複数の物理行に分割されたりします。これはユーザーに対して透過的に行われ、ほとんどのバックエンド コードへの影響はわずかです。このテクニックは、親しみを込めて TOAST (または「スライスしたパン以来の最高のもの」) として知られています。

PostgreSQL のキャッシュもページ レベルで行われるため、TOAST を残りの行と共にキャッシュする必要はありません (http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf)。

于 2012-07-10T22:56:24.837 に答える
3

Postgres が大きなフィールド値を TOAST できるという事実は、それが最善の方法であるという意味ではありません。

メイン データベースに大きなフィールドを保存すると、フォークやフォロワーの作成、特にバックアップの作成と復元など、多くのことが難しくなります。S3 を使用して PDF ファイルを保存することを強く再検討し、新しいクライアントの自動オンボーディング (heroku アプリの作成、データベースのプロビジョニング、S3 バケットのプロビジョニング/作成) に投資するだけです。

于 2012-07-12T06:30:13.740 に答える
0

Postgresは最大フィールドサイズ（または少なくとも最大ページサイズ）を課しているため、大きなPDFをどのように保存しているのかよくわかりません。ただし、TOAST を使用すると、これを回避できる場合があります。TOAST されたアイテムは別の (物理) テーブルに格納されるため、頻繁に選択しない場合はキャッシュしないでください。
それらを頻繁に選択している場合、あなたが望むことが可能かどうかはわかりません. Postgres が提供するキャッシングの「レベル」は 1 つだけであることを思い出してください。Linux VFS もキャッシングを行います。

于 2012-07-10T22:29:38.897 に答える