2014-07-02 33 views
2

我設計了一個SQL Server 2012數據庫的解決方案爲以下情形如何批量更新了很多積極的讀者

  • 該數據庫包含約1M記錄以及一些簡單的父子關係的SQL服務器數據庫4
  • 之間或5桌
  • 有一個全天候高負載的數據庫
  • 上讀取每日一次,我們收到了一批具有約1000插入,更新和刪除應合併到數據庫中,偶爾這個數字可能是更高。
  • 除了日常一批沒有其他作家到數據庫

有一些「特殊」要求

  1. 讀者應該不會遇到任何顯著的延遲,由於這些更新
  2. 整個批次應該從讀者的角度進行原子處理。讀者不應該看到一個部分處理一批
  3. 如果更新失敗中途我們需要回滾
  4. 處理該批次本身的批次的所有變化是時間關鍵,有一個簡單的實現,現在佔用幾分鐘就好了。

我想到的選項是

  • 紙環繞整個更新一批單個數據庫事務(這可能是一個大交易),並使用快照隔離,讓讀者閱讀原文數據,而更新正在運行。

  • 使用分區切換,看起來這個功能是爲這種用例而設計的。缺點似乎是,在我們開始處理批處理之前,我們需要創建所有原始數據的副本。

  • 切換整個數據庫。我們可以創建整個數據庫的副本,在該副本中處理批處理,然後將所有客戶端重定向到此數據庫(例如,通過更改其連接字符串)。這甚至應該允許我們使數據庫只讀,甚至可能爲了可伸縮性創建數據庫的多個副本。

以下哪個選項或其他選項最適合這種情況?爲什麼?

回答

1
  1. 交易策略將阻止並導致延遲。

分區切換並不是真的會解決您的解決方案,因爲您應該認爲,就像今天對數據庫執行操作一樣...(所以回滾/插入)仍然會阻止它可能被隔離到只是您的部分數據不是全部...

最好的辦法是使用2個數據庫和切換連接字符串...

或使用1個數據庫,並有2組表並使用交換查看「活動」表的視圖或sprocs。你仍然可能有磁盤爭用問題,但從鎖定的角度來看,你會沒事的。

+0

根據我的理解,快照隔離應該允許讀者繼續讀取事務開始之前的值(因爲SQL在臨時數據庫中創建了一個副本,爲什麼這麼說會阻塞並導致延遲?) –

+0

Frank I我努力想記住我在想什麼,你說的是正確的,快照隔離不會阻止讀者,我想在這裏放下自己,快照隔離是一個可行的選擇,但是我會告誡你,你需要在tempdb中有足夠的空間保持整個數據集的更新。 –