導入大量的xml文件

Question

什麼是最好的方法導入多個xml文件是非常大的數字（例如：30000）與Sql Server 2008不同的架構？

我目前正在循環瀏覽每個文件，將數據加載到datatable並使用SqlBulkCopy來插入數據，但它花費了大量的時間（大約1.5小時）。

Answer 1

這應該不會這麼長。據我估計，你有大約600MB的數據;您應該可以毫無困難地接近10MB/s或至少至少 1MB/s - 這意味着1-10分鐘應該很容易實現。

怎麼辦：

• 確定哪一部分是需要這麼長時間
• 使可能的瓶頸的名單
• 測試每一種理論，直到你找到了罪魁禍首
• 實現解決辦法。

如果沒有更多的細節，這是很難做到準確，但我可以推測：

• SqlBulkCopy通常快，所以你插入的可能不是瓶頸。你可以做得比數據錶快一點，但這可能不是問題。
• DataTable s可以有「索引」;即主鍵和約束。這些實施效率非常低下 - 這肯定會造成問題。
• 雖然SqlBulkCopy很快，但最好用很多行。如果您只複製SqlBulkCopy的1個文件，那意味着30000個調用，並且數據庫端可能至少有30000個fsyncs。您應該只使用一個SqlBulkCopy。
• 您的數據庫可能對您插入的行有索引或約束;這些會嚴重限制性能 - 檢查數據庫負載。
• .NET中的大多數xml讀取器速度相當快，但單個線程上的10MB/s可能會推動它。如果您的訪問模式特別糟糕（例如，加載完整的XmlDocument並查詢大量低效循環和/或XPath），則可能會遇到CPU負載問題。
• 20KB文件相當小。如果您正在從硬盤讀取這些數據，要達到1MB/s，您需要每秒讀取50個數據，即延遲20ms。這可能是一個問題，特別是如果文件非順序位於磁盤上。並行化可能會有所幫助，但SSD可以幫助更多（並且兩者都會更好）。然而，你看到的性能比這更低，所以這可能不是你的主要瓶頸。

考慮到這一點，我想看看這樣的順序以下客戶

• 磁盤負載（如果磁盤等待時間很長，考慮的SSD和併發）
• CPU負載 - 型材（低效率的分析或濫用DataTable S）
• SqlBulkCopy實例 - 使用一個（每線程）僅
• 數據庫負載（擺脫你可以在任何指標，包括如果可能的話聚集索引）

順序由是多麼困難，檢查這個問題啓發。磁盤負載不太可能有問題，但檢查起來並不重要，所以你最好先消除這種可能性。數據庫模式的問題都不是不可能的，但他們更多的工作，以確定（該指數是吧，我是通過去除它影響到另一個工作流？）所以我會檢查這些最後。