問題タブ [filetable]

画像をSQLデータベースに保存したい。画像のサイズは 50kb から 1mb です。FileStream と FileTable について読んでいましたが、どちらを選択すればよいかわかりません。各行には 2 つの画像とその他のフィールドがあります。

画像が更新/削除されることはなく、1 日に約 3000 行が挿入されます。

この状況でおすすめは？

Windows Server 2012 で ASP.NET を使用して Web アプリを作成しています。SQL Server 2014 を使用しており、ファイル テーブルが次のパスにマップされている FileTable があります\\CIHOST1\MSSQLSERVER\FileStreamDirectory\AvatarsFT\ 。

管理者としてログオンするように Web サイトのアプリケーション プール ID をセットアップすると、アプリはパスに対してファイルの読み取りと書き込みを行うことができますが、既定のアプリケーション プール ID に変更すると、アクセス拒否の例外が発生するため、アプリはそこからファイルを作成または読み取ることができません。 UNC パス。問題は、ApplicationPoolIdentity が SQL Server ファイル共有にアクセスできるように、どの権限をどこに設定するかです。ApplicationPoolIdentity ユーザーはどのグループに所属する必要がありますか?

SQL Server 2014 のファイル テーブルから実際のテキストを取得することは可能ですか?

ヒット ハイライト機能を実装したいのですが、そのためには、コンテンツが varbinary 列にあるため、インデックスを作成したファイル内の実際のテキストを取得する必要があります。

それが不可能な場合、これを行う唯一の代替手段は、FileTables を忘れて、アプリケーション側の「ドキュメント リーダー」を実装することだと思います。これにより、varbinary の代わりに「file_stream」列内に実際のテキストが表示されます。あるいは、C# コードの背後で iFilter を使用する UDF を定義することもあるでしょうか?

どんなアドバイスでも本当に役に立ちます。

私は現在、多くのアプリケーションからのドキュメントのユニークなエントリ ポイントとなるドキュメント管理システム開発の分析フェーズにいます。書類のサイズと量はアプリケーションによって異なります。たとえば、そのうちの 1 つは 1 年間に 500,000 のドキュメントを持ち、そのうち 468,000 は 256 KB 未満です。他のアプリケーションからのドキュメントのサイズは、一見しただけではさまざまなサイズになる可能性があります

私が提案した解決策は、外部アプリケーションと SQL Server の間のミドルウェアとして機能する WCF Web サービスを作成することです。

• ドキュメント挿入時
  • 外部アプリケーションは、アプリ GUID とドキュメントをバイトとして WCF に送信します[]
  • WCF はドキュメントをデータベースに挿入し、一意の GUID を WCF に返します。WCF はそれを外部アプリケーションに渡して独自の DB に格納します。
• ドキュメントを選択する場合
  • 外部アプリはドキュメント GUID とアプリ GUID を WCF に送信し、Web サービスは DB にクエリを実行し、ファイル コンテンツを含むバイト ストリームを返します。

高レベルのアーキテクチャは次のようになります (Entity Framework 6 を介したデータへのアクセス)。

さまざまな代替案を検討した後、Filestream (2008 年現在) と FileTable (2012 年現在) の機能を使用することにしました。

このソリューションの DB アーキテクチャの観点からは疑問があり、何百万ものドキュメントが FileTable に格納されたときの将来のパフォーマンスが心配です (クライアントの主な関心事でもあります)。このタイプの機能 (Filestream と FileTable) が小さなファイルのパフォーマンスを低下させるかどうかはわかりません。Microsoft や MVP などのさまざまなブログで読んだことによると、小さなファイル (256 KB 未満) の場合は VARBINARY(MAX) としてテーブルに保存し、ファイルが 1 MB 以上の場合は Filestream を使用することをお勧めします。

Filetable と Filestream を使用したことがないため、このアプローチのパフォーマンスはわかりません。1 年以内に、最大 6 つの異なるアプリケーションがこのリポジトリにドキュメントをダンプします。予想される増加は、年間で約 500 万のドキュメントであり、そのファイル サイズはさまざまであり、一見しただけでは判断できません。

実装のために、私は次のことを提案しました。

1. サイズに応じて、ドキュメントが VARBINARY またはテーブルの FileTable タイプに格納されるという WCF のロジック。2 つのファイル グループを作成します (1 つは <= 1 MB のファイル用、もう 1 つは > 1 MB のファイル用)。
2. アプリケーションと同じ数の FileTable を持ち、同様に多くの Filegroup を持つ。6 つの外部アプリケーションがある場合、それぞれに独自の FILEGROUP を持つ 6 つの FileTable がありますが、この場合はファイル サイズごとではなく、アプリケーションごとに区別します。

上記の後、このソリューションのアーキテクチャに関する推奨事項と、ハードディスク、RAM、プロセッサなどの特性に関する推奨事項が必要になります。

これは基本的にはい/いいえの質問ですが、答えが「はい」の場合は参考文献とハウツーを回答に含めていただければ幸いです。不思議なことに、MSDN や TechNet で決定的な答えを見つけることができず、直感と実験の結果、「いいえ」という結論に達しました。

SQL Server 2012 の FILESTREAMS および FileTable で Windows EFS を使用し、これらの FILESTREAMS で全文検索を実行することはできますか?

ティア

追加の詳細

FileTable 上の FILESTREAMS を使用して DB をスタンプする Visual Studio SQL プロジェクトを作成し、全文検索が機能しているので、ベースラインが適切であることはわかっています。そこから、2つのことを試しました。

1. 物理FileTable フォルダーを参照し、 EFS で暗号化します。DB、ログ、および FILESTREAM を作成した後に暗号化を追加しているため、これはおそらく間違ったアプローチです。SQL エラーは「Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when received results from the server. (プロバイダー: 共有メモリ プロバイダー、エラー: 0 - プロセスが反対側にありません。 pipe.)" 物理フォルダの暗号化を無効にすると、問題が解決されます。

2. 最初に物理ターゲット フォルダーを暗号化してから、SQL プロジェクトをデプロイします (したがって、.MDF と .LDF もディスク上で暗号化されます)。これはうまくいくようですが、UNC パス (\MyMachine\MSSQLSERVER\NewDb\Files) を参照してそこにファイルをコピーすると、Windows から次のエラーが表示されます: "Destination Folder Access Denied.You need permission to perform this action. " そのため、検索は機能する可能性がありますが、フォルダーにファイルを入れることはできません。

他の SO 投稿で詳しく説明されているように、Visual Studio SQL プロジェクトで SQL Server 2012 を使用しています。EFS (暗号化ファイル システム) が無効である限り、FILESTREAMS が有効になり、FileTables が独自の FileGroup に作成され、私の SQL プロジェクトはインデックス可能/検索可能な適切な FILESTREAM DB を生成します。物理パス (SQL のデータ ディレクトリで有効) で EFS を有効にすると、FileTable Win32 共有に対してファイルを読み書きできません。FWIW、共有を介してディレクトリを作成および削除できます。

Bruce Jackson のブログで読んだことによると、「問題なく動作する」はずですが、現在、EFS の有効化または無効化はトグルとして機能しています。EFS オフ=> 共有への/からのドラッグ アンド ドロップはうまく機能します。

SQL Server は独自のローカル アカウントで実行されており、他のすべての操作 (SSMS、Windows Explorer などを使用) をドメイン アカウントとして実行しています。これはローカル管理者であり、SQL Server の dbo にマップされています。十分な権限が必要だと思います。また、SSMS を介した BLOBS のクエリは正常に機能します。EFS が有効になっていると壊れるのは、Win32/UNC 共有アクセスだけです。

誰が何がうまくいかないのか知っていますか？

フォルダーとファイルの両方をFileTable含む SQL Server 2012 データベースに があります。フォルダの名前を変更したかったので、実行しました

update MyFileTable set name = 'NewName' where name = 'OldName';

更新は成功し、ファイル テーブルから選択すると新しい名前が反映されます。ただし、Windows エクスプローラーで対応するフォルダーの場所に移動すると、新しい名前が反映されません。更新して少し待ってから更新してみましたが、フォルダーにはまだ古い名前が付けられています。（古い名前の）フォルダを開こうとすると、場所が無効であるというエラーが表示され（またはその影響）、「OK」をクリックするとフォルダが消えます。

