Firebase BigQuery 导出架构大小差异

Posted 2023-03-24

【中文标题】Firebase BigQuery 导出架构大小差异

【英文标题】：Firebase BigQuery Export Schema Size Difference

【发布时间】：2018-08-07 00:26:19

【问题描述】：

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

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

谁能告诉我为什么相同的数据在新架构中要大得多？

结果是，与旧架构相比，从新架构读取表时，我们在 BigQuery 查询方面的费用要高得多。

【问题讨论】：

好问号。我能想到的唯一想法是新格式更加规范化，我们将在事件之间复制属性。我四处打听，看看这里有没有人知道。

【参考方案1】：

firebaser 在这里

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

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

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

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

【讨论】：

总体而言，您的存储成本不会是主要因素（在您的示例中，您的存储成本可能从每月免费到 34 美分）。大多数 BQ 成本来自查询本身，假设您在之前的模式中取消嵌套事件以查询事件，这两种模式在定价方面应该看起来相当可比。

感谢托德澄清！