使用表存储创建博客服务或持久聊天

Question

我正在尝试 azure 存储，但在使用它时无法想出现实生活中的场景。据我了解，表存储唯一的索引是分区键和行键。如果不进行完整的分区扫描，我无法对其他列进行排序或查询，对吧？

如果我要从传统的 sql 服务器或像 Mongo 这样更丰富的 nosql 数据库迁移我的博客服务，考虑到用户在一年内不会写那么多博客，我可能会没问题（我会为每个用户每年划分所有博客帖子例如）。即使有人每年会发表大约一千篇博客文章，我也可以将所有元数据加载到内存中。如果这不起作用，我可以进行更智能的分区。

如果我要将我的持久聊天服务迁移到表存储，我会怎么做？用户每天发布数千条消息并经常从桌面客户端、移动设备、网站等查询历史记录。我不想在这方面迷失，只返回 1 天的分页历史记录（这也可能很慢）。

任何想法或模式或我在这里遗漏了什么？

顺便说一句，我总是可以使用不同的数据库，但是考虑到 Table Storage 太便宜了，我不想这样做。

Answer 1

PartitionKey 和 RowKey 值是仅有的两个索引属性。要解决缺少二级索引的问题，您可以存储每个实体的多个副本，每个副本使用不同的 RowKey 值。例如，一个实体的 PartitionKey=DepartmentName 和 RowKey=EmployeeID，而另一个实体的 PartitionKey=DepartmentName 和 RowKey=EmailAddress。这将允许您通过 EmployeeID 或 emailAddress 进行查找。 Azure 存储表设计指南 (http://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/) 提供了更详细的示例，并提供了设计可扩展和高性能表所需的所有信息。

我们需要更多信息来回答您关于如何将聊天服务的内容迁移到表存储的第二个问题。我们需要了解您当前存储在聊天服务中的数据的格式和结构。