ドキュメント/画像データベースリポジトリの設計に関する質問

Question

質問：

データベースイメージリポジトリに直接アクセスするアプリケーションを作成するか、ドキュメントリクエストを処理するミドルウェアを作成する必要があります。

背景：

現在、約1500万のドキュメント/ドキュメントイメージ（90％以上の単一ページ、グループ4のTiff、残りのPDF、Word、Excelドキュメント）を保存するカスタムドキュメントイメージングおよびワークフローアプリケーションを持っています。イメージリポジトリは商用のサードパーティアプリケーションであり、非常に高価であり、率直に言ってオーバーヘッドが大きすぎます。文書画像を保存および取得するシステムが必要です。

イメージングをSQL Server 2005データベースに直接移動することを検討しています。インデックス情報は非常に限られています-基本的に2つのインデックスフィールド。これは生命保険のポリシー管理システムであるため、ポリシー番号とシステム全体で一意のID番号を使用して画像にインデックスを付けます。他にもインデックス値がありますが、それらは画像データとは別に保存および管理されます。これらのインデックス値により、個々の画像を取得するための一意のid値を検索できます。

データベースサーバーは、DBファイルをホストするSANドライブを備えたデュアルクアッドコアWindows 2003ボックスです。現在の画像リポジトリのサイズは約650GBです。変換されたデータベースのサイズを確認するためのテストは行っていません。データベースの設計についてはあまり質問していません。DBAと協力してその側面について取り組んでいます。それが変更された場合、私は戻ってきます：-）

置き換えられる現在のシステムは明らかにミドルウェアアプリケーションですが、3つのWindowsサーバーにまたがる非常に重いシステムです。このルートに行くと、単一のサーバーシステムになります。

私の主な関心事は、スケーラビリティとパフォーマンスです。パフォーマンスを重視しています。私は約100人のユーザーを抱えており、今後数年間は使用量の伸びがおそらく遅いでしょう。 ほとんどのユーザーは主に読み取りユーザーです。システムに頻繁に画像を追加することはありません。スキャンやその他の方法でリポジトリに画像を追加する部門があります。 （ftpを介して）ドキュメントを受信する他のアプリケーションもいくつかあり、それらは受信時に自動的にリポジトリに挿入されます。完全なインデックス情報または<！> quot; batches <！> quot;ユーザーがレビューとインデックスを作成すること。

ドキュメント（画像）のほとんど（90％以上）は非常に小さい<！> lt; 100K、おそらく<！> lt; 50K。したがって、SQL 2008を取得してファイルストリームを使用するよりも、データベースファイルへの画像の保存が最も効率的であると考えています。

Answer 1

多くの場合、スケーラビリティとパフォーマンスは最終的に互いに結びついています。というのは、今から6か月後に経営陣が戻ってきて、<！> quot;アプリケーションXの機能Yが許容できないほど遅く実行されるという意味です。<！ > quot;多くの場合、答えはバックエンドソリューションをアップグレードすることです。また、バックエンドのアップグレードに関しては、ほとんどの場合、ハードウェアの観点からスケールアップするよりもスケールアウトする方が安価です。

つまり、簡単に言えば、ユーザーアプリからの着信要求を具体的に処理し、適切な宛先にルーティングするミドルウェアアプリを構築することをお勧めします。これにより、フロントエンドユーザーアプリがバックエンドストレージソリューションから十分に抽象化されるため、スケーラビリティが問題になる場合は、ミドルウェアアプリのみを更新する必要があります。

Answer 2

これは簡単です。アプリケーションをインターフェイスに書き込み、何らかの種類のファクトリメカニズムを使用してそのインターフェイスを提供し、必要に応じてそのインターフェイスを実装します。

インターフェイスに満足したら、アプリケーションは、DBと直接通信するか他のコンポーネントと直接通信するかに関係なく、（ほとんど）実装から分離されます。

インターフェースの設計について少し考えてみてください。骨を折ってください！実装は、システムをオーバーエンジニアリングする必要はありませんが、システムを将来的に校正するバランスを提供します。

この時点でインターフェースさえ必要とせず、インスタンス化する単純なクラスであると主張するのは簡単です。ただし、契約が適切に定義されている場合（つまり、インターフェイスまたはクラスの署名）、それが変更（バックエンド実装のやり直しなど）からあなたを保護するものです。必要に応じて、後からいつでもクラスをインターフェイスに置き換えることができます。

スケーラビリティに関しては、テストしてください。そうすれば、スケーリングが必要な場合だけでなく、おそらく必要な場合もわかります。 <！> quot; 100人のユーザーに最適で、200人に問題があります。150に達した場合、バックエンドをもう一度検討することを検討したいかもしれませんが、今のところは良いです。<！> quot;

それはデューデリジェンスと責任ある設計戦術、IMHOです。

Answer 3

gabriel1836に同意します。ただし、追加の利点として、1400万件のドキュメントをプロプライエタリシステムから自国のシステムに一晩で変換しないため、しばらくの間ハイブリッドシステムを実行できることがあります。

また、データベースの外部にドキュメントを保存することを強くお勧めします。ファイルシステム（ローカル、SAN、NASは重要ではありません）に保存し、データベースへのドキュメントへのポインターを保存します。

現在使用しているドキュメント管理システムを知りたいです。

また、独自システムが提供するキャプチャ（スキャンとインポート）を置き換える努力を過小評価しないでください。