Firebase和索引/搜索 [英] Firebase and indexing/search

问题描述

我正在考虑使用Firebase作为应用程序，让人们使用全文搜索来搜集几千个对象。我喜欢提供客户端应用程序（不必担心托管数据）的想法，但我不知道如何处理搜索。数据将是静态的，所以索引本身不是什么大问题。

我假设我需要一些额外的服务来运行查询并返回Firebase对象句柄。我可以在某个固定位置启动这样的服务，但是我不得不担心其可用性和可扩展性。虽然我不希望这个应用程序有太多的流量，但它可以在几千个并发用户达到峰值。

建筑思想？

长期来看，Firebase将会有更高级的查询，所以希望它能够直接支持这类事情，而不需要做任何特殊的事情。在此之前，您有几个选择：

1. 编写处理搜索的服务器代码。最简单的方法是运行一些负责索引/搜索的服务器代码，正如你所提到的那样。 Firebase有一个Node.JS客户端，所以这将是一个简单的方法将服务连接到Firebase。所有的数据传输仍然可以通过Firebase进行，但是您可以编写一个Node.JS服务，在Firebase的某个指定位置监视客户端搜索请求，然后通过将结果集写回Firebase进行响应客户端消费。


2. 将索引存储在Firebase中，客户端自动更新索引。如果您希望变得非常聪明，可以尝试实施无服务器方案客户在写入数据时会自动对数据进行索引...因此，全文搜索的索引将存储在Firebase中，当客户端向集合中写入新项目时，它也将负责更新索引。而要进行搜索，客户端将直接使用索引来构建结果集。对于想要索引存储在Firebase中的复杂对象的一个​​字段的简单情况，这对于全文搜索来说实际上是非常有意义的，这可能相当粗糙。 ：）


3. 将索引存储在Firebase中，服务器代码将其更新。您可以尝试一种混合方法，将索引存储在Firebase中，客户端进行搜索，而不是让客户端更新索引，只要将新项目添加到集合中，您就可以拥有更新索引的服务器代码。这样，当服务器关闭时，客户端仍然可以搜索数据。在您的服务器赶上索引之前，它们可能会过时。

在Firebase进行更高级的查询之前，＃1可能是您的如果你愿意运行一个小小的服务器代码，最好的选择。 ： - ）

I am considering using Firebase for an application that should people to use full-text search over a collection of a few thousand objects. I like the idea of delivering a client-only application (not having to worry about hosting the data), but I am not sure how to handle search. The data will be static, so the indexing itself is not a big deal.

I assume I will need some additional service that runs queries and returns Firebase object handles. I can spin up such a service at some fixed location, but then I have to worry about its availability ad scalability. Although I don't expect too much traffic for this app, it can peak at a couple of thousand concurrent users.

Architectural thoughts?

解决方案

Long-term, Firebase will have more advanced querying, so hopefully it'll support this sort of thing directly without you having to do anything special. Until then, you have a few options:

1. Write server code to handle the searching. The easiest way would be to run some server code responsible for the indexing/searching, as you mentioned. Firebase has a Node.JS client, so that would be an easy way to interface the service into Firebase. All of the data transfer could still happen through Firebase, but you would write a Node.JS service that watches for client "search requests" at some designated location in Firebase and then "responds" by writing the result set back into Firebase, for the client to consume.
2. Store the index in Firebase with clients automatically updating it. If you want to get really clever, you could try implementing a server-less scheme where clients automatically index their data as they write it... So the index for the full-text search would be stored in Firebase, and when a client writes a new item to the collection, it would be responsible for also updating the index appropriately. And to do a search, the client would directly consume the index to build the result set. This actually makes a lot of sense for simple cases where you want to index one field of a complex object stored in Firebase, but for full-text-search, this would probably be pretty gnarly. :-)
3. Store the index in Firebase with server code updating it. You could try a hybrid approach where the index is stored in Firebase and is used directly by clients to do searches, but rather than have clients update the index, you'd have server code that updates the index whenever new items are added to the collection. This way, clients could still search data when your server is down. They just might get stale results until your server catches up on the indexing.

Until Firebase has more advanced querying, #1 is probably your best bet if you're willing to run a little server code. :-)

这篇关于Firebase和索引/搜索的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！