1

假设上游数据源是具有插入、更新和删除功能的事务性 SQL Server 表，那么了解 Elastic Search 索引何时需要更新的最佳方法是什么？

示例：表父、子、孙子。

Parent      |  Child                | Grandchild
ID   Name   |  ID  ParentID  Name   | ID  ChildID Amount
1    Foo    |  10   1         Bike  | 100 10      5
2    Bar    |  20   1         Car   | 200 20      2
3    Baz    |  30   3         Tran  | 300 30      1

孙子被更新，并且父项上的弹性搜索索引需要更新关联记录。

因此，在孙子更新时，我需要找到该孙子的 Parent.ID。这意味着加入 Child 并获取 ParentID 值。

同时，我们正在启动一个增量、迭代加载的数据仓库计划，因此理想情况下，我希望对两者使用相同的 SQL Server API/技术。

基于如何通知 Windows 服务（c#）数据库表更改（sql 2005）？通过 Remus Rusanu，不应使用查询通知 API，因为它的唯一用途是缓存失效，而不是更改跟踪......

这似乎留下了两个选项 - SQL Server Change Data Capture 和 SQL Server Change Tracking API。

我们考虑在应用程序级别进行所有更改跟踪，但我们主要担心的是带外更新，因为由于新的政府法规，一些数据需要在夜间以不可预见的方式更新，所以我们真的需要一个在表级别捕获更改并将其冒泡到队列中以提供 Elastic Search 的方法。

谢谢！

4

2 回答 2

2

这个人在有趣的解决方案中使用触发器、内置的 ServiceBroker 来排队更改和 C# 服务来读取该队列并将更改推送到弹性搜索： https ://medium.com/@mindingdata/elasticsearch-realtime-rivers-与-mssql-server-e1540a9bf1d3#.72k9buet5

该架构类似于 CDC，但使用服务代理来存储更改而不是 CDC 表

于 2015-12-14T21:53:02.140 回答
2

相应的 API 是变更跟踪或变更数据捕获。哪一个取决于数据更改的频率/数量以及原始数据和搜索索引之间可以承受的延迟有多大。对于低延迟和频繁更改，CDC 更适合恕我直言，因为它可以以最低的成本为您提供“增量”。对于缓慢变化的数据和不频繁的弹性搜索索引刷新，我可能更喜欢 CT，因为它更轻量级，尽管找出“增量”更复杂（我说可能是因为总的来说，我发现 CDC 比 CT 更适合长期解决方案，随着需求的发展，CDC 最终变得更合适）。

跟踪更改的常见问题是找出被删除的内容。内部解决方案，基于触发器或在应用程序层中实现，始终存在该部分的问题。并非不可能，但您最终将自己重新实现 CT/CDC，而无需访问 CDC 所利用的 SQL 日志解析和额外更新日志的内部结构......

于 2015-12-02T09:33:12.073 回答