我尝试使用azure存储，并且在我使用它时无法提供真实场景。据我所知，表存储唯一的索引是Partition Key和Row Key。我无法在不进行完整的分区扫描的情况下对其他列进行排序或查询，对吧？
如果我要从传统的sql服务器迁移我的博客服务，或者像Mongo这样更丰富的nosql数据库，我可能会没问题，考虑到用户不会在一年内博客那么多（我会根据每个用户对所有博客文章进行分区）每年例如）。即使有人每年会发布大约一千篇博文，我也可以在内存中加载所有元数据。如果能够很好地运作，我可以做更聪明的分区。
如果我将持久聊天服务迁移到表存储，我该怎么做？用户每天发布数千封邮件，并经常从桌面客户端，移动设备，网站等查询历史记录。我不想在此丢失，只返回1天的分页历史记录（也可能很慢）
任何想法或模式或我在这里缺少什么？
btw我可以随时使用不同的数据库，但考虑到Table Storage非常便宜，我不想这样做。
答案 0 :(得分：0)
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/）具有更详细的示例，并具有设计可伸缩和高性能表所需的所有信息。
我们需要更多信息来回答您关于如何将聊天服务的内容迁移到表存储的第二个问题。我们需要了解您当前存储在聊天服务中的数据的格式和结构。