SQL Server體系結構指導

Question

我們正在新架構上設計現有產品的新版本。 其內部Web應用程序可能有100個併發用戶（最多）這將在SQL Server 2008數據庫上運行。

最近的討論項目是，我們是否應該在單獨的數據庫中出於性能原因使用單個數據庫來拆分數據庫。

數據庫可以在5年內從50-100GB的任何地方增長。

我們是開發人員而不是DBA，因此得到一些常規指導將很好。

[我知道，因爲它依賴於架構的答案並不簡單，歸檔政策，數據量等]

選項1單主數據庫 [這是我的首選方案。

該計劃是將所有表放在單個數據庫中，並可能使用文件組和分區將多個磁盤上的數據分開（如果需要）。 [如果適用，使用模式]。這應該處理性能問題 其中一個意見是，單個服務器實例仍然會處理這些數據，所以仍然會有一個處理瓶頸。

對於報告，我們可以有一個單獨的報告數據庫，但仍在討論中。

選項2分割數據庫置於2個獨立的數據庫

DB1 - 客戶，帳戶，客戶資源等

DB2 - 這將包含批量數據的[即車輛跟蹤數據，財務交易表等]。

這些表通常會包含大量數據。 [如果需要，它可以位於單獨的服務器上]

該計劃將涉及將主數據保留在較小的數據庫[DB1]中，並將[主要]只讀事務類型數據保留在單獨的數據庫[DB2]中。 UI將主要從DB1中讀取，因此更具響應性。 [我知道，這個選項就更難被強制參照完整性。]

點考慮 由於我們是在設計階段，我們至少可以做出正確使用索引來處理性能問題因此多數民衆贊成爲什麼選項1對我來說很有吸引力，而且更多的是一種標準方法。 對於這兩種選擇，我們正在考慮實施歸檔數據庫。

道歉的長期問題。總之，問題是1 DB或2？

由於提前，

利亞姆

Answer 1

選項1在我看來是要走的路。

CPU不太可能成爲100個併發用戶提供工作負載的瓶頸。您可以通過熱插拔技術購買一臺具有額外CPU容量的多插槽服務器，以便爲您提供增長空間。根據您的可用性要求，您還可以考慮使用羣集解決方案來允許通過強制故障轉移到另一個節點來交換更多處理CPU資源。

磁盤子系統的性能將成爲您最關心的問題。您的設計決策將受到您使用的存儲解決方案的影響，我認爲這將是SAN技術。

至少您需要在單獨的LUN上放置LOG（RAID 1）和DATA文件（RAID 10或5取決於工作負載）。

根據您的表訪問，您可能希望考慮將不同的文件組放在單獨的LUN上。對您的表格數據進行分區可能對您有利，但僅適用於大型表格。

Answer 2

50到100GB和100個用戶是今天大多數標準的一個非常小的數據庫。不要過度設計解決方案，試圖解決您還沒有看到的問題。將它分割成兩個數據庫，兩個不同的服務器上的尤其是將會造成一系列令人頭痛的問題，而您最好不要使用它。集中精力創建一個有用的產品。

Answer 3

我同意其他意見，稱50和100GB之間這些日子很小。我也同意你不應該過度工作。但是，如果你存儲的實體（如你所說的，其中一個是讀寫的，其他部分主要是隻讀的）之間存在明顯的（或不是那麼明顯的）邏輯分隔，我仍然會將它分開在不同的dbs。至少我會用一種方式來設計它，因爲我很容易將一件作品分解出來。安全性會成爲一個原因，管理/備份/還原另一個更容易的可維護性（因爲固有的設計將更好地被分解，並且更好地隔離各個部分），並且在SQL Server中，可以擴展（或者如果它缺乏是一個單一的數據庫）。例如，分離登錄和內容數據庫通常對較大的Web應用程序有意義。

而且，如果你真的想要一個完善的設計，在一個單一的數據庫分開你的實體，採用不同的模式，將適當的權限在對象上，你最終幾乎在我眼裏同樣的努力。

微軟產品一樣的SharePoint，TFS和BizTalk都使用幾個不同的數據庫（儘管我不想假裝知道的原因/可能只是他們組織自己的團隊的方式）的結果。

尤其是對於你無法在SQL Server上擴展單個數據庫實例（羣集需要多個實例），我很想分割它。

@John：我會從來沒有使用RAID5。除了傷害表現之外，別無它用。我同意RAID10方法。

Answer 4

將數據放入另一個數據庫不會對性能產生絲毫的影響。性能完全是其他因素的一個因素。

一個原因，以創建一個新的數據庫是維護和管理的原因。例如，如果一組數據需要不同的備份和恢復策略或具有更高的可用性要求。