This question already has answers here:
Firestore slow queries with large collections unless offline persistence disabled
(2 answers)
Closed 2 years ago.
I have a very simple query which is quite slow (5seconds or more) when running it on my android.
QuerySnapshot snapshot = await userTeamPointsCollection
.where('user_ref', isEqualTo: userIdRef)
.where('season_id', isEqualTo: season)
.where('match_day', isEqualTo: matchday)
.get();
The collection consists of 10 documents, so i have no idea why the query might be slow.
I have already created a composite index, there was not much improvement.
DO you have any suggestions on what i should try or why it is so slow? (Internet is not an issue...)
Best regards,
If you are aiming for fast synchronization of (frequent) relatively small write operations, consider using Firebase's Realtime Database over Cloud Firestore.
Firebase has two NoSQL databases: Cloud Firestore and the Realtime Database. Both database's offer real-time synchronization as one of their core primitives, but Realtime Database is often faster and handles small write operations more efficiently (and often cheaper), while Firestore is best if you have relatively big documents, a larger number of (50K-1M concurrent) listeners, and relatively fewer write operations.
For more info please refer to this link
Related
This question already has answers here:
Couple Firebase Firestore and Firebase Storage calls together into a batch?
(2 answers)
Closed last month.
I'm developing an app in Flutter, I have a method called **CreateUser **which takes as parameters the user information, his profile picture, and a list of strings, I need to save the information in the Realtime Database, the picture in the Cloud Storage and the list in the Firestore.
I would like all these operations to be successful, if one of these should fail then I would like the others to undo the data they wrote. How can I implement the rollback of the other operations? Can I use transactions?
I've tried using transactions but I'm not sure if I can use them on different Databases.
I need to save the information in the Realtime Database, the picture in the Cloud Storage, and the list in the Firestore.
That's indeed possible, by performing one operation, right after another, only when the operation succeeds. For example, as soon as the operation for writing data to the Realtime Database completes, then inside the callback, perform the addition of the image to Storage. As soon as the addition of the image to Storage succeeds, perform the last operation of writing the data to Firestore.
I would like all these operations to be successful, if one of these should fail then I would like the others to undo the data they wrote.
There is no built-in mechanism for that. If you thought you can add to a batch operation, a Realtime Database write operation, a Firebase Storage file upload
and Firestore write operation and be sure that all three are complete, so you can have consistent data, please note that this is not possible. These operations are a part of different Firebase services and unfortunately, at the moment I'm writing this answer there is no way you can make them atomic, meaning all succeed or all fail with an exception.
How can I implement the rollback of the other operations?
You have to write code for that because none of the Firebase products support cross-product transactional operations. To solve this, you'll have to nest the calls during your write/upload operations and handle the error if the next operation fails. This means that you either have to delete the data from the Realtime Database and the file from Storage if the write operation in Firestore fails. Or only delete the data from the Realtime Database if the file upload to Storage fails.
But note, at some point in time, there will be a failure that the client can't roll back one of the delete operations. The most common approach for these inevitable failures which might happen is to make your code robust by handling exceptions and performing occasional cleanups in both places, Firebase Storage and Firestore, considering that the first operation is the one that writes data to the Realtime Database.
As discussed with the Firebase engineers, the reason is quite clear. Even if the Realtime Database and Cloud Firestore are both Firebase products, they are still different products. Besides that, Firebase Storage is a service within Google Cloud. So now, 2023-01-12 there is no way you we can do that. Hopefully, it will be available in the near future.
Can I use transactions?
No, and that's for the exact same reason as above.
One way I might address this, is to use the Firestore document write operation to trigger a Workflow [1] that can handle the three operations and rollback depending on failure state. That way you can also have a constant transaction record follow the process.
If you wanted to provide app feedback say to the user, you could have your app. wait for a DB record of completion (or error) get written and based on that report back to the user.
[1] https://cloud.google.com/firestore/docs/solutions/workflows
I'm building an app which uses Firestore for storing most data. The app has a chat functionality and I was considering using Realtime Database for that. What are the benefits of using Firebase Firestore vs Realtime Database for this chat functionality? If there is no difference, should I use Firestore for everything?
P.S. I have already read the firebase comparison of the two https://firebase.google.com/docs/database/rtdb-vs-firestore and I am still not sure which way to go about this.
FB RTDB was designed for a chat application but is not so great for more than simple querying. Firestore was developed to improve the querying requirements and is newer. Newer doesn't necessarily mean better, depends on the use case. Their pricing models are very different, so you need to understand how your use case will be charged.
You can use both of course. They can work well together but if a simple chat requirement is all you need, I would use RTDB.
PS. The unique keys generated in RTDB for each new record are automatically in chronological order, which relates back to it being designed for a chat app. There is a caveat though, the chat messages may still get out of order because the keys are generated on the device and if the device clocks are slightly out and messages are being exchanged rapidly then you may get a miss timing. The way round this is to write each record with a property of server time...and use that to sort the chat messages. Hope that helps your decision.
PPS. RTDB charges for data storage volumes and data download volumes. Firestore charges for storage and db reads and writes. There will be a lot of the latter in a chat app so I would recommend running some what-if scenarios in Excel.
This question already has answers here:
What's the difference between Cloud Firestore and the Firebase Realtime Database?
(5 answers)
Closed 3 years ago.
I am building an app related to online bookings of Barbers in my city.I am planning to use Firebase to store my data and showing realtime updates. What will be the right option i.e. Realtime Database or Firestore. As much as I read, Firestore is great but it costs the developers according to number of queries and in my case query numbers will be much higher as I am planning to show realtime update to clients for their booking status.
And I am a naive in this area so suggest which one will be easy to learn.
It's up to you in the end, so I'll just name some main points:
Realtime Database is basically one giant JSON file, while Cloud Firestore is based on collections of documents.
Both offer realtime updating.
Cloud Firestore has better ways to filter and sort data.
Cloud Firestore has more advanced ways of writing and updating information.
Realtime Database is based on a single region, while Cloud Firestore can scale to multiple regions automatically.
They have different security options.
Realtime Database charges based on bandwidth and storage, but at a higher rate. As you mentioned in your question, Cloud Firestore charges based on operations on your database (read, write, etc.)
In the end, it all depends on how you want to work in your code. For example, do you want to work with one large JSON tree, or do you want to work with separate documents? Cloud Firestore is the newer of the two, but that doesn't necessarily mean it's better in your scenario.
Can the new Firestore service scale?
I know it's in beta. I'm looking for some live examples of Firestore Scaling.
In terms of:
Number of database transactions.
Size of database.
Also - Does firebase have some auto scaling policy.
Can Firebase itself scales in terms of:
Number of users (using the OAuth)
Does anyone have some Firebase scaling example and could share.
firebaser here
The first line on the main documentation page for Cloud Firestore:
Use our flexible, scalable NoSQL cloud database to store and sync data for client- and server-side development.
A bit lower in key capabilities:
Designed to scale
Cloud Firestore brings you the best of Google Cloud Platform's powerful infrastructure: automatic multi-region data replication, strong consistency guarantees, atomic batch operations, and real transaction support. We've designed Cloud Firestore to handle the toughest database workloads from the world's biggest apps.
That tells you that the folks that created Cloud Firestore thinks that scalability is one of its key features. Give that these are the same folks that worked on many of Google Cloud Platform's features, I tend to believe them on that front. :-)
There were also some earlier questions that may be relevant:
What's the difference between Cloud Firestore and the Firebase Realtime Database?
Designed to Scale -- Cloud Firestore will be able to scale better than the Realtime Database. It's important to note that your queries scale to the size of your result set, not your data set. So searching will remain fast no matter how large your data set might become.
Queries scale with the size of your result set, not the size of your data set
Just keep in mind that Cloud Firestore is still in beta and will be slower (but scale better) than Firebase's realtime database:
Firestore slow performance issue on getting data
This question already has answers here:
What's the difference between Cloud Firestore and the Firebase Realtime Database?
(5 answers)
Closed 5 years ago.
Recently Firebase Firestore was launched. After going through the documentation, I am confused how exactly Firebase Firestore is different Firebase Realtime Database and what are the situations in which Firestore should be used over Realtime Database as Realtime Database provides almost all the functionalites which Firestore provides (Querying, Security, Offline Capabilities).
In Realtime database of Firebase, it provides only the following features
Stores data as one large JSON tree.
Simple data is very easy to store.
Complex, hierarchical data is harder to organize at scale.
But in Firestone completely different data structure has been follow.
Stores data in documents organized in collections.
Simple data is easy to store in documents, which are very similar to JSON.
Complex, hierarchical data is easier to organize at scale, using subcollections within documents.
Requires less denormalization and data flattening.
For more detailing you can visit the following link: Difference between Realtime Vs Firestone