文檔/圖像數據庫存儲庫設計問題

Question

問題：

我應該編寫我的應用程序以直接訪問數據庫Image Repository或編寫一箇中間件以處理文檔請求。

背景：

我有一個自定義文檔影像和工作流應用程序，目前存儲約15萬個文件/文件圖像（90％+單頁，第4個TIFF格式，其餘PDF，Word和Excel文檔）。圖像存儲庫是一個商業化的第三方應用程序，非常昂貴並且坦率地說有太多開銷。我只需要一個系統來存儲和檢索文檔圖像。

我正在考慮將圖像直接轉移到SQL Server 2005數據庫中。索引信息非常有限 - 基本上是2個索引字段。這是一個人壽保險政策管理系統，因此我使用保單號碼和全系統唯一ID號爲圖片編制索引。還有其他索引值，但它們與圖像數據分開存儲和維護。這些索引值使我能夠查找單個圖像檢索的唯一id值。

數據庫服務器是一個帶有SAN驅動器的雙核四核Windows 2003機箱，它承載着數據庫文件。當前的圖像存儲庫大小約爲650GB。我沒有做任何測試，看看轉換的數據庫有多大。我沒有真正詢問數據庫設計 - 我正在與這方面的DBA合作。如果這種變化，我會回來:-)

當前被替換的系統顯然是一箇中間件應用程序，但它是一個非常重量級的系統分佈在3個Windows服務器。如果我走這條路線，它將是一個單一的服務器系統。

我的主要擔憂是可擴展性和性能 - 嚴重偏重於性能。我有大約100個用戶，並且在接下來的幾年中使用率增長可能會很慢。 大多數用戶主要是讀取用戶 - 他們不經常向系統添加圖像。我們有一個部門負責處理掃描並以其他方式將圖像添加到存儲庫。我們還有一些其他應用程序（通過ftp）接收文檔，並在收到文檔時自動將它們插入到存儲庫中，既可以提供完整的索引信息，也可以作爲用戶檢查和索引的「批處理」。

大多數（90％以上）文檔/圖片都很小，< 100K，可能是< 50K，所以我相信圖片在數據庫文件中的存儲將是最有效的，而不是獲取SQL 2008並使用一個文件流。

Answer 1

通常情況下，可擴展性和性能最終會彼此結合，即從現在管理層回來後的六個月內，「X應用程序中的函數Y運行速度緩慢得不可接受，我們如何加速它？通常，答案是升級後端解決方案。當涉及升級後端時，其擴展幾乎總是比較便宜，而不是在硬件方面進行擴展。

所以，長話短說，我會建議構建一箇中間件應用程序，專門處理來自用戶應用程序的傳入請求，然後將它們路由到適當的目的地。這將充分抽象出後端存儲解決方案中的前端用戶應用程序，以便在可擴展性確實成爲問題時，只需要更新中間件應用程序。

Answer 2

這很簡單。將應用程序寫入接口，使用某種工廠機制來提供該接口，然後根據需要實現該接口。

一旦你對界面感到滿意，那麼應用程序（大部分）與實現隔離開來，無論它是直接與數據庫還是其他組件交談。

在你的界面設計上稍微思考一下，但是做了一些愚蠢的事情，「這很簡單，它在這裏工作，現在可以工作」，實現了未來對系統進行校對時的良好平衡，而不一定需要對其進行工程設計。

在這個時候很容易認爲你甚至不需要接口，而只是一個簡單的類，你實例化。但是，如果您的合同定義得很好（即接口或類簽名），那麼可以保護您免受更改（如重做後端實施）。如果您覺得有必要，隨時可以使用接口替換該類。

就可擴展性而言，測試它。那麼你不僅知道你是否需要擴展，而且可能還需要擴展。 「對於100個用戶來說非常適用，如果我們打到150，我們可能會考慮再考慮一下後端，但是對於現在來說，這很好。

這是盡職調查和負責任的設計策略，恕我直言。

Answer 3

我同意gabriel1836。然而，一個額外的好處是你可以暫時運行一個混合系統，因爲你不會在一夜之間將你的專有系統中的14百萬個文件轉換成你自己的系統。

此外，我強烈建議您將文檔存儲在數據庫之外。將它們存儲在文件系統（本地，SAN，NAS並不重要），並將指向文件的指針存儲在數據庫中。

我很想知道您現在使用的文檔管理系統。

另外，不要低估替換專有系統提供的捕獲（掃描和導入）的努力。