什麼是Azure表存儲日誌數據更好的計數算法？

我第一次使用Windows Azure並冒險進入Azure表存儲，以便使我的應用程序可以擴展到高密度流量負載。我的目標很簡單，就是根據一組參數記錄每個傳入請求並報告計數或彙總日誌中的數據。在這裏我已經提出了2個選項，我想知道更多有經驗的人認爲是更好的選擇。什麼是Azure表存儲日誌數據更好的計數算法？

選項1：使用布爾值和計數的「真」行

因爲每行寫一次，從不更新，存儲每個計數參數爲bool，並在總結線程，拉在一個查詢的行並對每組真值進行計數以獲得每個參數的總計。如果有很多參數，這將節省空間，因爲我想Azure Tables將bool存儲爲單個位值。

選項2：使用int值和總和的行

每一行被寫入如上述，而是每個參數列被添加作爲0或1求和的值將通過查詢所有行的發生和對每列使用Sum操作。這會更快，因爲Summation可能發生在單個查詢中，但是我爲保存布爾值的32位整數而丟失了一些東西嗎？

我認爲在這一點上的查詢速度，選項2是最好的，但我想大聲問一下存儲和檢索方面的意見，因爲我不知道Azure表很好（我希望這有助於其他人在路上）。

來源

2011-06-11 eudaimos

表存儲不會執行聚合服務器端，因此對於這兩個選項，您最終會在本地抽取所有行（及其所有屬性）並計數/求和。這使得它們在性能上同樣糟糕。 :-)

我覺得你最好保持一個跑步總數，而不是每次重新總結一切。我們在Cloud Cover Episode 43上談到了幾個模式：http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-43-Scalable-Counters-with-Windows-Azure

來源

2011-06-11 23:23:26 smarx

我已經在發佈我的問題之前看過您的博客文章並下載了源代碼。我確實看過這集，儘管它非常令人難以忍受（iPad的iTunes下載音頻很好，但視頻很可怕 - 不要再停下來一遍又一遍地停下來 - 這使得它完全無法觀看），並在我的筆記本電腦上觀看網絡，並保持緩衝（速度最快。網絡說我的con是2.88 Mbps的下載）。所以我花了一個半小時才完成了30分鐘的劇集。供參考的是，對於那些進入的人來說，他們開始談論跟蹤計數的模式，他們在9:30開始討論。 – eudaimos 2011-06-12 21:32:00

@smarx我以爲你爲你的博客實施了評論。他們發生了什麼？您應該在展示結束時用您的評論更新博客文章和源代碼，以便將DeploymentId用作分區。 – eudaimos 2011-06-12 21:58:48

@smarx最後，我對你的答案的看法：所以你說我不應該真的使用日誌和計數日誌數據b/c它最終會成爲一個大的拉動序列化XML和通過HTTP B/c所有聚合不能在本地完成。這是否意味着更好的紋理對象（更少的屬性）b/c它們更容易拉回來？我能做的最好的計數就是在每個線程的計數上進行同步，是不是已經保證了？我走了日誌數據B/C的方式，我根本不需要任何鎖。 – eudaimos 2011-06-12 22:07:42

什麼是Azure表存儲日誌數據更好的計數算法？

回答

相關問題