星期六

竟然从Firebase发来3万美元的账单

竟然从Firebase发来3万美元的账单

(转载)
实际上从Firebase发送了30,000美元的账单

  去年7月,群众筹款运动在哥伦比亚流行起来。 在最初的48小时内,一切都很好。 他们成功地保持了网站的正常运行,实现了超过200万的会话和超过2000万的页面浏览量。

  直到他们看到帐单。

  $ 30,356.56USD在72小时。

  他们在众筹活动中获得的任何收益将很快被运行该应用程序的成本所吞没。
  为什么错了?

  Firebase与传统的基于云的数据库之间最大的区别之一是定价模型。 亚马逊,数字海洋,谷歌云,Microsoft Azure和所有其他提供商使用基于实例的数据库的按小时付费模式。

  但是,Firebase会对数据库的每十万至25万次读取,写入和删除请求收费。 如果您可以将其保持在此范围内,则实际账单费用不应超过25美元。亚马逊的DynamoDB遵循类似的定价原则,只是它们从读取和写入请求中分配数据存储成本。

  相比之下,传统的云数据库受到每个层上可用的并发连接数的限制,与数据库的交互次数或数量实际上并不重要,因为它是按小时付费的。 关于每个服务及其提供程序的精美字体的任何警告。

  哥伦比亚的众筹活动通过阅读集合中的每个文档条目来计算每次用户查看特定视图时所收集的总价值和支持价值,这是一个错误。 这意味着,如果有100次捐赠,则应用程序将调用数据库一次,但是实际读取操作将等于两次读取且100次读取-一个是计算第二次支持者总数所需的值-A 总共200个读取请求。

  当此数字需要显示在多个页面上并因此需要多次计算时,情况会变得更糟。 当支持者的数量激增至数千时,页面浏览量攀升至200万以上,对数据库的读取请求变得非常容易,达到数十亿。

  这既不是Google帐单错误,也不是科技巨头试图抢钱。 在没有针对效率进行优化的数据结构中,就是人为错误。 即使这家哥伦比亚创业公司使用传统的云托管解决方案而不是Firebase解决方案,也将面临最大化数据库连接或类似连接的问题。 问题的根源是连接和传输的数据量,而不是服务本身。
  如何将东西保持在25美元以下

  使用Firebase时,我们倾向于只考虑服务的数据库方面。 但是,Google随该软件包提供了大量的云功能调用。 几乎可以说,他们鼓励我们使用它。

  每月有200万次呼叫或即用即付的定价模型,每百万次呼叫的价格为0.40美元,这使您想知道为什么它们会提供比与数据库的读/写/删除交互更多的信息。这么多电话。

  由于Firebase是无表结构,因此很容易启动聚合表来优化数据请求。 不仅返回结果更快,而且读/写/删除请求的数量也大大减少。

  但是,即使实际的基础结构具有处理该结构的能力,也不能有效地扩展上述结构。

  云功能充当微服务的廉价后端,从而减少了前端发生的进程。 在下图中,将付款单据插入到集合中之后,它会触发云功能,该功能会更新集合中的另一个单据以跟踪需要计算的数据。 结果,第一个触发器将导致三个操作-两个文档写入操作和一个读取操作。 尽管这听起来像是更多的读写操作,但是大多数应用程序读取繁重,因此需要对其进行优化。

  采用这种结构,这意味着在请求数据时,仅活动1需要输入数据,从而进行一次读取,而不是返回五个单独的结果。

  当此结构可以扩展到一百万个视图时,您只希望发出一百万次读取调用,而不会随着更多的支付而呈指数级爆炸。 如果您的应用程序是实时更新的,情况可能会变得更糟。
  重新思考编写应用程序的方式

  是否使用Firebase都没关系。 如今,托管应用程序的价格很便宜,但如果不加以控制,则数据库的成本通常很高。 数据是构成应用程序的元素,而连接,读取和写入请求是涉及应用程序不同部分之间的流量时最常发生的事情。

  前端可以快速启动,而后端可以使所有事情井井有条并受到检查。 传统架构在后端提供数据会话,但是无服务器架构通常没有此好处。

  但是,运行后端需要更多空间和处理能力,这可能会增加您的总体账单。 无服务器架构提供按需服务,最终可以降低成本。 考虑数据将如何继续存在将影响响应速度以及为您提供所需数据所需的读写总数。 之后所需的处理次数越少,整个应用程序的成本随时间推移的可伸缩性越好。

没有评论:

发表评论

 皆さんこんにちは、リュウタツと申します、中国から来ました、AIデザイン学科の一年生です。 私のテーマは「極東の地」です。 実に中国では日本といえば日中戦争を思い出すでしょう、日本に来る前は日本人ってまだ敵なのかな、仲良くできるかなっと思いました。ようやく、去年の4月にこの極東の...