我们的应用程序中有一个工作空间的概念。用户可以是几乎任何数量的工作空间的成员，并且工作空间可以具有几乎任何数量的用户。我想实现一个活动源，以帮助用户找出他们所属的每个工作区中发生的事情，即当有人上传文件或在工作区中创建任务时，此活动会显示在该工作区的活动中Feed以及每个用户的活动Feed。问题是我无法提供合适的数据结构来快速读取和写入活动。我想出的是使用属性Targets存储每个活动，该属性是所有工作空间的用户ID的字符串，然后过滤活动，其中该字段包含我想要获取活动的用户的ID但是，这种方法具有严重的性能和可伸缩性限制，因为我们使用SharePoint作为我们的存储。我们也可以使用Azure表或Blob存储，我只想为工作区的每个用户创建一个单独的活动实体，这样我就可以轻松地按用户的ID过滤活动，但这可能导致数百个如果工作空间有数百个成员然后编写所有这些副本，则相同活动的副本会出现问题，因为Azure在单个批处理操作中仅支持100个实体（如果我错了，请更正我），然后SharePoint不是一个选项一点都不因此，我需要帮助确定我可以使用哪些数据结构来存储每个工作区的活动，以便它们可以通过其id以及任何工作区的ID来轻松检索任何成员。
答案 0 :(得分：1)
我们也可以使用Azure Table或Blob Storage，我只想为工作区的每个用户创建一个单独的活动实体，这样我就可以轻松地按用户的id过滤活动
Azure存储表可以作为存储活动实体的选择，而表存储相对便宜，您可以考虑将多个相同的实体（使用不同的分区策略）存储在单独的分区中或单独的表中以便有效地读取。
使用workspaceid_userid作为复合键存储用户的活动实体也是一种可能的方法。有关更多详细的表格设计模式，请参阅this article。
Azure在单个批处理操作中仅支持100个实体（如果我错了，请纠正我）
是的，单个batch operation最多可包含100个实体。