0

任何人都知道或有设计 azure table 以适应动态搜索的经验？
我有一个图书馆类：

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; }
}

我需要将其转换为天蓝色表。

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

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

4

2 回答 2

2

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

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

这样，您的搜索将始终与 PartitionKey 相协调，从而更快。但是，此搜索可能仍会执行多个请求，因为分区键匹配可以跨越多个存储事务并需要延续令牌（etags）此外，您将无法执行“包含”类型的搜索，并且通常将此系统带到比基本关键字搜索更远的任何地方或充其量是“开始”搜索。

高温高压

于 2013-10-30T04:22:10.920 回答
2

Azure Storage Tables 并不是为了支持这种用法而设计的，主要是因为行的唯一索引是它们的 PartitionKey + RowKey 的组合，所以任何不依赖 PK（至少）和 RK 的查询都是非常低效的（服务器将基本上解析所有行！）。

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

于 2013-10-30T04:21:28.253 回答