ただし、新しい名前で同じ場所に新しいフォルダーを作成しようとすると、フォルダーが既に存在するというエラーが表示されます。「OK」をクリックすると、新しい名前のフォルダーが表示され、「新しいフォルダー」という名前の新しいフォルダーが表示されます (という名前のフォルダーを作成しようとして失敗したためですNewName。フォルダーを削除した後New folder、目的の結果が得られます: ファイル テーブルが更新され、新しい名前が Windows エクスプローラーに反映されます。

したがって、ファイル テーブルはほとんど機能しているように見えますが、クエリまたはストアド プロシージャで実行された名前の変更 (またはその他の変更) がファイル共有に反映されるようにするにはどうすればよいでしょうか?

私はグーグルで検索しましたが、この問題について議論しているものは見つかりませんでした。

編集:
新しいレコードをファイル テーブルに挿入するときに、同様のことに気付きました。新しいレコード (この場合はフォルダー) は、ファイル テーブルには表示されますが、作成後に Windows エクスプローラーには表示されません。しかし不思議なことに、さまざまなことを試してみたところ、最近作成された 5 つのフォルダーが Windows エクスプローラーに一度に表示されました。だから、多分ただの遅れがあります。誰かが同様の経験をしたことがありますか？

私はFileTable自分のプロジェクトで最初にSQL Server 2014とEFコードを使用しています。

このコマンドを使用すると

それはSQLでこの警告を示しています

FILESTREAM データベース オプション NON_TRANSACTED_ACCESS が FULL に設定され、READ_COMMITTED_SNAPSHOT または ALLOW_SNAPSHOT_ISOLATION オプションがオンになっている場合、FILETABLE のコンテキストでの FILESTREAM データへの T-SQL およびトランザクション読み取りアクセスはブロックされます。

今、私は続けてテーブルを作成し、フォルダとファイルを問題なく挿入します。

読み取りデータがこのエラーを表示するときに、データを読み取るための私の問題:

メッセージ 33447、レベル 16、状態 1、行 2
FileTable 'File' の file_stream 列にアクセスできません。FileTable は行のバージョン管理をサポートしていないためです。トランザクション レベルを READ COMMITTED SNAPSHOT または SNAPSHOT 以外に設定するか、READCOMMITTEDLOCK テーブル ヒントを使用してください。

最初に EF コードを使用しています - この問題を解決するにはどうすればよいですか?

Filestream / FileTable をドキュメント ストレージとして使用するカスタム ドキュメント管理システムに取り組んでいます。

ディレクトリ構造は次のとおりです。APPNameDir --> 年 --> 月 --> ファイル

+ APPNameDir + 2015 + 12 File 1.pdf File 2.pdf + 2016 + 01 File 3.pdf File 4.pdf + 02 File 5.pdf File 6.pdf

私がやりたいことは、C# コードからストアド プロシージャを呼び出し、フォルダー ツリー (たとえば、(BooksApp/2016/03) と file_stream データを渡すことです。

次に、ストアド プロシージャで、フォルダー ツリーが既に存在するかどうかを確認し、そうでない場合は存在しないフォルダーを作成します。

この投稿を見たので、一度に 1 つのフォルダーを作成できますが、一度に複数のフォルダーを作成することはできません。

2016が存在しないかどうかを確認してから作成できると思います。次に、03月が存在しないか確認してから作成するなどを行いますが、Webアプリケーションから2秒以内にドキュメントを挿入したいので、DataBaseに数百万のドキュメントがある場合のパフォーマンスが心配です(制限はあります)。 ）。数日前にパフォーマンスのベンチマークを行ったところ、Web アプリケーションからドキュメントを挿入するのに 100 ～ 300 ミリ秒かかりました。各ディレクトリの FileTable をクエリし、それらが存在しない場合はそれらを作成する必要がある場合、DB にそのような量のドキュメントがあるとパフォーマンスが低下するのではないかと心配しています。

プロジェクトで同様のニーズを経験したことがありますか? 何か案が？