Question

任何人都知道或有过设计天蓝色桌子以适应动态搜索的经验吗？我有一个图书馆课程：

public class LibraryDocument
{
    public string DocumentNumber { get; set; }
    public string Complaint { get; set; }
    public string Respondent { get; set; }
    public string DocumentDate { get; set; }
    public string Division { get; set; }
    public string DocumentType { get; set; }
    public string Content { get; set; }
    public string Footer { get; set; }
    public string Title { get; set; }
    public string[] FooterItems { get; set; }
    public string[] RespondentList { get; set; }
    public string[] ComplaintList { get; set; }
}

我需要将其转换为azure表。

Input:客户将通过api发送关键字 Process:系统必须能够匹配所有库数据中的关键字 Output:返回匹配数据的分区键和Rowkeys

我想不出更好的方法来设计所需的表格有什么建议吗？

Answer 1

Azure存储表并非旨在支持此类用法，主要是因为行的唯一索引是其PartitionKey + RowKey的组合，因此任何不依赖于PK（至少）和RK的查询都是非常低效的（服务器基本上会解析所有行！）。

我建议看看Lucene.NET，这是一个可以在Azure上部署的搜索引擎。一些资源：

Answer 2

我认为表存储通常不是动态搜索的绝佳解决方案。我建议您考虑将Lucene.NET与Azure Directory https://azuredirectory.codeplex.com/或其他搜索引擎一起使用来实现此逻辑。

但是，如果您必须让ATS提供搜索功能，请考虑创建两个表： LibraryDocuments表将包含所有LibraryDocument对象。 PartitionKey / RowKey组合将是唯一的，并为每个文档提供业务含义/密钥信息。创建一个LibraryIndex表，它将partitionKey关闭每个可能的关键字和LibraryDocument的PartitionKey / RowKey conctatinated组合的RowKey，其中可以找到该关键字。 IE：索引表将为LibraryDocuments提供索引

这样，您的搜索将始终是PartitionKey，因此更快。但是，此搜索可能仍会执行多个请求，因为partitionkey匹配可以跨越多个存储事务并需要延续令牌（etags）此外，您将无法进行“包含”类型的搜索，并且通常会将此系统放在任何地方，然后进行基本关键字搜索，或者最好是“开始”搜索。

HTH

在天蓝色的桌子上动态搜索

2 个答案: