何时一起使用Firebase Realtime DB和Firestore有意义? [英] When does it make sense to use Firebase realtime DB and Firestore together?

问题描述

在任何情况下都可以同时使用实时和Firestore吗?哪种情况更适合于Firebase实时与Firestore或两者结合?我一直在阅读有关人们遭受巨额费用打击的恐怖故事，无论如何都需要事先进行测试.

Is there any situation where it makes sense to use both realtime and firestore in conjunction? What situations lend themselves more favorably to firebase realtime vs firestore, or a combination? I keep reading about horror stories of people getting hit with huge costs is there anyway to test before hand.

就上下文而言，我希望与超过50,000种产品的基于拍卖的市场合作.这个想法是为了能够根据需要过滤那些产品，创建，修改和删除那些产品，喜欢的商品的出价，以及检索用户的出价.从我阅读的内容来看，使用firebase针对市场的一般建议(保持成本低廉)似乎建议将产品存储在实时数据库中，并将用户对象，销售等存储在firestore中.我需要的查询种类是出价最低/最高，最喜欢的商品，以及如何获取用户当前和购买的商品.

For context I am looking to work with an auction based market place of over 50,000 products. The idea is to be able to filter those products as needed, create, modify and delete bids for those products, favorite items and retrieve Users bids. From what I was reading the general suggestion (to keep cost low) for market places using firebase seems to suggest storing products in realtime db and the user objects, sales etc. in firestore. Kinds of queries I will need are find products with the lowest/highest bids, most favorited items, as well as fetching users current and purchases.

从成本的角度来看，何时将实时存储与火力存储最佳结合?

When would it be optimal to store in realtime vs firestore, from a cost perspective?

我当前的逻辑是实时存储产品对象，因为它们将被更频繁地引用.另外，我认为将用户信息，他们的出价和购买的信息存储在Firestore中的一个文档中是有意义的，因为这只会产生一次读取成本，而对于一个活跃的用户，可能会导致传输大量数据.令我感到困惑的是，诸如查看给定产品的先前销售与获得用户的先前销售之类的事情，应实时存储销售(作为他们自己的对象或嵌入在产品对象中)或存储(存储在用户文档中)还是两者都有?

My current logic is to store the product objects in realtime since they will be referenced more frequently. Alternatively I am thinking it makes sense to store the user info, their bids, and purchases in one document in a firestore as that would incur just one read cost, and for a highly active user could result in a large amount of data to be transferred. Where I am confused comes with things like viewing the previous sales of a given product vs getting a user's previous sales, should sales be stored in realtime (as their own object or embedded in the product object) or firestore (embedded in the User doc) or both?

推荐答案

看看您打算制作的应用程序，让我们简短地谈谈.

Looking at your app that you plan to make, let have a short talk regarding it.

一个出价应用程序，首先有人要出售他们的东西，然后将其发布到您的应用程序中.然后，您应用的每个用户都可能会看到它开始对其出价.现在，由于我不知道您的应用程序将如何运行，但我的假设是，您将把投标者的数据以及他们进行的投标存储在Firebase实时数据库中.

A bidding app, first someone wants to sell their stuff so they post it in your app. Then every single user of your app may see it start bidding on it. Now as I don't know how your app is going to work but here's my assumption you will store the data of bidders and the bids they make in firebase realtime database.

这将涉及许多读，写操作.现在，Firestore确实为您提供了20K operations/day，但是如果您超过限制，则只需花费$0.18/100K writes和$0.06/100K reads.现在，选择完全取决于应用程序的规模.如果您的应用具有大量受众，请使用实时数据库".您每月最多可以免费下载多达10GB的数据，超出此价格则每GB可以节省1美元.但这有一个问题，如果您坚持使用星火计划，则只能同时建立100个数据库连接，因此，如果用户数量众多，我会怀疑性能.使用Blaze计划，它最多可以达到200K，每个数据库也可以达到200K.因此，如果您创建另一个数据库，您将拥有更多.我个人建议根据区域或任何参数创建多个数据库以分散流量. [再次取决于有多少人使用您的应用]

