許多開發人員正在尋找一種將現有應用程序集成到SQL Azure Federations並替換Identity列(我的表的主鍵)的大問題。因爲很多原因,我不想爲我的主鍵使用GUID(請不要打開關於GUID的爭論,這不是我的問題:我只是不想要GUID,句點)。SQL Azure聯合身份驗證替代方案:是Azure隊列還是服務總線隊列是一個不錯的選擇?
因此,我需要構建一個關鍵提供程序來替換標準SQL數據庫的「身份」功能。我正在使用實體框架,因此我可以輕鬆找到一個位置,在插入前設置Id
值(通過覆蓋我的ObjectContext
類的SaveChanges
方法)。我只需要找到一個「不太複雜」的實現來獲取當前的ID,即「農場就緒」。
我讀過這個SO貼子:「ID Generation for Sharded Database (Azure Federated Database)」和「Synchronizing Multiple Nodes in Windows Azure來自MSDN Magazine」,但這個解決方案聽起來有點複雜。
我正在考慮爲每個SQL表創建(自動)一個天藍色的隊列,它包含一個連續整數的預先加載的列表。當我想要一個Id值時,我只需要從隊列中獲取一條消息(它將變爲不可見並在路上被刪除),這會給我當前可用的Id。
關於「Windows Azure隊列」和「Windows Azure服務總線隊列」之間的選擇,由於"high" latency of Service Bus Queues的原因,我推薦「Windows Azure隊列」。 我不認爲缺乏Azure隊列的「訂購保證」是一個問題。
您如何看待使用Azure隊列提供Id值的想法?你看到有什麼理由放棄這個想法嗎?您是否有更好的主意,甚至是一個很好的習慣,在SQL Azure Federation數據庫中提供整數ID? 謝謝。
編輯:
Astaykov建議SnowMaker。我終於完成了一個fork of SnowMaker與Azure存儲庫的v2完全兼容。
EDIT 2
請注意,Azure的SQL聯合會將退役2015年9月與網絡和業務層,作爲解釋here。但是這個問題對於自定義分片解決方案仍然有效。
感謝您指出了這一點。不幸的是,SnowMaker與Azure存儲庫v2 +不兼容,所以我不得不重寫BlobOptimisticDataStore類,而現在我只是在嘗試它。這個身份問題真的給了我一個關於SQL Federations不完整的感覺......真遺憾。順便說一句,謝謝你的回答! – JYL
有兩件事:您可以安全地將Azure Storage Client 1.7.XX與Azure.Storage 2.X一起引用,以使SnowMaker正常工作。或像你一樣修復它與存儲2一起工作。 – astaykov
我同意你的觀點,即身份在可伸縮性方面不能解決任何問題。但有時我們不需要可擴展性,我們只需要一個易於設置的小型多租戶系統。在這種情況下,標識列不是問題。 我看到SQL Azure Federation是將我的單租戶應用程序遷移到多租戶應用程序的一種簡單方法。事實上,這並不容易(至少現在是這樣)。對於身份的特殊情況,我理解並接受這一限制,但我只是很傷心,微軟沒有提供任何指導來取代它(當然除了GUID)。 – JYL