搜索有關構建大型企業系統的信息

Question

如果在一個會話中上載和處理500000個數據記錄是正常操作（C＃.NET 3.5），如何組織信息管理系統的數據庫層，業務邏輯和跨平臺API + MS SQL 2005）？

我特別感興趣的是經過生產驗證的分頁模式，它的併發性，可伸縮性和可靠性表現良好。

有沒有人有任何想法，在什麼方向挖？

• 開源項目（不關心的語言或平臺，只要它不是OOK）
• 書
• 文章
• 谷歌關鍵字
• 論壇或新聞組

任何幫助將不勝感激！

更新：

• 簡單分頁（即：在ROWNUMBER SQL 2005）不起作用，因爲有 很多併發改變 到數據庫。在頁面請求之間刪除或插入的項目會自動使當前頁面索引無效。

Answer 1

完成實施。我最近被告知，其中一個上傳的內容大約是2148849條記錄。在此上傳過程中，分層成功地處理了幾個斷開的連接和數據庫級別的數十個死鎖。

如果別人需要的一些信息：

• Product page
• Exception Handling Action Policies

Answer 2

這是一本好書，開始：

Patterns of Enterprise Application Architecture由Martin Fowler

Answer 3

當涉及到數據庫優化你最有可能使用「BigTable的」技術中受益的數據量巨大。我發現article here非常有用。簡單的想法是使用數據庫非規範化來交換磁盤空間以獲得更好的性能。

要在MS SQL 2005中進行分頁，您需要查找有關使用ROW_NUMBER函數的更多信息。 Here is just a simple example，你會發現他們噸使用谷歌（關鍵字：ROW_NUMBER分頁SQL 2005）。不要深究 - 實施沒有什麼魔力，而是你將如何使用/呈現分頁本身。 Google搜索就是一個很好的例子。

注意：我們發現NHibernate框架原生分頁支持不足以滿足我們的解決方案。

另外，您可能有興趣創建FULLTEXT索引並使用全文搜索。關於創建全文索引的Here is MSDN article，關於全文搜索的some info。

祝你好運。

Answer 4

dandikas，

謝謝你提到的部分非規範化。是的，這是我正在考慮改進某些查詢性能的方法。

不幸的是，NHibernate ORM不適合解決方案，因爲它增加了性能開銷。與SQL分頁一樣 - 它不適用於多個併發編輯（如stress-testing檢測到的情況）

Answer 5

我照顧企業數據倉庫，該倉庫上傳數十萬條記錄的某些訂閱源。
我不知道這是否是您的情況，但我們：

• 接收界河我們上傳到Sybase數據庫的文本文件。
• 使用awk格式化不同的提要，以便它們採用通用格式。
• 使用bcp將它們加載到非規範化的中間表中。
• 運行存儲過程來填充規範化數據庫structre。
• 從非規範化中間表中刪除。

這運行得很好，但我們強制我們的上傳順序。即當Feed到達時，他們進入隊列，我們​​在完成隊列頭部的處理之前完全處理Feed，然後查看其餘的隊列。

這有幫助嗎？

Answer 6

同樣與SQL分頁 - 它不會在衆多 併發修改的情況下工作（通過壓力測試檢測）

正如我提到的，在實現分頁沒有魔法 - 您使用ROW_NUMBER或臨時表。這裏的神奇之處在於評估您最常用的真實世界使用場景。使用臨時表和用戶跟蹤可能會有助於克服併發編輯方案。雖然我感覺你會通過回答問題贏得更多：

1. 用戶在轉到另一頁之前停留多長時間？
2. 用戶從第一個頁面移動到其他頁面的頻率？
3. 用戶將瀏覽的常見頁面數量是多少？
4. 當用戶從一個頁面移動到另一個頁面並返回時，如果某些信息發生變化，它有多重要？
5. 當用戶位於顯示信息的頁面上時，如果某些信息被刪除，它有多重要？

在你首先回答上述問題，然後只處理真正重要的情況之前，儘量不要專注於如下問題：「如何在分頁時處理任何可能的併發編輯方案？」。

另一個說明是UI。查看盡可能多的分頁UI，因爲有更好的解決方案，而不僅僅是右箭頭和左箭頭，或排列頁碼。一些解決方案有助於隱藏/克服技術上不可解決的尋呼場景。

P.S.如果這個答案很有用，我會把它和我的第一個結合起來。