在不耗尽免费配额的情况下有效地搜索/exist() Firestore

Question

我正在做一个业余项目，想让我的用户检查他们的朋友是否有帐户。

目前我是这样实现的：

1. 为电子邮件读取电话联系人
2. 循环浏览电子邮件
   1. 对用户数据库进行.get() 查询¹为使用该电子邮件的用户
   2. 如果返回数据，则表明好友在平台上并显示邀请按钮
3. 一小时内超出免费配额²

问题是任何.get 都被视为读取操作，即使没有数据返回。他们的doc.exists 只能在.get 之后进行tun，因此需要读取文档以检查是否存在。

我确定我忽略了一些明显的事情，我想要做的本质上是一个类似 .exist() 的查询，它不会“花费”一次阅读。

---

1：我实际上并没有将电子邮件存储在 Firestore 中，而是存储它们的哈希值，并且正在查询它们。效果相同，但它允许我查询不公开真实电子邮件和其他数据的辅助用户数据库。

2：不要试图让自己变得便宜，但如果这个应用变成商业应用，这将使计费成为一场噩梦。

Answer 1

根据您的评论，您说您将联系人保存在内存中，对于每个联系人（电子邮件地址），您在现有的 Firestore 数据库中搜索匹配项。

一小时内超出免费配额

这意味着您正在 Firestore 数据库中搜索大量联系人。

问题是任何 .get 都被视为读取操作，即使没有数据返回。

没错。根据Firestore pricing的官方文档，它明确指出：

查询最低收费

对于您执行的每个查询，即使查询未返回任何结果，读取一个文档的最低费用也是如此。

因此，例如，如果您有 1000 个联系人，并且您为每个联系人查询数据库，即使您的查询没有返回任何结果，您仍然需要为 1000 次读取操作付费。

我确定我忽略了一些显而易见的事情，我想要做的本质上是一个类似 .exist() 的查询，它不会“花费”阅读。

Firestore 不是这样工作的。这意味着无论结果如何，每个查询都会产生至少一个文档读取的成本。

1：我实际上并没有将电子邮件存储在 Firestore 中，而是存储它们的哈希值，并且正在查询它们。效果相同，但它允许我查询不公开真实电子邮件和其他数据的辅助用户数据库。

正如您已经注意到的，无论您存储实际的电子邮件地址还是相应的哈希值，结果都是一样的。

2：不要试图让自己变得便宜，但如果这个应用变成商业应用，这将使计费成为一场噩梦。

试试这个功能，Firebase realtime database，相信我，它们在同一个项目中可以很好地协同工作。