gpt4 book ai didi

azure - 关于Azure表设计

转载 作者:行者123 更新时间:2023-12-02 06:50:08 24 4
gpt4 key购买 nike

我是一名自由职业者,目前正在开发我的一款游戏,并尝试使用 Azure 表服务在 Azure 表中记录我的用户移动。该游戏基于纸牌。

流程是这样的:

许多用户(UserId)将在一张 table (TableId)上玩。 table 上的每个游戏都会有一个唯一的 GameId。每个游戏中可能有多个具有唯一 DealId 的交易。同一张 table 上可以有多个具有相同 gameId 的交易。此外,每个用户在单个游戏中都会有相同的 DealId。

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

问题:

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

TableId GameId DealId UserId 时间戳1 201 300 123451 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 作为 RowKeyGameLogsByGameId -- 这会将 GameId 作为 PartitionKey,将 GUID 作为 RowKeyGameLogsByUserId -- 这会将 UserId 作为 PartitionKey,将 GUID 作为 RowKeyGameLogsByDealId -- 这会将 DealId 作为 PartitionKey,将 GUID 作为 RowKey

请问有什么想法吗?

TableId、GameId、DealId、UserId 格式较长。

我想查询数据,以便

  1. 从 TableId 获取所有日志。
  2. 获取 TableId 和特定游戏 (GameId) 中的所有日志
  3. 获取此游戏(GameId) 中用户(userid) 的所有日志
  4. 获取某个用户在一笔交易中的所有日志(dealId)
  5. 从表中获取某个日期的所有日志;对于用户、游戏和交易也是如此

最佳答案

根据我迄今为止对 Azure Tables 的了解,我相信您的方向是正确的。

但是有一些事情我想提一下:

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

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

0 预先填充您的 Id 值,使它们的字符串长度相等您提到您的 id 值很长。但是 PartitionKey 值是 string 类型。我建议预先填充这些值,使它们的长度相等。例如,将 Game Id 存储为 PartitionKey 而不是将其存储为 12103 等时,请将它们存储为 000000000010000000000200000000103。这样,当您列出所有 Id 时,它们将按正确的顺序排序。如果不进行预填充,您将得到的结果为 1, 10, 11, 12....19, 20。

您将失去交易支持

由于您使用的是多个表(甚至是具有不同 PartitionKeys 的单个表),因此您将无法使用 Azure 表中提供的实体批量事务,并且所有插入都需要按照以下方式完成原子操作。由于每个操作都是网络调用,并且可能会失败,因此您可能希望通过幂等后台进程来执行此操作,该进程将继续尝试将数据插入到多个表中,直到成功为止。

我建议您创建一个基于其他值的复合 RowKey,而不是 RowKey 的 Guid

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

分区扫描

我查看了您的查询要求,几乎所有这些要求都会导致分区扫描。为了避免这种情况,我建议保留更多的数据副本。例如,请考虑查询要求中的 #3 和 #4。在这种情况下,您需要扫描用户的整个分区,以查找有关游戏 ID 和交易 ID 的信息。因此,请为表服务仅返回延续 token 的情况做好准备。

关于azure - 关于Azure表设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35547761/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com