我正在考虑将Firebase用于应该使人们对数千个对象的集合进行全文搜索的应用程序。我喜欢交付仅客户端应用程序的想法(不必担心托管数据),但是我不确定如何处理搜索。数据将是静态的,因此索引本身并不重要。
我假设我将需要一些额外的服务来运行查询并返回Firebase对象句柄。我可以在某个固定位置启动此类服务,但随后我不得不担心其可用性和可伸缩性。尽管我预计该应用不会带来太多流量,但它可能会达到数千个并发用户的峰值。
建筑思想?
最佳答案
从长远来看,Firebase可能具有更高级的查询,因此希望它可以直接支持这种事情,而您无需执行任何特殊操作。在此之前,您有几种选择:
编写服务器代码以处理搜索。如您所提到的,最简单的方法是运行一些负责索引/搜索的服务器代码。 Firebase具有Node.JS客户端,因此这是将服务连接到Firebase的简便方法。所有数据传输仍然可以通过Firebase进行,但是您将编写一个Node.JS服务,该服务在Firebase中的某个指定位置监视客户端“搜索请求”,然后通过将结果集写回Firebase来“响应”。客户消费。
将索引存储在Firebase中,客户端会自动对其进行更新。如果您想变得真正聪明,则可以尝试实施一种无服务器方案,在该方案中,客户端在写入数据时会自动为其索引。因此,全文搜索的索引将存储在Firebase中,并且在客户端写入时集合中的一个新项目,它将负责适当地更新索引。为了进行搜索,客户端将直接使用索引来构建结果集。对于要为Firebase中存储的复杂对象的一个字段建立索引的简单情况,这实际上很有意义,但是对于全文搜索而言,这可能会很粗糙。 :-)
将索引存储在Firebase中,并使用服务器代码对其进行更新。您可以尝试一种混合方法,将索引存储在Firebase中,并由客户端直接用于搜索,但是要让客户端更新索引,而不是让客户端将索引添加到集合中时就更新索引的服务器代码。这样,当服务器关闭时,客户端仍然可以搜索数据。在服务器追上索引之前,它们可能会获得过时的结果。
在Firebase进行更高级的查询之前,如果您愿意运行一些服务器代码,那么#1可能是最好的选择。 :-)