为我的 Azure 搜索服务创建高效的索引器

Question

我的数据源不能是单个表，因为我需要跨越 6 个表的数据。为此，我创建了一个在这些表上进行连接的视图。 当我使用这个视图作为数据源时，索引需要很多时间并且超时。我尝试将超时时间增加到 40 分钟，并提出了另一项更改建议：

“disableOrderByHighWaterMarkColumn”：真

它超时了。我还设置了批量大小：1000。这次它填充了索引，但在几个小时后失败，说“连接丢失”。并“感谢”禁用OrderByHighWaterMarkColumn，如果我再次重新运行索引器，它将再次处理所有行。

我的问题是解决这个问题的最佳方法是什么。

后续问题：由于我依赖于视图，因此我无法进行自动更改跟踪。我正在使用高水印列 (LastUpdatedTime) 来跟踪我的视图中的更改。我只想在我的索引中保留 6 个月的数据，所以我不确定在使用 View 时如何做到这一点。我的视图中已经有“where CreateDateTime > dateadd(month, -6, getdate())”子句，但这不会使 Indexer 从索引中删除“out-of-time-window”行（文档）。我怎样才能在这里实现我的目标？ 我是否应该编写一个处理器任务来定期使用 C# SDK 查询所有文档并根据日期删除文档？

Answer 1

很抱歉听到 Azure SQL 数据库索引器给您带来麻烦。我注意到您的问题中有几件事在 SQL 性能方面可能值得考虑：

我的数据源不能是单个表，因为我需要跨越 6 个表的数据。为此，我创建了一个在这些表上进行连接的视图。当我将此视图用作数据源时，索引需要很多时间并且会超时。

值得查看query performance troubleshooting guide 并找出导致问题的 Azure SQL 数据库中究竟发生了什么。假设您要使用更改跟踪支持，索引器对 SQL 数据库使用的默认查询如下所示： SELECT * FROM c WHERE hwm_column > @hwmvalue ORDER BY hwm_column 当 hwm_column 上没有索引或计算 hwm_column 时，我们经常在这里看到性能问题。你可以阅读更多关于issues with the high water mark column here的信息。

我尝试将超时时间增加到 40 分钟，并提出了另一项更改建议：“disableOrderByHighWaterMarkColumn”：true 它已超时。我还设置了批量大小：1000。这次它填充了索引，但在几个小时后失败，说“连接丢失”。并“感谢”禁用OrderByHighWaterMarkColumn，如果我再次重新运行索引器，它将再次处理所有行。

disableOrderByHighWaterMarkColumn 似乎不适用于您的场景，所以我同意您不应该设置它。减少批量大小似乎产生了积极的影响，我会考虑使用上面引用的故障排除指南来衡量性能提升

后续问题：由于我依赖于视图，因此我无法进行自动更改跟踪。我正在使用高水印列 (LastUpdatedTime) 来跟踪我的视图中的更改。我只想在我的索引中保留 6 个月的数据，所以我不确定在使用 View 时如何做到这一点。我的视图中已经有“where CreateDateTime > dateadd(month, -6, getdate())”子句，但这不会使 Indexer 从索引中删除“out-of-time-window”行（文档）。我怎样才能在这里实现我的目标？我是否应该编写一个处理器任务来定期使用 C# SDK 查询所有文档并根据日期删除文档？

我会考虑添加soft delete policy，而不是过滤掉超过 6 个月的数据。这里的挑战是索引器需要选择应该删除的行。完成此操作的最简单方法可能是更新您的应用程序逻辑以向您的视图添加一个新列，指示应删除该行。一旦此列的值发生更改，LastUpdatedTime 也应更新，以便在下一个索引器查询中显示。 你可以编写自己的处理器任务，但在 Azure 认知搜索中查询所有文档并对其进行分页可能会对搜索性能产生负面影响。我建议先尝试让它与您的索引器一起使用。