私は現在、多くのアプリケーションからのドキュメントのユニークなエントリ ポイントとなるドキュメント管理システム開発の分析フェーズにいます。書類のサイズと量はアプリケーションによって異なります。たとえば、そのうちの 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 万のドキュメントであり、そのファイル サイズはさまざまであり、一見しただけでは判断できません。
実装のために、私は次のことを提案しました。
- サイズに応じて、ドキュメントが VARBINARY またはテーブルの FileTable タイプに格納されるという WCF のロジック。2 つのファイル グループを作成します (1 つは <= 1 MB のファイル用、もう 1 つは > 1 MB のファイル用)。
- アプリケーションと同じ数の FileTable を持ち、同様に多くの Filegroup を持つ。6 つの外部アプリケーションがある場合、それぞれに独自の FILEGROUP を持つ 6 つの FileTable がありますが、この場合はファイル サイズごとではなく、アプリケーションごとに区別します。
上記の後、このソリューションのアーキテクチャに関する推奨事項と、ハードディスク、RAM、プロセッサなどの特性に関する推奨事項が必要になります。