我们已使用提供的脚本将所有旧的Firebase BigQuery事件表迁移到新的架构。我们注意到的一件事是，每日餐桌的大小急剧增加。
例如，在旧模式中，来自4/1/18的数据为3.5MM行和8.7 Gig。迁移后，同一日期的新表为32.3MM行和27 Gig。就行数而言，这几乎是其10倍，而其空间大小则是其3倍以上。
有人可以告诉我为什么新模式中的相同数据如此之大吗？
结果是，从新模式读取表而不是从旧模式读取表时，BigQuery查询成本要高得多。
答案 0 :(得分：2)
firebaser here
虽然增加导出数据的大小绝对不是目标，但这是新模式的预期副作用。
在旧的存储格式中，事件以束存储。虽然我不完全知道事件是如何捆绑的，但肯定是一堆事件，它们具有自己的具有共享属性的唯一和。这意味着您经常必须取消查询中的数据嵌套或将表与自身交叉连接，以获取原始数据，然后再次组合和分组以符合您的要求。
在新的存储格式中，每个事件都单独存储。这无疑增加了存储大小，因为现在捆绑软件中事件之间共享的属性对于每个事件都是重复的。但是，使用新格式编写的查询应该更易于阅读，并且可以更快地处理数据，因为它们不必首先取消嵌套。
因此，较大的存储容量应具有更快的处理速度。但是我完全可以想象，当您看到差异时，贴纸震撼，并意识到提高的速度并不总是能弥补这一点。对于这种情况，我深表歉意，并向您保证，从现在开始没有计划进行其他任何重大的架构更改。