即使在200OK响应之后，Azure搜索索引上的mergeOrUpload操作也需要一些重建索引的时间吗？
我们已经配置了Azure索引器，它每隔1分钟在index和cosmosdb (源)之间同步数据。但我们也有使用nodeJS中间件直接将数据更新到索引中，并在执行更新后从索引中检索数据的场景。我们注意到一些问题，在对索引执行mergeOrUpload操作后，使用下面显示的数据，我们得到"200“OK响应，但在执行get请求时，azure搜索仍然返回旧的陈旧数据。
- 是否需要一些重新编制索引的时间？此问题不能使用postman重现，但会通过代码发生。我们通过代码使用rest API方法，并且不使用任何npm模块
- 是否有一个最佳实践或我们需要使用的任何特定API，然后API返回给我们更新的文档？
POST功能接口：{{url}}/indexes/orders-index/docs/index?api-version={{version}}
{
"value": [
{
"@search.action": "mergeOrUpload",
"productKey": "d1cef269-0059-4378-8284-df3f6a90b062",
"aomsOrderReleaseNbr": "7640156001",
"aomsOrderEntryDate": "2018-05-29T00:00:00Z",
"supplierNbr": "SWM",
"locationName": ""
}
]
}获取功能接口：{{url}}/indexes/orders-index/docs?api-version={{version}}&$count=true&search=lowerProductKey:/.*d1cef269\-0059\-4378\-8284\-df3f6a90b062.*/&queryType=full&$top=100&$skip=0
{
"@odata.context": "https://abcd/indexes('orders-index')/$metadata#docs",
"@odata.count": 1,
"value": [
{
"@search.score": 1,
"productKey": "d1cef269-0059-4378-8284-df3f6a90b062",
"aomsOrderReleaseNbr": "7640156001",
"aomsOrderEntryDate": "2018-05-29T00:00:00Z",
"supplierNbr": "SWM",
"locationName": ""
}
]
}回答 1
Stack Overflow用户
发布于 2018-06-08 04:06:34
Azure search使用分布式写入(基于仲裁)机制来确保持久存储到索引的数据可用。因此，索引中的数据最终将是一致的，但是如果在将文档插入索引(通过POST)之后立即查询索引，则新插入的文档可能不会立即显示出来。这是一个经过深思熟虑的优化查询性能的决定。
请注意，当索引器运行成功，或者insert index API返回200OK时，这并不意味着文档立即可用于搜索。 200确实意味着文档将持久存储在持久存储中。
文档在搜索结果中显示的延迟取决于许多因素，其中一些是
- 您的服务在
下的负载量
- 搜索服务副本的数量
已插入的文档的数量
关于这一点：
我们已经配置了Azure索引器，它每隔1分钟在索引和cosmosdb (源)之间同步数据。但我们也有使用nodeJS中间件直接将数据更新到索引中，并在执行更新后从索引中检索数据的场景
首先，你的azure搜索索引器的时间表不能少于5分钟，所以我很好奇它是如何每分钟都有的。无论如何，因为您有一个索引器和一个写入相同索引的自定义作业，如果它们碰巧“索引”相同的文档(基于文档键)-最后一个编写者胜出；这也可能导致显示可能陈旧的结果，这取决于两个文档中是否有其他内容差异。
关于最佳实践：
- 我们建议您的查询尽量不要依赖强一致性保证--也就是说，您的应用程序应该可以处理返回稍微陈旧数据的查询。
- 尝试在索引操作和查询操作之间加入一些延迟(正如我所说的，这是无法确定的，但需要试验一下)。
- 如果您能以某种方式确定查询返回的文档已过时，则还可以合并某种重试(它们之间有一个合理的休眠间隔)
https://stackoverflow.com/questions/50746146
复制相似问题