假设上游数据源是具有插入，更新和删除的事务性SQL Server表，那么知道弹性搜索索引何时需要更新的最佳方法是什么？
实施例： 表父，子，孙。
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
更新孙子，并且需要为关联记录更新父级的弹性搜索索引。
所以，在更新了Grandchild之后，我需要找到该孙子的Parent.ID。这意味着加入Child并获取ParentID值。
与此同时，我们正在启动一个增量的，迭代加载的数据仓库计划，所以理想情况下我想对两者使用相同的SQL Server API /技术。
根据Remus Rusanu在How to notify a windows service(c#) of a DB Table Change(sql 2005)?中的评论，不应使用查询通知API，因为它唯一的用途是缓存失效，而不是更改跟踪......
这似乎留下了两个选项 - SQL Server Change Data Capture和SQL Server Change Tracking API。
我们考虑过在应用程序级别进行所有更改跟踪，但我们主要关注的是带外更新，因为由于新的政府法规，某些数据需要以不可预见的方式在一夜之间更新，因此我们确实需要一种方法来捕获表级别的更改并将其冒泡到队列中以提供弹性搜索。
谢谢！
答案 0 :(得分：2)
适用于此的API是更改跟踪或更改数据捕获。哪一个取决于数据更改的频率/数量以及原始数据和搜索索引之间可以承受的延迟。对于低延迟和频繁更改CDC是更好的imho，因为它可以给你一个'delta＆＃39;以最低的成本。对于缓慢变化的数据和不常见的弹性搜索索引刷新，我可能更喜欢CT，因为它更轻巧，虽然找出了delta＆＃39;更复杂（我说也许因为总的来说我发现CDC比CT长期解决方案更适合，因为需求的发展使CDC最终更适合）。
跟踪更改的常见问题是找出已删除的内容。内部解决方案，基于触发器或在应用层中实现，始终存在该部分的问题。这不是不可能做到的，但是你最终会自己重新实现CT / CDC，而无需访问CDC利用的SQL日志解析和额外更新日志的内部......
答案 1 :(得分：0)
这个人在使用触发器的有趣解决方案中，内置ServiceBroker对更改进行排队，使用C＃服务读取该队列并将更改推送到弹性搜索： https://medium.com/@mindingdata/elasticsearch-realtime-rivers-with-mssql-server-e1540a9bf1d3#.72k9buet5
该体系结构类似于CDC，但使用服务代理来存储更改而不是CDC表