Android Firebase数据库带宽计算

我在两周前发布了一款名为MyPetrol的android应用程序，在三天内就在马来西亚访问了大约9万名用户。之后，由于Firebase数据库带宽消耗巨大（3天117GB），我关闭了该应用程序。我是一个自学成才的业余爱好者，没有IT相关背景，所以我真的为此感到困扰。希望有人能帮忙

该应用程序是一款针对汽油价格的众包应用程序。用户可以输入特定加油站的汽油价格，其他同意指定价格的用户可以“喜欢”该价格。一旦价格被更新，“like”计数被重置

打开应用程序后，它会查询附近加油站（最多20个加油站）的Google Places API Web服务。这样，它就可以将监听器与Firebase数据库中的电台数据挂钩。每个站点的数据结构如下所示

prices{
    ChIJpXJ4phI4zDERJqFTBzawpXk={
        placeID='ChIJpXJ4phI4zDERJqFTBzawpXk',
        company=500,
        lat=3.2095573,
        lng=101.7185698,
        name='Shell Malaysia (Iznora Enterprise)',
        firebaseID='xxx',
        userName='xxx',
        time=1491833181946,
        ron95=2.0,
        ron97=1.7,
        diesel=2.0,
        isValid=true
    }
}

为了跟踪喜欢的东西，有一部分数据

likes{
    ChIJpXJ4phI4zDERJqFTBzawpXk={
        firebaseID1=true,
        firebaseID2=true,
        firebaseID3=true
    }
}

我读到我们可以使用

（Firebase.getDefaultConfig（）.setLogLevel（Level.DEBUG））

进行流量检查，但是我没有看到任何关于logcat中上传和下载带宽的内容。只有这样的东西

04-10 22:39:19.250 3015-3192/? D/RepoOperation: onDataUpdate: /prices/ChIJpXJ4phI4zDERJqFTBzawpXk
04-10 22:39:19.250 3015-3192/? D/RepoOperation: onDataUpdate: /prices/ChIJpXJ4phI4zDERJqFTBzawpXk {time=1491833181946, firebaseID=xxx, valid=true, diesel=2, ron97=1.7000000476837158, ron95=2, placeID=ChIJpXJ4phI4zDERJqFTBzawpXk, name=Shell Malaysia (Iznora Enterprise), userName=xxx, company=500, lat=3.2095573, lng=101.7185698}
04-10 22:39:19.268 3015-3015/? D/EventRaiser: Raising /prices/ChIJpXJ4phI4zDERJqFTBzawpXk: VALUE: {time=1491833181946, firebaseID=xxx, valid=true, diesel=2, ron97=1.7000000476837158, ron95=2, placeID=ChIJpXJ4phI4zDERJqFTBzawpXk, name=Shell Malaysia (Iznora Enterprise), userName=xxx, company=500, lat=3.2095573, lng=101.7185698}
04-10 22:39:19.273 3015-3015/? D/EventRaiser: Raising /likes/ChIJpXJ4phI4zDERJqFTBzawpXk: VALUE: null

最后，我使用Android设备监视器检查每个操作的流量。以下仅为Firebase的平均结果。谷歌地图和其他http查询不包括在内

+----------------------------+-----------+-----------+-----------------------------------------+
|           Action           | Rx(bytes) | Tx(bytes) |                  Notes                  |
+----------------------------+-----------+-----------+-----------------------------------------+
| onPause                    |      2942 |      4680 | detach all listeners                    |
| onResume                   |     10143 |      5204 | reattach all listeners for 15 stations  |
| click "like" by self       |       620 |       535 | write action + download /likes/placeID  |
| update price by self       |      1642 |      1783 | write action + download /places/placeID |
| click "like" by other user |       382 |       112 | download /likes/placeID                 |
| update price by other user |       423 |       104 | download /places/placeID                |
+----------------------------+-----------+-----------+-----------------------------------------+

就在我关闭应用程序之前，数据库中有5.7MB的数据。我可以保证我直接将每个电台的侦听器连接为/prices/placeID，因此我没有检索整个“电台”数据，而是只检索该特定电台的数据。对于“like”也是如此。听众在暂停时也会分离

我没有任何可用的用户操作日志，因此很难追溯发生的事情。然而，每当用户打开应用程序时，必须查询Google Place API，因此我知道在这3天内，我有245k次查询。因此，对于每个用户会话

117GB / 245k session = ~480kB/session

这似乎很大。我在带宽等方面没有经验，所以我可能错了。即使我假设所有用户都做了下面极不可能的操作，我仍然无法填满带宽

+----------------------------+-----------+-------+--------------+----------------------------------------------------------+
|           Action           | Rx(bytes) | Times | Total(bytes) |                          Notes                           |
+----------------------------+-----------+-------+--------------+----------------------------------------------------------+
| onPause                    |      2942 |    10 |        29420 | Pause and resume 10 times, this does not update the map. |
| onResume                   |     10143 |    10 |       101430 |                                                          |
| click "like" by self       |       620 |    15 |         9300 | Click like on all 15 stations                            |
| update price by self       |      1642 |    15 |        24630 | Update price on all 15 stations                          |
| click "like" by other user |       382 |   100 |        38200 | 100 other users clicked per session                      |
| update price by other user |       423 |   100 |        42300 | 100 other users updated the price per session            |
| Total                      |           |       |       245280 |                                                          |
+----------------------------+-----------+-------+--------------+----------------------------------------------------------+

对于普通用户，我希望每个会话的最大带宽大约为50kB，因此Firebase似乎消耗了x10的带宽。所以我的问题是：

我是否正确计算了每个会话的带宽

使用Android设备监视器确定的流量是否正确？我错过什么了吗？有更好的检查方法吗

Firebase如何计算带宽？它也包括上传吗？有没有隐藏的带宽

抱歉发了这么长的邮件。如果有人能帮忙，我将不胜感激。

---

谢谢。

我找到了bug。它与上面的问题完全无关，但我在这里记录它是为了帮助其他用户。首先，回答我自己的问题

问题（1）-是的。每个会话480kB的估计值应该相当准确

问题（2）和（3）-Firebase消耗的带宽应该低于Android设备监视器记录的带宽。我联系了支持团队，得到了以下回复

对于带宽问题，下载的GB仅测量Firebase数据库发送到客户端应用程序的数据量。这意味着对应用程序进行数据检索。有关详细信息，请查看以下链接：

---

因此，扣除一些开销，实际带宽应该稍微低一些

那么，回到高带宽消耗。它与Firebase数据库的

查询
有关。当新用户注册时，我有一个疑问

Query priceQuery = getPricesRef().orderByChild("firebaseID").equalTo(myFirebaseID);

这是我噩梦的开始，因为我没有为那个数据库设置
.indexOn
。阅读Firebase官方文档。关于
查询的文档非常差。它只说明如果没有索引，性能将很差，但从未提及带宽：


基于上述陈述，我的假设是，如果没有
.indexOn
，对Firebase的查询可能需要更长的时间才能回复，因为Firebase server可能需要更长的时间来提供搜索结果。

但是，如中所述，首先从Firebase下载整个数据库，然后在客户端对其进行排序和查询我想这就是他们所说的实时客户端库可以执行特别查询而不指定索引

随着我的数据库的增长，每个注册的用户都开始通过下载整个
prices
数据库来消耗更高的带宽。到最后，仅注册一次就消耗了每个用户约800kB的内存因此请确保始终使用
.indexOn