我正在评估firebase。 Feed是我计划的应用程序的核心部分。对于新用户帖子采用扇出策略，我试图在提交之前了解限制和成本。我想完全包围这个世界观，所以我可以清楚地向客户阐明考虑因素，所以我不会把它们建在一个角落里。 （讨厌地雷）
新用户帖子将通过HTTP调用云功能。帖子将写入数据库，另一个云函数将execute in response to onCreate/onWrite for that db path for fan-out。 （旁白：这可以做得更多efficient?）
让我们考虑成本，然后考虑限制。拥有1000名粉丝的用户的扇出成本：
云功能 pricing（网络出站，调用成本和免费等级被忽略）。资源：128MB，200MHz @ 0.000000231每100毫秒执行一次。 cost = ms * (cost/100) * invocations。完成3秒，有100万次调用：3000 * 0.00000000231 * 1000000 = 6美元。
实时数据库 pricing（忽略数据存储成本）
根据定价，目标应用程序的实际成本是数据离开数据库的任何地方，包括$1/Gb的云功能。这首先是令人困惑的，因为云功能报告说进入的数据是免费的，并建议您的唯一成本是数据移动到外部世界。我会从数据库中请求给定用户/followers/{userId}的关注者树，然后将帖子写入每个用户Feed /feed/{followerId}/{postId}:true。数据输出将花费树，+协议开销，并且数据成本将是免费的。我没有看到数据库计算时间的任何成本。文档规定协议开销约为5％，Cost = (outBound + outBound * .05) * invocations。 Data is not compressed.
为了估计获得所有1000个关注者，我将其键入为每个请求返回的每行数据的粗略近似值：{"v4NXj7AS1dUhl83V2XhZ5i9tzq42":true} = 35个字符/ 35个字节（UTF-8）。让我们称这50个字节是错误的。 50 * follower-count = outBound = 50 * 1000 = 50k。
Cost = (50k + 50k * 5%) * 1,000,000 = 52,500,000K = 52.5Gb = $53
因此，有1000名粉丝发布100万次的人的费用是$53 + $6 = $59好的 - 而且由于这种情况永远不会发生，我有一个上限，我很高兴。现在让我们谈谈限制。
云功能限制 limits关注无法增加的可能存在问题的限制，我只看到Max concurrent invocations for non-HTTP functions: The maximum concurrent invocations of a single function that is not triggered by HTTP is 1000.我认为这意味着像{{1}这样的数据库触发器会算的。这是否意味着如果每个函数如上所述执行onCreate，我的吞吐量将是（1000 / 3s），或者每秒约333次操作？刚刚感受到这里。很大程度上，我并不怀疑CF限制会成为一个问题。
实时数据库限制 limits我没有看到任何写入限制，除了3s我们的调用写入输出是树提取的两倍大小从上面看，因为完整路径与密钥一起写入。扇出时，这将是100k。 64MB /分钟/ .1MB = 640.所以基本上你只能有大约640个人和1000个朋友平均写一分钟。好的 - 这给了我每个数据库的规模感。
我认为这给了我一种非常合理的理解，即我可以期待的规模，成本，前期和维持的投资。
最后，如果实时数据库在任何方面给我们带来任何悲伤，可以转移到https://cloud.google.com/datastore/作为干净的后备。针对突发事件的干净退出计划，无需进行广泛的更改。高兴。
这个估计是否明智？你觉得怎么样？
其他未解决的问题：