活動數據結構的饋

Question

有一個在我們的應用程序工作區的概念。用戶可以是幾乎任何數量的工作空間的成員，並且工作空間實際上可以具有任意數量的用戶。我想實現一個活動源，以幫助用戶找出他們所屬的每個工作區發生了什麼事情，例如，當某人上傳文件或在工作區中創建任務時，此活動將出現在該工作區的活動源中以及每個其用戶活動供稿。問題是我無法想出一個合適的數據結構來快速讀取和寫入活動。我想出了存儲着每個活動與屬性Targets這是所有工作區的用戶ID的字符串，然後過濾，其中該字段包含了我希望獲取的活動用戶的ID活動，但這種方法存在嚴重的性能和可伸縮性限制，因爲我們使用SharePoint作爲存儲。我們還可以使用Azure Table中或Blob存儲，我想只是一個工作空間的每個用戶創建一個單獨的活動實體，以便然後我就可以很容易地通過用戶的ID過濾的活動，但是這可能會導致數百相同的副本活動如果一個工作區有數百個成員，然後編寫所有這些副本變得有問題，因爲Azure在單個批處理操作中僅支持100個實體（如果我錯了，請糾正我），然後SharePoint根本不是一個選項。因此，我需要幫助確定可以使用哪種數據結構來存儲每個工作區的活動，以便他們可以通過其id來輕鬆檢索任何成員，也可以通過工作區id檢索任何工作區。

Answer 1

我們還可以使用Azure Table中或Blob存儲和我的想法只是創建一個單獨的活動實體爲工作區的每一位用戶，這樣，然後我就可以很容易地通過用戶的ID過濾活動

Azure存儲表可以作爲存儲活動實體的選擇，並且表存儲相對便宜，您可以考慮將同一實體多次（使用不同的分區策略）存儲在單獨的分區中或單獨的表中以便高效讀取。

和存儲用戶的活動實體workspaceid_userid作爲化合物鍵還可以是一種可能的方法。有關更多詳細的表格設計模式，請參閱this article。

天青僅支持單個批量操作100個單位（糾正我，如果我錯了）

是，一個單一的batch operation可以包含多達100個實體。