Azure表存储中的表设计

Question

我应该使用azure组织用于消息传递的REST服务。现在我有DB的问题。我有3个表：用户，聊天，聊天消息。

1. 用户包含用户数据，如登录，密码哈希，盐。
2. 聊天包含分区密钥 - 用户登录，rowkey - chatId，nowInChat - 用户来自聊天。
3. 聊天消息包含分区键，由...组成 userlogin_chatId_datetimeticks （zevis_8a70ff8d-c363-4eb4-8a51-f853fa113fa8 _634292263478068039）， rowkey - messageId，message，sender - userLogin。

我在设计中看到了一些缺点，例如，如果你想象一年前用户是积极沟通的，现在不说话，而且其中一个想看历史，那么我就得发一个使用时间间隔（例如一周）请求数据的大量服务器请求。以低于今天的时间发送请求将无效，因为我们得到了整个故事。 我们应该如何改变表的设计？

Answer 1

由于Azure存储表不支持二级索引，并且存储非常便宜，因此最佳选择是使用不同的分区和/或行键将数据存储两次。从Azure存储表设计指南：

  

要解决缺少二级索引的问题，可以存储多个索引   每个实体的副本，每个副本使用不同的PartitionKey和   RowKey值

https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#table-design-patterns

Answer 2

感谢您的帖子，您有两种选择。设计更改量最少的最简单答案是在Chat表中包含StartTime和EndTime。虽然这些属性不会被编入索引，但我猜测一旦过滤UserID就不会有很多行要扫描。

第二个选项需要更多工作，但更干净，是创建一个包含Partition Key = UserID，Row Key = DateTimeTicks的附加表，并且您的实体属性将包含ChatID。这样，您就可以在给定的日期/日期范围内快速按用户进行过滤。 （这是上面提供的非规范化答案）。

希望这有助于您的设计进度。

Answer 3

我会创建一个包含这些PK和RK值的单独表： 分区键= UserID，行键= DateTime.Max - DateTimeTicks

您也可以选择将ChatId附加到上面行键的末尾。

这样，用户进行的最新通信将始终位于最前面。因此，您稍后可以通过仅传入UserId和获取计数来简单地查询表（即，如果您想要来自用户的最新聊天条目，则获取Count = 1）。查询也将非常快，因为由于您对行键使用反向刻度，因此azure表存储服务将按照行键的字典顺序对相同用户ID的条目进行排序，始终将最新的聊天保留在分区之上它将具有最小反转刻度值。

即使您在RowKey的末尾添加了聊天ID（即InvertedTicks_ChatId），排序顺序也不会改变，并且无论聊天ID如何，最新的对话都将在最前面。

再次读取实体后，从DateTime.Max中减去反转的刻度以查找实际日期。