简体繁体 English

Firebase 和笛卡尔公共读取

[英]Firebase and cartesian public reads

原文 2022-12-16 14:43:53 4 1 firebase/ google-cloud-firestore

I'm working on a product that displays the results of running races.我正在开发一种显示跑步比赛结果的产品。 Races could have thousands of participants.比赛可能有成千上万的参与者。 So, in the days after a medium-sized event, there might be 3000 non-authenticated users wanting to browse 3000 results.因此，在中型活动之后的几天内，可能有 3000 个未经身份验证的用户想要浏览 3000 个结果。

Although not every visitor will view all the results, the maximum damage at 3000 * 3000 would be 9,000,000 reads which at $.06 (Google cloud pricing) would cost $540,000 (Update: I'm a dummy, I missed the "per 100,000 documents" part, so this would only be $540).虽然不是每个访问者都会查看所有结果，但 3000 * 3000 的最大损坏将是 9,000,000 次读取，按 0.06 美元（谷歌云定价）将花费 540,000 美元（更新：我是个傻瓜，我错过了“每 100,000 个文档” " 部分，所以这只会是 540 美元）。

Obviously, I wouldn't deliver all 3000 results for each visit - there would be paging and limits.显然，我不会为每次访问提供所有 3000 个结果 - 会有分页和限制。 Though, there's something inherently scary about the possibility of those costs.不过，这些成本的可能性本身就有些可怕。

Questions:问题：

Is firebase simply the wrong technology for this type of product?对于这类产品，Firebase 只是错误的技术吗？
Is firebase not really intended for non-authenticated apps? firebase 不是真的适用于未经身份验证的应用程序吗？ Obviously DDOS becomes a concern for public access and there's no real protection in FB for this.显然，DDOS 成为公众访问的一个问题，FB 对此没有真正的保护。

Every post I've read on these topics assumes developers are building apps for authenticated users.我读过的每一篇关于这些主题的文章都假定开发人员正在为经过身份验证的用户构建应用程序。

1 个解决方案

9,000,000 reads which at $.06 (Google cloud pricing) would cost $540,000 9,000,000 次读取，0.06 美元（谷歌云定价）将花费 540,000 美元

The Firestore pricing of $0.06 is for 100,000 document reads, so 9 million document reads cost $540. 0.06 美元的Firestore 定价适用于 100,000 次文档读取，因此 900 万次文档读取的成本为 540 美元。

Aside from that: you should model your data in a way that ensures you read the data that the user actually sees.除此之外：您应该以确保您读取用户实际看到的数据的方式对数据进行建模。 For example, if all users will read the entirety of all 3,000 documents, consider using a data bundle to distribute that to them.例如，如果所有用户都将阅读全部 3,000 个文档，请考虑使用数据包将其分发给他们。

Realistically though it is more likely that each user will read just a subset of the documents, and probably not of all 3,000 documents.实际上，每个用户更有可能只阅读文档的一个子集，而不是全部 3,000 个文档。 So consider if you can combine the part that they'll read into a more cost-efficient structure.因此，请考虑是否可以将他们将阅读的部分组合成更具成本效益的结构。 For if these were news articles: you could store the headline and intro paragraph of the first 100 articles in a single document, and just read that document (let's call it the frontpage ) into each client when it starts.如果这些是新闻文章：您可以将前 100 篇文章的标题和介绍段落存储在一个文档中，然后在每个客户端启动时将该文档（我们称之为frontpage ）读入。

There are many more ways to model the data, depending on the use-cases of your app.根据您的应用程序的用例，还有更多方法可以对数据进行建模。 To learn more on how to think about such data modeling, I recommend reading NoSQL data modeling and watching the excellent Get to know Cloud Firestore video series.要了解有关如何考虑此类数据建模的更多信息，我建议阅读NoSQL 数据建模并观看优秀的了解 Cloud Firestore视频系列。