タグ付けされた質問 「blob」

データベース内のデータに関連するバイナリファイルを保存するのに最適な場所は何ですか？あなたは： BLOBを使用してデータベースに保存する データベース内のリンクを使用してファイルシステムに保存する ファイルシステムに保存しますが、コンテンツのハッシュに名前を変更し、データベースにハッシュを保存します 私が考えていないこと （1）の利点は（とりわけ）トランザクションの原子性が保持されることです。コストは、ストレージ（および関連するストリーミング/バックアップ）要件を劇的に増加させる可能性があることです （3）の目標は、ある程度まで原子性を保持することです。書き込み先のファイルシステムでファイルの変更や削除を許可せず、ファイル名として常に正しいハッシュを持つことを強制できる場合。ハッシュを参照する挿入/更新を許可する前にファイルシステムにファイルを書き込むことが考えられます-ファイルシステムの書き込み後、データベースDMLの前にこのトランザクションが失敗した場合、ファイルシステムはすべてのリポジトリであるため、問題ありません可能性のあるファイルとハッシュ-そこにポイントされていないファイルがあるかどうかは関係ありません（注意すれば定期的にクリーンアップできます） 編集： 一部のRDBMSはこれを個別の方法でカバーしているようです-他の人がそれをどのように行うのか知りたいと思います-特にpostgresのソリューション

123 database-design  blob 

この質問はbytea v。oid v。blob v。大きなオブジェクトなどに関するものではありません。 主キーintegerフィールドとフィールドを含むテーブルがありbyteaます。byteaフィールドにデータを入力したいのですが。これはおそらく、いずれかのPL/言語で行うことができPL/Python、将来的にはこれを行うことを検討するかもしれません。 私はまだテストと実験を行っているので、「標準」のSQLステートメントを使用して（サーバー上の）ファイルからデータを挿入するだけです。サーバーに対する書き込み権限を持つ管理者のみが、希望する方法でデータを挿入できることを認識しています。ユーザーはbytea現在データを挿入しないので、この段階では心配していません。さまざまなStackExchangeサイト、PostgreSQLアーカイブ、およびインターネットを一般的に検索しましたが、答えが見つかりませんでした。 編集： 2008年からのこの議論は、私がやりたいことは不可能であることを意味します。byteaフィールドはどのように使用されますか？ 編集： 2005年のこの類似の質問は未回答のままです。 解決済み： Webサイトのここで提供される詳細はpsycopg、Pythonで作成したソリューションの基礎を提供しました。byteaを使用して、バイナリデータを列に挿入することもできますPL/Python。「純粋な」SQLを使用してこれが可能かどうかはわかりません。

38 postgresql  plpgsql  blob  datafile 

この非常に支持されたSOの回答では、別のテーブルとの1：1関係しかない場合でも、画像を別々のテーブルに配置することを推奨しています。 写真をSQL Serverテーブルに配置する場合、写真を保存するために別のテーブルを使用することを強くお勧めします。従業員の写真を従業員のテーブルに保存せずに、別のテーブルに保管してください。このように、従業員のテーブルは、クエリの一部として従業員の写真も常に選択する必要がないと仮定すると、無駄がなく、平均的で非常に効率的です。 どうして？SQL Serverはテーブルに専用のBLOBデータ構造へのポインターのみを格納しているのではないかという印象を受けましたが、なぜ別の間接層を手動で作成する必要があるのですか？それは本当にパフォーマンスを大幅に改善しますか？はいの場合、なぜですか？

28 sql-server  blob 

