Azure表中的表格设计存储

我应该使用azure为REST服务组织消息传递。现在我遇到了数据库问题。我有3个表格：用户，聊天，聊天消息。Azure表中的表格设计存储

用户包含用户数据，如登录，密码哈希，盐。
交谈包含partitionkey - userlogin，rowkey - chatId，nowInChat - 用户来自聊天。聊天的
消息包含partitionkey，至极由 userlogin_chatId_datetimeticks （zevis_8a70ff8d-c363-4eb4-8a51-f853fa113fa8 _634292263478068039） rowkey - MESSAGEID，消息发送者 - 用户登陆。

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

来源

2016-03-27 ZeViS

我认为你需要更加规范化你的数据;这通常在NoSQL键值数据库中完成，以解决这样的问题。 –

因为Azure存储表不支持二级索引和存储是非常便宜的，最好的选择是存储数据的两倍，采用不同的分区和/或行键。从Azure存储表设计指南：

要解决缺乏二级索引，可以存储与每个各实体的多个副本复印件使用不同的PartitionKey和 RowKey值

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

来源

2016-03-29 21:27:57

感谢您的留言，您有两种选择。用最少的设计更改最容易的答案是在聊天表中包含StartTime和EndTime。虽然这些属性不会被编入索引，但我猜测在筛选UserID后不会有很多行要扫描。

第二个选项需要更多的工作，但清洁剂，将创建一个分区键=用户名的附加表，行键= DateTimeTicks和你的实体属性将包含ChatID。这将使您能够在给定的日期/日期范围内快速过滤用户。（这是上面提供的非规范化答案）。

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

来源

2016-03-31 22:10:07

我将创建一个单独的表与这些PK和RK值：分区键=用户名，行键= DateTime.Max - DateTimeTicks

您也可以选择追加ChatId上述行键结束。

这样用户所做的最新通信将始终在最前面。所以你稍后可以通过仅传入UserId和一个计数来简单地查询表（即如果你想从用户那里获得最新的聊天记录，取计数= 1）。查询速度也会非常快，因为由于您使用的是反转行号作为行键，因此天青表存储服务会按增加行键的字典顺序对相同用户标识的条目进行排序，并始终将最新的聊天记录保留在分区顶部它将具有最小反转刻度值。

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

一旦你读完了实体，你就从DateTime.Max中减去倒置的滴答来找到实际的日期。

来源

2016-04-08 09:30:12

Azure表中的表格设计存储

回答

相关问题