是否可以在 SQL Azure 中創建數百個數據庫而不是一個大數據庫並冒死鎖的風險
我需要創建高度可擴展的解決方案——數千個站點中的現場設備將數據實時傳送到後端系統，而 SQL Azure 在添加 sql 數據庫和應用程序伺服器方面似乎非常適合。
每個現場設備每秒有效地發送 400 個感測器值 - 每天大約兩個小時，而所有其他時間每 5 分鐘發送 400 個感測器值。此外，當該現場設備發生錯誤時，它還會發送所有 400 個感測器的最後一分鐘數據（400 * 60 個讀數）——當出現任何問題時會導致大量數據。
我真的很想設計系統，使獨立的現場設備及其儲存的數據不會影響其他設備。允許每個現場設備不影響其他現場設備的性能。
我開始設計時考慮使用單個數據庫來保存所有設備的數據 - 但在模擬多個站點設備時已經開始出現死鎖。因此，我正在轉向多數據庫解決方案。主數據庫保存所有設備的查找表 - 將連接字元串返回到真實數據庫
在項目的這個階段，最重要的是我能夠將這些數據實時傳遞回在 Web 瀏覽器中執行的使用者界面——每秒更新他們的螢幕。
在項目的未來階段，有必要開始跨多個設備聚合數據，顯示統計數據，例如區域 Y 中感測器 X 的總和。我可以看到這對於多數據庫方法來說很難做到。
所以會重視任何建議，例如
您認為使用 Sql Azure 託管潛在的 1000 個數據庫並使用此主數據庫間接指向真實數據庫是否明智？
從應用程序到數據庫的連接是否會出現問題 - 例如連接池問題？
我將如何從 Sql Azure 中的所有這些不同數據庫中聚合數據。
會對您的所有評論感興趣。問候，克里斯。
我想我會發布一個關於項目實際如何運作的快速答案。
最後，我們沒有使用 Azure。我們使用標準 SQL 數據庫伺服器 - 每個引擎都位於不同的數據庫中。理論上，主數據庫保存每個引擎的連接資訊。因此可以在不同的數據庫伺服器上儲存不同的引擎。在實踐中，我們還不需要這樣做。目前我們在一台機器上有 200 個引擎數據庫。我使用連接池。
每個引擎每秒到達的 400 個感測器以 XML 格式發送，轉換為 DataTable，並使用自定義數據類型批量插入 SQL 數據庫。每秒插入 400 條記錄只需要 40ms - 70ms。我對現有數據集進行了外部連接，以應對現有數據重新發送的情況。
該系統的編寫方式使得每個引擎在理論上不應減慢其他引擎的速度。每個引擎都在其自己的執行緒池中進行有效管理。這些執行緒池可以存在於不同的伺服器中。對數據庫的寫入和每個使用者界面（Web 瀏覽器）的更新是在單獨的執行緒中完成的，因此使用者不必等待數據庫完成插入。
我們現在處於一個位置，我們準備將這個概念帶入 Azure。現在 Azure 中的限制似乎不像撰寫本文時那麼多。
由於沒有其他人回答，我將分享一些意見並揮手。
只要您不鎖定公共資源，或者以相同的順序鎖定資源，就不會出現死鎖問題。
我會在單獨的數據庫之前查看單獨的表。每個額外的數據庫肯定會花費更多，但額外的表不一定會花費更多。您可能需要使用超過 1 個數據庫，因為您將儲存大量數據，或者因為您需要儲存突發流量的速率。如果您可以管理它，我認為表級粒度將比從數據庫級粒度開始更靈活，並且可能便宜很多。
將每個設備的數據放入它自己的表中的問題在於，它使報告變得困難，因為所有表名都不同。
我認為您有某種方法可以檢測何時收到“重新發送失敗”的數據。您不想將相同的值兩次放入表中，我確信設備可能會發生故障（本地電源故障？），而與早期值是否正確儲存無關。
WAG：假設每個“值”為 4 個字節，我計算出每台設備每天收集的數據約為 11.5 MB。（這忽略了各種東西，例如設備標識符和時間戳，但我認為粗略估計是可以的。）因此，對於“數千”個站點，我們每天查看數十 GB。您沒有提到該數據的任何生命週期。最大的 Azure 數據庫目前最大為 150 GB。你可以很快填滿這些。
在短時間內在網路瀏覽器中發生任何事情是不確定的。當您從（可能是多個）具有 GB 數據的數據庫中讀取數據時，不斷地將大量新數據插入到您正在讀取的表中並通過開放的 Internet 與 Web 伺服器進行互動時，“實時”是一廂情願的想法。國際海事組織。“足夠快”是通常的目標。
如果您無法將所需的所有數據保存在一個 SQL Azure 數據庫中的單個報告中，那就是個問題。沒有連結伺服器或分佈式視圖（此時）。沒有簡單的方法可以跨多個 Azure 數據庫進行聚合。您必須將所有數據拉到一個中心位置並從那里報告。我猜聚合數據太大而無法儲存在單個 SQL Azure 數據庫中，因此您必須轉到本地或 EC2。具有星型架構結構的數據集市或倉庫將是那裡的經典答案，但這需要大量的處理時間，這意味著沒有“實時”。此外，這可能會導致從 Azure 到任何地方的更多數據傳輸，這將花費您。
如果沒有先行試點計劃，我不會採用這種策略。首先要做的是建構一個實例（它可以每秒處理 400 個感測器值嗎？（是一系列行、一個大的非規範化行、一個 XML 文件還是其他什麼？傳入數據的格式會影響數據可以儲存多快。您可以進行批量插入，還是必須逐行進行？）每秒 4,000 個感測器值怎麼樣？單個 SQL Azure 實例可能無法儲存該值很快。）並查看它如何以您的預期速率處理插入，並查看報告如何工作。我也會和微軟談談。僅僅處理成百上千個獨立數據庫的計費可能很奇怪。
我不知道這是否適用於你，但你看過微軟的“Stream Insight”產品嗎？它似乎是針對像你這樣的情況。警告：我從未使用過它。
行銷宣傳：有效分析來自多個來源的大量事件數據。使用 Microsoft StreamInsight 近乎實時地從關鍵資訊中獲取見解。監控、分析和處理動態數據並幾乎立即做出明智的決策
在快速進行Google搜尋時，我注意到一篇部落格文章指出，StreamInsight 去年可作為 CTP 在 SQL Azure 上使用。它現在可能已經準備好迎接黃金時段了。
祝你好運，這聽起來是一個有趣的項目。