一般的に、ファイル システムに画像を保存し、データベース エントリを介してリンクする方が常に良いと考えていました。ただし、データベースの設計を最適化しようとしており、いくつか質問があります。
私の画像はすべて白黒 (グレースケールではなく真の白黒) の非常に小さなサムメールで、サイズは 70x70 です。画像 (基本的には 1 と 0 の 2D 配列) を取得すると、それぞれ約 600 バイトのバイナリ データとして格納できます。
したがって、私の質問は、データベースに格納されている 600 バイトをクエリする方が、リンクをクエリしてからファイルシステムにアクセスするよりも高速かどうかです。多くの「画像」クエリが作成されていると仮定します。
この分野で経験のある人はいますか？
問題があれば、私は MySQL と MonetDB を使用しています (別々に使用していますが、両方について同じ質問があります)。
どうもありがとう、ブレット
600バイトしかない場合は、それほど心配する必要はなく、blobとしてデータベースに保存します。
High Scalabliltyには、Flickrの設計方法に関する興味深い記事があります。これはあなたにとって有用な読み物になるかもしれません。
質問 sql-server にタグを付けたので、遺憾なジム・グレイによる研究論文であるTo Blob or Not To Blobを読むことをお勧めします。この論文では、BLOB をファイル システム (NTFS) とデータベース (SQL Server) に格納するというトピックについて詳しく説明しており、さまざまな角度から検討されていることに驚かれることでしょう。必読です。しかし、結論は次のとおりです。
この調査は、オブジェクトが平均で 1 メガバイトを超える場合、NTFS が SQL Server よりも明らかに優れていることを示しています。オブジェクトが 256 キロバイト未満の場合、データベースが明らかに有利です。この範囲内では、ワークロードの書き込み集中度と、システム内の典型的なレプリカの保存期間によって異なります。
あなたのケースは明らかに「To BLOB」ケースに当てはまります。
私が理解している限り、理由もなく使用していない場合は、さらに大きなファイルを DB に格納しても問題はありませんSELECT *(率直に言って、使用する理由はまったくありませんSELECT *)。
BLOB と TEXT は他のデータとは別に保存されるため、明示的にクエリを実行しない限り、パフォーマンスに影響はありません。
イメージをデータベースに保存する (そして要求ごとに提供する) と、これらのイメージをプロキシ サーバーにキャッシュすることができなくなります (むしろ、タスクが何倍も複雑になり、ほとんどすべての既成のソリューションが妨げられます)。問題は、影響を測定するには、別の見方をする必要があることです。「単一のクエリで画像を取得するのにどれくらいの時間がかかるか」ではなく、「一連の (ここに妥当な数を入れて) クエリにどれくらいの時間がかかるか」を自問してください。同じ一連の画像を取得するには". また、「DB への往復のコストを支払わなければならないのか?」と自問することもあるでしょう。
このアイデアにメリットがないわけではありません。単一の場所で画像を更新することが重要な要素になる可能性があります。また、高可用性が必要な場合は、DB をデータの中心点として構成する方がはるかに簡単です (イメージをファイル システムに置くということは、イメージが更新されたときにノード間で同期することを意味します)。変更の追跡、許可、追加データ、「壊れたリンク」の回避 - これらも同様に役割を果たす可能性があります。
上記のすべては別として、「ファイルシステム」手法を使用して悪い経験をしました。現在、「データベース」手法への移行を検討しています。
あなたがウェブアプリケーションについて話しているなら、データベースに画像を保存するのはばかげています。デスクトップアプリケーションが得られる利点はありませんが、問題があるだけです。
これはファイル サイズだけの問題ではなく、データベースが動作しているときに予想されるレコードの最大量に関するものでもあります。昔は、あらゆるタイプのフィールドに対してこの種の計算を行っていました。レコードの最大量に 600 バイトを掛けるだけで、結果が扱いやすいものであれば、速度について心配する必要はありません。
@codeholic が言うように、SELECT * を使用していなければ、すべてうまくいきます。