通过缩短字段名称来节省Firebase带宽？ [英] Saving firebase bandwidth by shortening field names?

问题描述

使用Firebase我给这些字段提供了易读的名称，比如timestamp，last_changed，message_direction等。

是字段为每一个行命名数据交换的一部分？

这意味着，我是否可以通过缩短字段名称来节省带宽？

解决方案

<正如Frank指出的那样：是的，它们确实会影响带宽。但是，如果你做数学计算，你会发现带宽很少值得你付出努力和模糊处理，而且通常你的数据有效载荷将会极大地掩盖这些密钥的一些额外的字符。

让我们考虑一个平均聊天消息：

  {
sender：typicaluserid：12345678901234567890， 
timestamp：1410193850266，
message：Hello world。你所有的基地都属于我们！ 
 
 $ / code> 

好的，首先我们来看看这个消息的有效载荷。这是163字节，UTF-8编码。如果我将密钥更改为无意义的三个字符id（例如sdr，ts和msg），那么它将是149个字节。用一些宽松的填充来处理事务开销，比如说大概有40个字节，大概节省了2％，换来需要读取数据。接下来，我们来考虑一下带宽使用情况。如果我们有一个非常活跃的，非常庞大的聊天系统（即我们正在严肃的$$），我们可能有10K个活跃用户每天平均发送50个消息。这意味着我们每天会发送 200字节* 500k = 100MB 数据，或者每个数据大约 3GB 。
$ b

这意味着我可以在Firebase的免费计划中轻松支持大量的聊天系统，而不会超过带宽限制。

<如果我们把这11个字节关闭，我们有 189 * 500k * 30 = 2.8GB 。所以这个努力没有太大的区别。

Using Firebase I'm giving the fields easily human-readable names, such as "timestamp", "last_changed", "message_direction" etc.

Are the field names part of the data exchange for every single "row"?

Meaning, would I save bandwidth by shortening the field names?

解决方案

As Frank pointed out: Yes, they do affect bandwidth. However, if you do the math, you'll see that bandwidth is rarely worth the effort and obfuscation, and that generally your data payload will vastly eclipse the few extra characters of the keys.

Let's consider an average chat message:

{
  "sender": "typicaluserid:12345678901234567890",
  "timestamp": 1410193850266,
  "message": "Hello world. All your base are belong to us!"
}

Okay, so first let's look at the payload for this message. This is 163 bytes, UTF-8 encoded. if I changed the keys to meaningless three character ids (e.g. sdr, ts, and msg), then it would be 149 bytes. With some liberal padding for transaction overhead, let's say about 40 bytes, it's about a 2% savings, in exchange for needing a rosetta stone to read my data.

Next, let's consider bandwidth usage. If we have a very active, very massive chat system (i.e. we're raking in serious $$), we might have 10k active users sending an average of 50 messages per day. That means we'd be sending 200 bytes * 500k = 100MB of data per day, or around 3GB of data per month.

That means that I could support a massive chat system comfortably on Firebase's free plan without exceeding bandwidth limits.

If we take those 11 bytes, off, we have 189 * 500k * 30 = 2.8GB. So not a significant difference for the effort.

这篇关于通过缩短字段名称来节省Firebase带宽？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！