azure-cognitive-search - 为我的 Azure 搜索服务创建高效的索引器

Question

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

“disableOrderByHighWaterMarkColumn”：真

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

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

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

标签： azure-cognitive-search

Answer 1

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

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

值得查看查询性能故障排除指南，并找出导致问题的 Azure SQL 数据库中到底发生了什么。假设您要使用更改跟踪支持，索引器对 SQL 数据库使用的默认查询如下所示： SELECT * FROM c WHERE hwm_column > @hwmvalue ORDER BY hwm_column 当 hwm_column 上没有索引或计算 hwm_column 时，我们经常看到性能问题。您可以在此处阅读有关高水位标记列问题的更多信息。

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

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

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

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