同じデータを読み取りながら、非常に異なる論理読み取りを報告する3つの簡単なテストを次に示します。 セットアップ 次のスクリプトは、100個の同一行を持つテストテーブルを作成します。各行には、行外に格納されるのに十分なデータを含むxml列が含まれます。私のテストデータベースでは、生成されるxmlの長さは各行で20,204バイトです。 -- Conditional drop IF OBJECT_ID(N'dbo.XMLTest', N'U') IS NOT NULL DROP TABLE dbo.XMLTest; GO -- Create test table CREATE TABLE dbo.XMLTest ( ID integer IDENTITY PRIMARY KEY, X xml NULL ); GO -- Add 100 wide xml rows DECLARE @X xml; SET @X = ( SELECT TOP (100) …

26 sql-server  performance  blob  database-internals 

列の1つがXMLデータで、XMLエントリの平均サイズが約15キロバイトのかなり大きなテーブルがあります。他のすべての列は、通常のint、bigint、GUIDなどです。具体的な数値を得るために、テーブルの行数が100万で、サイズが最大15 GBであるとします。 私が気づいたのは、すべての列を選択したい場合、このテーブルからのデータ選択が本当に遅いということです。私がする時 SELECT TOP 1000 * FROM TABLE ディスクからデータを読み取るのに約20〜25秒かかります-結果に順序を付けませんが。コールドキャッシュを使用して（つまり、後にDBCC DROPCLEANBUFFERS）クエリを実行します。IO統計の結果は次のとおりです。 スキャンカウント1、論理読み取り364、物理読み取り24、先読み読み取り7191、lob論理読み取り7924、lob物理読み取り1690、lob先読み読み取り3968 最大15 MBのデータを取得します。実行計画には、予想どおりクラスター化インデックススキャンが表示されます。 クエリ以外にディスクでIOが実行されていません。また、クラスター化インデックスの断片化が0％に近いことも確認しました。これは一般消費者向けのSATAドライブですが、SQL Serverは〜100-150 MB / minよりも速くテーブルをスキャンできると思います。 XMLフィールドが存在すると、ほとんどのテーブルデータがLOB_DATAページに配置されます（実際、テーブルページの約90％がLOB_DATAです）。 私の質問は-LOB_DATAページはサイズだけでなく、テーブルに多くのLOB_DATAページがある場合にSQL Serverがクラスター化インデックスを効果的にスキャンできないため、低速スキャンを引き起こす可能性があると考えるのは正しいですか？ さらに広く-そのようなテーブル構造/データパターンを持つことは合理的であると考えられていますか？Filestreamを使用する際の推奨事項では、通常、フィールドサイズがはるかに大きくなるため、実際にはそのような道を行きたくありません。私はこの特定のシナリオに関する良い情報を実際に見つけていません。 私はXML圧縮を検討してきましたが、クライアント上またはSQLCLRで行う必要があり、システムに実装するにはかなりの作業が必要になります。 圧縮を試みましたが、XMLは非常に冗長であるため、（ac＃アプリで）XMLを20KBから〜2.5KBに圧縮し、VARBINARY列に格納して、LOBデータページの使用を防ぎます。これにより、テストでSELECTが20倍高速化されます。

19 sql-server  performance  xml  blob 

データベースから移行します。imageファイルシステム上のバイナリファイルにエクスポートしたいタイプの列が1つあります。レコードごとに1つのファイル。SQL Serverでこれを行うにはどうすればよいですか？

13 sql-server  migration  export  datafile  blob 

大規模な（100Mb-1 GB）マルチチャネル時系列データをPostgreSQLデータベースにインポートしようとしています。データは、通常はそれぞれ数秒の「レコード」または「エポック」にデータを分割するEDF形式のファイルから取得されます。各エポックのレコードは、データの各チャネルの信号を短い整数の順次配列として保持します。 最悪の場合、BLOBとしてデータベース内にファイルを保存するように義務付けられています。そこで、信号データに基づくクエリを容易にするなど、データベース内のデータをさらに活用できるオプションを調査したいと思います。 私の最初の計画は、エポックレコードごとに1行としてデータを格納することです。私が比較検討しているのは、実際の信号データをbyteaまたはsmallint []（またはsmallint [] []）のどちらのタイプとして格納するかです。誰かが他のものを推薦することはできますか？ストレージとアクセスのコストに興味があります。使用法は、1回挿入され、時々読み取られ、決して更新されない可能性があります。レコードを比較して分析するための関数を追加できるように、カスタムタイプとしてより簡単にまとめることができれば、はるかに優れています。 間違いなく私は詳細が低いので、私が明確にしてほしいことについてコメントを追加してください。

9 postgresql  datatypes  blob  bytea 

varbinary（max）型のフィールドに大量のデータが格納されたデータベースがあります。ある時点で、すべての行ではなく、ほとんどの行のデータをパージできます。私たちの計画は、そのフィールドをnull可能にし、不要になったときにデータをnullにすることです。それができたら、DBのサイズを小さくしたいと思います。これを達成するための最良の方法は何ですか？ 現在の設定でスペースを再利用する良い方法がない場合、私が持っているアイデアの1つは、メインテーブルへのキーとデータフィールドの2つの列だけを持つ別のテーブルにデータフィールドを移動することです。次に、不要になった行を削除するだけです。（そして、何らかの縮小を行います。）ただし、これは、既存のフィールドを単にnull可能にするよりも、はるかに難しい変更です。 注：データベースファイルのサイズを小さくすることはあまり気にしていませんが、新しく解放されたスペースが再利用可能になることは気にします。 DBサイズの90％以上がこの1つのフィールドです。私はすでに3TBです。

8 sql-server  sql-server-2014  disk-space  blob  varbinary 

いくつかのimageおよびtext列を含むSQL Serverデータベースがあり、それらを非推奨でない対応するvarbinary(max)とに移行することから発生する可能性のある潜在的な問題を調査していますvarchar(max)。 アプリケーションコードの変更は別として、私の主な関心事は、これに関連する潜在的な「問題」です。たとえば、古いデータ型ではサポートされているが、新しいデータ型ではサポートされていない機能はありますか？ 新しい型は少なくとも古い型と同じくらい大きいので、切り捨てによるデータの損失は少なくとも問題にはならないようです。

8 sql-server  database-design  blob