Question

我在2周前发布了一款名为MyPetrol的Android应用程序，并在三天内在马来西亚大约有9万用户。之后，由于Firebase数据库带宽消耗量巨大（3天内为117GB），我删除了应用程序。我是一个自学成才的爱好者，不是来自IT相关背景，所以我真的很担心。希望有人可以提供帮助。

该应用程序是一个众包汽油价格的应用程序。用户可以在特定车站输入汽油价格，其他同意所述价格的用户可以＆＃34;喜欢＆＃34;它。一旦价格更新，＆＃34;喜欢＆＃34;计数重置。

打开应用程序后，它会向附近的加油站（最多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 database bandwidth usage when read with Query我们可以使用(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 Device Monitor检查每个操作的流量。以下是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，所以我没有找回整个＆＃34; Station＆＃34;数据，但只有该特定站的数据。同样的＆＃34;喜欢＆＃34;。听众也在onPause上分离。

我没有任何可用的用户操作日志，因此我很难追溯发生的事情。但是，每当用户打开应用程序时，都必须查询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如何计算带宽？它还包括上传吗？有没有隐藏的带宽？

对不起，很长的帖子。感谢有人可以提供帮助。谢谢。

Answer 1

所以，回到高带宽消耗。它与Firebase数据库的Query有关。当新用户注册时，我在下面有一个查询。

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

这是我噩梦的开始，因为我没有为该数据库设置.indexOn。阅读官方Firebase文档here。有关Query的文档很差。它只表明在没有索引的情况下性能会很差，但从未提及带宽：

根据上述声明，我的假设是没有.indexOn，对Firebase的查询可能需要更长时间才能回复，因为Firebase服务器可能需要更长时间才能提供搜索结果。 < / p>

但是，正如Firebase database bandwidth usage when read with Query中所解释的那样，首先从Firebase下载整个数据库，然后在客户端进行排序和查询！我想这就是实时客户端的含义库可以执行即席查询而无需指定索引。

随着我的数据库的增长，每个用户注册通过下载整个prices数据库开始消耗更高的带宽。最后，仅仅注册就消耗了大约800kB的用户。 因此请务必始终使用.indexOn！

Answer 2

我发现了这个错误。这与上述问题完全无关，但我在这里记录它是为了帮助其他用户。首先，回答我自己的问题。

问题（1） - 是的。估计每次480kB应该非常准确。

问题（2）和（3） - Firebase消耗的带宽应低于Android Device Monitor记录的带宽。我联系了支持团队并得到了以下答复。

对于带宽问题，下载的GB仅测量Firebase数据库发送到客户端应用的数据量。这意味着要对您的应用程序进行数据检索。您可能需要查看以下链接以获取更多信息：


https://groups.google.com/forum/#!topic/firebase-talk/T1sADDJYuIc

https://groups.google.com/forum/#!topic/firebase-talk/cM9N476RDfE

因此，扣除一些开销，实际带宽应略低。

Firebase数据库带宽计算

2 个答案: