簡體 English 中英

Azure表或SQL Azure？

[英]Azure Tables or SQL Azure?

原文 2010-04-15 05:24:52 8 11 azure/ azure-sql-database/ azure-table-storage

我正處於Web應用程序的規划階段，該應用程序將在Azure中托管，其中包含用於Web站點的ASP.NET和用於豐富用戶體驗的Silverlight。 我應該使用Azure Tables還是SQL Azure來存儲我的應用程序數據？

11 個解決方案

Azure表存儲似乎比SQL Azure便宜。 它的可伸縮性也高於SQL Azure。

如果您已經進行了大量的關系數據庫工作，SQL Azure更容易使用。 如果您正在移植已經使用SQL數據庫的應用程序，那么將其移動到SQL Azure將是明顯的選擇，但這是我推薦它的唯一情況。

Azure Tables的主要限制是缺少二級索引。 這是在PDC '09宣布，目前即將上市，但沒有任何時間框架公告。 （參見http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title ）

我已經看到了建議使用混合系統，其中您使用表和blob存儲來存儲大量數據，但是使用SQL Azure進行索引，搜索和過濾。 但是，我自己還沒有機會嘗試這種解決方案。

將二級索引添加到表存儲后，它將基本上是基於雲的NoSQL系統，並且比現在更有用。

盡管SQL Azure表和表存儲具有相似的名稱，但它們的共同點很少。

以下是兩個可能對您有幫助的鏈接：

基本上，第一個問題應該想知道我的應用程序是否真的需要擴展？ 如果沒有，那么去SQL Azure。

對於那些試圖在兩個選項之間做出決定的人，一定要將報告要求納入等式。 SQL Azure Reporting和其他報告產品支持SQL Azure開箱即用。 如果您需要生成復雜或靈活的報告，您可能希望避免使用表存儲。

Azure表比SQL Azure更便宜，更簡單，擴展性更好。 SQL Azure是一種托管SQL環境，本質上是多租戶，因此您應該分析您的性能要求是否適合SQL Azure。 SQL Azure的高級版本已經公布，並且在撰寫本文時已預覽（參見此處）。

我認為決定SQL Azure和Azure表之間的決定性因素如下：

您是否需要進行復雜連接並使用二級索引？ 如果是，SQL Azure是最佳選擇。
你需要存儲過程嗎？ 如果是，SQL Azure。
您需要自動縮放功能嗎？ Azure表是最佳選擇。
Azure表中的行大小不能超過4MB。 如果需要在一行中存儲大數據，最好將其存儲在blob存儲中並引用表行中的blob URI。
您需要存儲大量的半結構化數據嗎？ 如果是，Azure表是有利的。

盡管Azure表在簡單性和成本方面非常有益，但仍有一些限制需要考慮。 請參閱此處獲取一些初步指導。

另一個考慮因素是延遲。 曾經有一個微軟運行微型基准測試的站點使用表存儲和SQL Azure來處理各種對象大小的吞吐量和延遲。 由於該網站已不再可用，我將簡單地從您的回憶中給出一個粗略的近似值。 表存儲的吞吐量往往比SQL Azure高得多。 SQL Azure往往具有較低的延遲（多達1/5）。

已經提到表存儲很容易擴展。 但是，SQL Azure也可以與Federations一起擴展。 請注意，聯合（有效分片）會給應用程序增加很多復雜性。 我也不確定聯盟對性能有多大影響，但我想有一些開銷。

如果業務連續性是優先考慮的事項，請考慮使用Azure存儲，默認情況下可以獲得廉價的地理復制。 使用SQL Azure，您可以完成類似的操作，但需要花費更多精力與SQL Data Sync 。 請注意，SQL Data Sync也會產生性能開銷，因為它要求所有表上的觸發器監視數據更改。

我意識到這是一個老問題，但仍然是一個非常有效的問題，所以我正在添加我的回復。

CoderDennis和其他人已經指出了一些事實 - Azure Tables更便宜，Azure Tables可以更大，更高效等。如果你100％肯定你會堅持使用Azure，那么請使用Tables。

但是，假設您已經決定使用Azure。 通過使用Azure表，您可以將自己鎖定到Azure平台。 這意味着編寫非常特定於Azure表的代碼，而不僅僅是要移植到Amazon，您必須重寫代碼的這些區域。 另一方面，使用LINQ對SQL數據庫進行編程將更容易移植到另一個雲服務。

如果您已經決定使用雲平台，這可能不是問題。

我建議將Azure Cache與Azure Table結合使用。 僅表有200-300ms的延遲，偶爾會出現高峰，這可能會顯着減慢響應時間/ UI交互性。 對我來說，Cache + Table似乎是一個成功的組合。

對於您的問題，我想談談如何決定使用邏輯選擇SQL Table以及哪些需要使用Azure Table。

我們知道SQL Table是一個關系數據庫引擎。 但是如果你在一個表中有一個大數據，則SQL表不適用，因為SQL查詢得到的大數據很慢。

此時你可以選擇Azure表，Azure表查詢是如此之快，然后SQL表為大數據，例如，在我們的網站上，有人訂閱了很多文章，我們把文章作為用戶的饋送，每個用戶都有一份副本文章標題和描述，所以在文章表中有很多數據，如果我們使用SQL表，每個查詢執行可能需要超過30秒。 但在Azure Table中，PartitionKey和RowKey的用戶文章提取速度非常快。

從此示例中，您可能知道如何在SQL表和Azure表中進行選擇。

我想知道我們是否會在適當的時候最終得到一些“供應商獨立”的雲API庫？

我認為您首先要定義應用程序使用漏斗的內容。 您的數據模型是經常更改還是穩定的？ 你必須能夠執行超快插入和讀取不是那么復雜？ 你需要提前谷歌搜索嗎？ 存儲BLOBS？

這些是（並且不僅僅是）您必須自己提問和回答的問題，以便決定您是否更有可能在存儲數據時使用NoSql或SQL方法。

請考慮兩種方法可以輕松共存，也可以使用BLOB存儲進行擴展。

Azure表和SQL Azure都是兩種不同的野獸。它們適用於不同的場景，一個與azure表相關的是你不能從azure移動到任何其他平台，除非你在代碼中編寫可以處理這種轉換的提供者。