報告和日常交易的數據庫

Question

我有一個系統，可以保存大量的數據。使用的數據庫是SQL Server。其中一張桌子有大約30萬行，並且有相當數量的這種大小的桌子。在這張桌子上發生了定期更新 - 我們說這是交易發生的「交易數據庫」。

現在，我們需要實現報告功能。一些架構師正在提出一個不同的數據庫，它是這個數據庫的副本+一些額外的報表。他們提出這個建議是因爲他們不想破壞事務數據庫的功能。爲此，數據必須經常移至報告數據庫。我的問題在於，是否真的需要爲此目的而設置第二個數據庫？我們是否可以將事務數據庫本身用於報告目的？由於必須將數據移動到不同的數據庫，因此如果事務數據庫本身用於報告，則會出現延遲。 期待一些專家的意見。

Answer 1

您需要對ETL，數據倉庫和報表數據庫進行一些研究，因爲我認爲您的架構師可能會以良好的方式解決這個問題。既然你沒有提供實際報告的細節，我會盡量回答一般情況。

（聲明：我在這方面的工作，我們必須面向這個產品）

事務數據庫的讀/更新/插入之間的良好平衡優化，索引和表normalisations都是爲了這種效果。

報表數據庫非常適合讀取超出所有其他事物的訪問。這意味着適用於交易數據庫的「正常」規範化規則將不適用。事實上，高度的反規範化可能會使報告查詢的方式更加高效和簡單。

對事務數據庫運行復雜（尤其是對擴展數據範圍（如歷史時間範圍）的聚合）查詢可能會影響性能，因此數據庫的關鍵用戶 - 事務生成器可能會受到負面影響。

雖然在您的情況下可能不需要報告數據庫，但您可能會發現將兩個用例分開更簡單。

您對數據延遲的關注是真實的。這隻能由使用報告的業務用戶回答。如果不是所有的需求都包含非實時信息，人們經常會說「我們需要實時信息」。數據過時的可接受程度只能由他們回答

事實上，我建議您稍微進一步研究一下，並針對報告問題查看多維立方體，而不是僅報告數據庫。設計將您的報告問題抽象爲全新的水平。

Answer 2

在完美的世界裏，報告和運營數據應該是分開的。原因是你想要集中交易表插入/更新（通常更少的指數）和報告的選擇（通常更多的指數）。當然現實世界並不是完美的世界。所以這是我的經驗法則。只要您可以在保持報告代碼的可維護性的情況下在相同表格上同時執行這兩個操作，而沒有性能損失，那麼就沒有真正的理由分離。當到了跳躍的時候，你可能會處於一個階段，關係型數據庫至少應該增加一個BI解決方案。另一個原因爲什麼兩個人應該分開時間。

有一點要記住。大多數建築師想要超過建築師，畢竟這是他們的工作。保持誠實，並讓他們證明自己的情況。對於你而言，總是希望你是如此的成功，以至於你將需要他們的話來設計它，但是如果你付出重大的交付問題的速度，不要試圖實現最終的遊戲。

Answer 3

我第二個Hubson的答案。我自己可能不是一個體面的SQL服務器開發人員，但我面臨着大表（大約1米行）。所以或多或少我有這方面的經驗。

引用this SE answer，我可以說由於硬盤的I/O容量，相同硬盤上的多個DB不會提高性能。如果您可以以某種方式將報告數據庫放到不同的硬盤上，那麼您可以通過I/O和read only中的其中一個密集型硬盤獲得收益。

如果兩個數據庫存在於同一個實例中，它將共享相同的memory和tempdb，這對性能或降低I/O成本根本沒有好處。

此外，300K行是不是一個大問題，除非是加入了與其他3頁300K的表，或者具有需要數據清理等，這是不同的，雖然如果你的數據增長率增加一個非常複雜的查詢在未來快速發展。

如何在不涉及運行數據庫性能影響的情況下提高報表性能？

1. 正確的索引

   除了需要一些存儲，正確的索引會導致更快的數據處理，你會驚奇地發現它是如何加快處理速度。

2. 正確鎖定

   NoLock恕我直言，是最好用的報表，除非您使用的不是一個序列數據庫中不同的鎖定策略。由於未提交事務導致的報告結果中的某些偏差通常無關緊要。

3. 彙總數據

   已調度的過程中產生的彙總數據，也可以用來防止重新計算報告閱覽。

編輯：

那麼，什麼是具有第二數據庫的好處？雖然 對性能沒有直接的好處，但它是有益的。可以使用第二個數據庫來保持事務數據庫乾淨並與報告活動分開。它的好處：

1. 保持物化數據

   例如每月產生的利潤總額的摘要可以被存儲在表中屬於這個特定的分貝

2. 保持報告邏輯

3. 您可以針對特定人員使用不同的交易分區來保護訪問權限

4. 爲db生成的文件用事務分隔。這是備份更容易/恢復（並與交易分開），當你想要移動到不同的硬盤，則很容易

總之，加入另一個正常的數據庫對於這種情況將不會過多在性能上受益，除非它是正確的（分開硬盤，分開服務器等）。然而，第二個數據庫雖然提供了可維護性方面和安全策略的好處