首页 > 解决方案 > Firebase BigQuery 导出架构大小差异

问题描述

我们已使用提供的脚本将所有旧 Firebase BigQuery 事件表迁移到新架构。我们注意到的一件事是每日餐桌的大小急剧增加。

例如,旧模式中 4/1/18 的数据是 3.5MM 行和 8.7 Gig。迁移后,同一日期的新表为 32.3MM 行和 27 Gig。这在行数方面几乎是 10 倍,在空间大小方面是 3 倍以上。

有人能告诉我为什么相同的数据在新模式中要大得多吗?

结果是,在从新架构读取表时,我们在 BigQuery 查询成本上比旧架构收取的费用要高得多。

标签: firebasegoogle-bigqueryfirebase-analytics

解决方案


火力基地在这里

虽然增加导出数据的大小绝对不是目标,但这是新模式的预期副作用。

在旧的存储格式中,事件被存储在包中。虽然我不完全知道事件是如何捆绑的,但它肯定总是一堆具有自己独特性共享属性的事件。这意味着您经常不得不取消嵌套查询中的数据或将表与它们本身交叉连接,以获取原始数据,然后再次将其组合和分组以满足您的要求。

在新的存储格式中,每个事件都是单独存储的。这肯定会增加存储大小,因为捆绑中的事件之间共享的属性现在为每个事件复制。但是您以新格式编写的查询应该更易于阅读并且可以更快地处理数据,因为它们不必先取消嵌套。

因此,更大的存储容量应该会带来稍快的处理速度。但我完全可以想象当你看到差异时贴纸的震惊,并意识到提高的速度并不总是弥补这一点。如果是这种情况,我深表歉意,并且已经得到保证,从这里开始不会计划任何其他大的架构更改。


推荐阅读