Firebase数据库带宽计算

Question

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

该应用程序是一个众包汽油价格的应用程序.用户可以在特定站点输入汽油价格,同意所述价格的其他用户可以"喜欢"它.更新价格后,重置"喜欢"计数.

打开应用程序后,它会向附近的加油站(最多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
    }
}

我在阅读Query时可以看到Firebase数据库带宽使用量,我们可以用它(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,因此我没有检索整个"站"数据,而只检索该特定站的数据.同样对于"喜欢".听众也在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的带宽.所以我的问题:

1. 我是否对每个会话的带宽进行了计算？
2. 使用Android设备监视器确定的流量是否正确？我错过了什么吗？有更好的检查方法吗？
3. Firebase如何计算带宽？它还包括上传吗？有隐藏的带宽吗？

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

Answer 1

所以,回到高带宽消耗.它与QueryFirebase数据库有关.当新用户注册时,我在下面有一个查询.

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

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

根据上述声明,我的假设是,如果没有.indexOn,对Firebase的查询可能需要更长时间才能回复,因为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

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