2

我是一名自由职业者，现在正在开发我的一款游戏，并尝试使用 Azure 表服务将我的用户移动记录在 Azure 表中。游戏以卡牌为基础。

流程是这样的：

许多用户（UserId）将在一张桌子（TableId）上玩。桌上的每个游戏都有一个唯一的 GameId。在每个游戏中，可能有多个具有唯一 DealId 的交易。同一张桌子上可以有多个具有相同 gameId 的交易。此外，每个用户在单个游戏中都将拥有相同的 DealId。

获胜者是在玩家多次机会后决定的。

问题：

我可以将 TableId 设为 PartitionKey，但我不确定为 RowKey 选择什么，因为 TableId 和 RowKey (GameId/UserId/DealId) 的组合在表中应该是唯一的。我可以有这样的条目：

TableId GameId DealId UserId 时间戳 1 201 300 12345 1 201 300 12567

可能我可以做的是创建 4 个 Azure 表，如下所示，但我做了很多重复；我也不能像这里提到的那样触发点查询https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#guidelines-for-table-design

GameLogsByTableId -- 这将有 TableId 作为 PartitionKey 和 GUID 作为 RowKey GameLogsByGameId -- 这将有 GameId 作为 PartitionKey 和 GUID 作为 RowKey GameLogsByUserId -- 这将有 UserId 作为 PartitionKey 和 GUID 作为 RowKey GameLogsByDealId -- 这将有 DealId 作为 PartitionKey 和 GUID作为 RowKey

请问有什么想法吗？

TableId、GameId、DealId、UserId的格式很长。

我想查询这样的数据

  1. 从 TableId 中获取所有日志。
  2. 从 TableId 和特定游戏中获取所有日志（GameId）
  3. 在这个游戏（GameId）中获取用户（userid）的所有日志
  4. 获取交易中用户的所有日志（dealId）
  5. 给我一个日期表中的所有日志；同样对于用户、游戏和交易
4

2 回答 2

2

根据我迄今为止对 Azure Tables 的了解，我相信您走在正确的轨道上。

不过有几点我想提一下：

您可以使用单个表来存储所有数据

尽管这种方法在逻辑上很好地分离了数据，但您实际上并不需要使用单独的表来存储每种数据。如果需要，您可以将它们存储在一个表中。如果您使用单个表，因为这些 id（游戏、表、用户和交易）是数字，所以我建议适当地为值添加前缀，以便您可以很好地识别它们。例如，当指定表示游戏 ID 的 PartitionKey 时，您可以在该值前面加上前缀，G|以便您知道它是游戏 ID，例如G|101。

预先填充您的 Id 值0以使它们等长字符串 您提到您的 id 值是long. 但是该PartitionKey值是string类型的。我建议预先填充这些值，使它们具有相同的长度。例如，当将 Game Id 存储为 PartitionKey 而不是将它们存储为1,等时，将它们存储2为, , 。这样，当您列出所有 Id 时，它们将按正确顺序排序。如果没有预填充，您将获得 1、10、11、12....19、20 的结果。103000000000010000000000200000000103

您将失去交易支持

由于您正在使用多个表（甚至是具有不同 PartitionKeys 的单个表），因此您将无法Entity Batch Transactions在 Azure 表中使用可用的，并且所有插入都需要作为原子操作完成。由于每个操作都是网络调用并且可能会失败，因此您可能希望通过幂等后台进程来执行此操作，该进程将继续尝试将数据插入到多个表中，直到成功为止。

而不是 Guid for RowKey，我建议你创建一个RowKey基于其他值的复合

这更适用于更新场景。由于更新需要PartitionKey和RowKey，我建议使用RowKey作为其他值的组合创建的 a 。例如，如果您使用TableIdas PartitionKey for GameLogsByTableId，我建议RowKey使用其他值创建一个，例如U|[UserId]|D|[DealId]|G|[GameId]. 这样，当您获取要更新的记录时，您会自动知道如何创建一个RowKey而不是先从表中获取数据。

分区扫描

我查看了您的查询要求，几乎所有这些要求都会导致Partition Scans. 为避免这种情况，我建议保留更多重复的数据副本。例如，在您的查询要求中考虑 #3 和 #4。在这种情况下，您需要扫描整个分区以查找用户以查找有关 Game Id 和 Deal Id 的信息。因此，请为表服务只返回延续令牌的情况做好准备。

于 2016-02-22T12:37:21.257 回答
0

就个人而言，除非您有绝对海量的数据需求，否则我不会为此使用表存储。它会让你的工作比使用 SQL 数据库困难得多；您可以使用任何您喜欢的索引，具有关系完整性等等。唯一支持 ATS 的是它对于大数据来说很便宜。

于 2016-03-14T22:04:45.510 回答