android – Firebase数据库带宽计算

概述我在2周前发布了一款名为MyPetrol的 Android应用程序,并在三天内在马来西亚大约有9万用户.之后,由于Firebase数据库带宽消耗量巨大(3天内为117GB),我删除了应用程序.我是一个自学成才的爱好者,不是来自IT相关背景,所以我真的很烦恼.希望有人可以提供帮助. 该应用程序是一个众包汽油价格的应用程序.用户可以在特定站点输入汽油价格,同意所述价格的其他用户可以“喜欢”它.更新价格 我在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    }}

我读了我们可以使用的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/ChIJpXJ4phI4zDERJqFTBzawpXk04-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,lng=101.7185698}04-10 22:39:19.268 3015-3015/? D/EventRaiser: Raising /prices/ChIJpXJ4phI4zDERJqFTBzawpXk: VALUE: {time=1491833181946,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的带宽.所以我的问题：

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

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

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

query pricequery = getPricesRef().orderByChild("firebaseID").equalTo(myFirebaseID);

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

基于上述声明,我的假设是,如果没有.indexOn,对Firebase的查询可能需要更长时间才能回复,因为Firebase服务器可能需要更长时间才能提供搜索结果.

但是,正如Firebase database bandwidth usage when read with Query所述,整个数据库首先从Firebase下载,然后在客户端进行排序和查询！我想这就是实时客户端库可以在不指定索引的情况下执行即席查询的含义.

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

总结

以上是内存溢出为你收集整理的android – Firebase数据库带宽计算全部内容，希望文章能够帮你解决android – Firebase数据库带宽计算所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。