This will involve lots of read, write operations. Now Firestore does offer you 20K operations/day, but if you cross the limit it will barely cost you $0.18/100K writes and $0.06/100K reads. Now the choice entirely depends on scale of your app. If your app has large number of audience, go for Realtime-Database. You can download upto 10GB of data per month for free and a dollar per GB beyond that. But this has a catch, if you stick to the spark plan, you can have only 100 simultaneous connections to the database so I doubt the performance if you have large number of users. It can go upto 200K using Blaze plan and that too per database. So if you create another database you will have more. I will personally suggest create multiple databases as per the region or any parameter to spread the traffic. [Again it's upto how many people use your app]

我认为，您应该使用Firebase Realtime数据库应用程序. [请确保您还使用了Firebase存储器来存储正在出售的物品的大照片].

In my opinion, you should use the Firebase Realtime database your app. [Make sure you utilize the firebase storage as well for storing large photos of the things on sale].

最后，当操作次数较少但大小较大时，请使用firestore.当您有许多小任务(例如更新最高出价值或当前正在竞标某件事的用户数量)时，请使用Firebase实时数据库，请使用Realtime DB. 我认为，请选择实时数据库.我也将它用于一些游戏内容，例如存储用户统计信息并随着用户的进度进行更新.这涉及许多读/写/更新/删除操作，因此我坚持使用实时数据库.

Lastly, use firestore when you have less number of operations but are larger in size. Use firebase realtime database when you have many small tasks like updating the highest bid value or number of users currently bidding for a particular thing, use Realtime DB. In my opinion, go for realtime database. I too use it for some game stuff like to store user stats and update it as the user progresses. This involves lots of read/write/update/delete operations so I stick with realtime-database.

何时将Firestore与实时数据库一起使用?

正如您提到的用户个人资料一样，我建议使用Firestore存储这些凭据.由于用户通常不会更新其个人资料，因此不会花费太多写操作.而且，投标者将对投标非常感兴趣，而不是关注其他个人资料.因此，即使有几个用户检查了其他人的个人资料.这不会花费您太多的阅读.但是，即使您的应用程序设计为竞标者必须一次检查卖方的个人资料，firestore仍将帮助您减少实时数据库[GB Downloaded]配额的使用. 每当有人从您的实时数据库中查询数据时，您就会消耗10 GB的免费下载限制的一部分.

As you have mentioned user profile, I will suggest use Firestore to store those credentials. Because user's won't generally update their profile so this won't cost much writes. Also the bidders would be much interest in bidding rather than watching others profiles. So even if if a few users check other's profile. This won't cost you much reads. But even if your app is designed in such a way that bidder must check seller's profile once, then firestore will definitely help you reduce usage of realtime database's [GB Downloaded] quota. Every time someone queries data from your realtime database, you consume some part of the 10 GB of free download limit.

正如我提到的同时连接到数据库一样，如果您在Firestore中托管用户个人资料数据，则firestore将负责个人资料访问，以便投标人从您的应用程序获得更快的响应.只需确保您利用了Firebase存储，Firestore和实时数据库中的所有免费配额，并确保您的应用程序的设计方式能够在所有服务之间平均分配流量.使用后端的云功能，并且不要在客户端使应用程序[.apk]过于繁琐，因为该应用程序需要大量的代码编写. 因此，结论是，使用Firestore存储不会频繁访问的数据，例如用户凭证以及他们所出售的任何东西.使用实时数据库存储出价数据.哦，是的，如果您还想存储一些统计信息，例如某人进行了多少次购买或某些信息更改得过于频繁，则将其存储在Firebase实时数据库中.您可以简单地创建一个子节点users/${username}并将常用的东西保留在实时数据库中.这不会花费您太多的存储空间，但会占用该下载限制.不应太昂贵，尤其是谈论您的应用程序将解决50000个产品XD时.

Also as I have mentioned the simultaneous connections to the database, if you host user profile data in Firestore then firestore will take care of profile visits so that bidders get faster response from your application. Just make sure you utilise all the free quotas from firebase storage, firestore and the realtime database and make sure your app is designed in such a way that it spreads traffic evenly between all services. Use the cloud functions on your back-end, and don't make your application [.apk] too heavy on client side as the app needs a lot to code. So the conclusion, use firestore to store data which won't be accessed frequently like the user credentials and whatever stuff they have on sell. Use realtime database to store bidding data. Oh and yes, if you also want to store some stats like how many purchases has someone made or some information that changes too frequently put that in firebase realtime database. You can simply create a child node users/${username} and keep the frequent stuff in realtime database. This won't cost you much storage but take of that download limit. Shouldn't be expensive much especially talking of your app is going to address 50000 products XD.

我希望与超过50,000种产品的拍卖市场合作.

I am looking to work with an auction based market place of over 50,000 products.

如果用户数量相对较少，那么实时数据库就足够了，但是谁知道您的应用程序用户何时可能会大量增加.因此，最好如上所述将数据分布在Firestore和实时数据库中.

If you have comparatively less number of users, realtime database is sufficient but who knows when there may be a huge rise in your app users. So it's better to spread the data in both Firestore and Real-time database as mentioned above.

请注意::这是我所面临的，然后在stackoverflow上进行搜索并找到此.即使您只是在Firestore中的数据"选项卡上滚动，Firestore也会对READS进行计数.因此，请确保您不只是在那冲浪.我写了2次，只是在查看数据的存储方式，我已经读取了27次...

Just a caution: This is what I faced, then searched over stackoverflow and found this. Firestore counts READS even if you are just scrolling over the data tab in firestore. So make sure you don't just get surfing over there. I made 2 writes and was just looking at how the data is being stored and I already got 27 reads ...

这篇关于何时一起使用Firebase Realtime DB和Firestore有意义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！