Netflix工程师使用Elasticsearch Percolate Queries实现反向搜索

Netflix的工程师Ricky Gardiner、Alex Hutter和Katie Lefevre最近发表了一篇文章，介绍了他们如何利用Elasticsearch的Percolate Queries在连接图中实现“反向搜索”实体。反向搜索的含义是，不是搜索与查询匹配的文档，而是搜索与文档匹配的查询，从而支持动态订阅和通知场景，其中订阅者和订阅实体之间没有直接关联。

核心场景

一个核心场景是，员工希望基于动态条件（例如“在墨西哥城拍摄且未分配关键角色的电影”）接收与电影子集相关的各种事件的更新通知。这意味着员工不是订阅特定电影的更新，而是订阅返回动态电影子集的查询。这带来了一个问题：当电影发生变化时，由于员工与他们感兴趣的电影之间没有直接关联，系统无法确定应该通知谁。

初步解决方案及其问题

一个简单的解决方案是为所有变更事件重复执行所有已保存的搜索查询，从而确定相关的订阅者。然而，由于从Netflix联邦图获取数据会带来巨大的流量影响，这种解决方案迫使团队在及时通知和减轻图负载之间做出选择。

使用Percolate Queries的解决方案

Netflix的工程师选择了使用Elasticsearch的Percolate Queries来实现这一功能。Percolate Query是一种专门的查询机制，允许用户索引查询本身，然后将这些查询与传入的文档进行匹配。

实现细节

为了让用户使用这一功能，Netflix团队在Domain Graph Service（DGS）中添加了一个新的ReverseSearch服务。通过这个服务，他们暴露了一个新的SavedSearch实体，该实体的过滤器使用Graph Search DSL编写，并转换为Elasticsearch查询，索引在percolator字段中。当发生变更事件时，系统使用percolate query评估索引，并从匹配变更文档的已保存查询中确定相关的订阅者。

版本控制挑战与解决方案

Netflix在扩展Graph Search功能时，遇到了索引系统版本控制的重大挑战。特别是当引入新字段时，需要更新现有搜索索引以包含这些新字段。现有的索引没有这些新字段的映射，使得在不创建新索引版本的情况下无法过滤它们。

Netflix通过实现双管道索引系统解决了这个问题，其中每个索引版本都有自己的专用管道。当更改需要新的索引映射时，Netflix会创建一个新的Elasticsearch索引版本，与现有版本并行运行。他们利用Data Mesh平台的日志压缩主题来填充新管道，允许重新索引整个语料库，而无需数据源重新发送所有过去的事件。

这种新旧管道的并行操作确保了服务的连续性，同时填充新索引。一旦处理完积压任务并且最新索引准备就绪，Netflix使用Elasticsearch索引别名切换到新版本，从而简化了过渡并最小化了搜索功能的中断。