I'm new with Firebase technology and I would like to optimize Firebase database size (including for decrease cost).
What are the different ways to decrease Firebase database size?
Can I simply use node names as short as possible, for example instead of having a node "user", rename this node "u"? (relevant if this node is very present)
Do there are other tips?
Here's the approach we take from one of our mobile apps:
We have a mobile app, web service, Firebase Database and Firebase Storage. We sometimes have a small SQL database as well.
We have the mobile app display data from Firebase but write data to Firebase via the web service, never directly.
We started with using Firebase Database as our storage, then changed to a hybrid Firebase Database + Firebase Storage mix.
We now store the "view data" is Firebase Storage and only store a "stub/pointer" in the Firebase Database (it reduces data size and it reduces traffic).
We end doing an extra read from Firebase Storage every time the value of a "stub/pointer" changes in Firebase Database, but that works for our scenario. We also don't do it for every situation, so we peek and chose where it makes sense to use this approach.
We ended up reducing cost - that was our main reason to search for a solution and it looks like that's your motivation as well.
Other than that, using short names for the key names may help as well.
Related
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.
It seems odd to me that Firestore would charge me for read queries to locally cached data, but I can't find any clarification to the contrary in the Firestore Pricing document. If I force Firebase into offline mode and then perform reads on my locally cached data, am I still charged for each individual entity that I retrieve?
Second, offline users in my app write many small updates to a single entity. I want the changes to persist locally each time (in case they quit the app), but I only need eventually consistent saves to the cloud. When a user reconnects to the internet and Firestore flushes the local changes, will I be charged a single write request for the entity or one per update call that I made while offline?
Firestore could potentially fit my use case very well, but if offline reads and writes are charged at the same rate as online ones it would not be an affordable option.
As the offical documentation says,
Cloud Firestore supports offline data persistence. This feature caches a copy of the Cloud Firestore data that your app is actively using, so your app can access the data when the device is offline. You can write, read, listen to, and query the cached data. When the device comes back online, Cloud Firestore synchronizes any local changes made by your app to the data stored remotely in Cloud Firestore.
So, every client that is using a Firestore database and sets PersistenceEnabled to true, maintains it's own internal (local) version of the database. When data is inserted/updated, it is first written to this local version of the database. As a result, all writes to the database are added to a queue. This means that all the operations that where stored there will be commited on Firebase servers once you are back online. This also means that those operations will be seen as independent operations and not as a whole.
But remeber, don't use Firestore as an offline-only database. It is really designed as an online database that came work for short to intermediate periods of being disconnected. While offline it will keep queue of write operations. As this queue grows, local operations and app startup will slow down. Nothing major, but over time these may add up.
If Google Cloud Firestore priceing model does not fit your use case very well then use Firebase Realtime Database. As mentioned also in this post from the Firebase offical blog, one the reasons you still might want to use the Realtime Database is:
As we noted above, Cloud Firestore's pricing model means that applications that perform very large numbers of small reads and writes per second per client could be significantly more expensive than a similarly performing app in the Realtime Database.
So it's up to you which option you choose.
According to this If you want to work completely offline with Cloud Firestore you can disable network by :
FirebaseFirestore.getInstance().disableNetwork()
but firestore will cause client offline error for first user get request, that you must consider this error as empty response.
Firebase's documentation has the following paragraph:
Using Cloud Firestore and Realtime Database: You can use both databases within the same Firebase app or project. Both NoSQL databases can store the same types of data and the client libraries work in a similar manner. Keep in mind the differences outlined above if you decide to use both databases in your app.
I can't find any documentation on how to add a Cloud Firestore to an existing project with a Realtime Database, though. I will ultimately upgrade to Cloud Firestore, but would like some time to experiment and learn before I convert the production database.
Does anybody know how to use both databases in the same Firebase project?
When you go to your project in the console and choose the Database product, you should see something like this the first time:
This is a selector that lets you choose to see either Realtime Database or Firestore in your project. You can switch between the two with this selector.
The first time you select Cloud Firestore, it will ask you to configure things. Start in "test mode" to set things up for full read and write without authentication to get started quickly, but of course your should always have rules set up in production.
After you set up Firestore, you should be able to use both client SDKs to access both databases independently.
I learnt about real-time data storage and hosting storage from this post Difference between Data Storage and Hosting Storage?
But i am still not clear about real time Database and and newly introduced file storage.
Does anybody have some brief explanation about it ?
Thanks in advance .
(As per the concern about duplicated with Difference between Data Storage and Hosting Storage? what the problem solves and what i am asking are two different things and hosting storage and file storage are different in case of google firebase )
Firebase now offers these places to store your data:
Realtime Database
Remote Config
Hosting
Storage
Cloud Firestore
The best place to store your data, depends on the type of data you want to store and the way you want to consume it.
The Firebase documentation says this about it:
The Firebase Realtime Database stores JSON application data, like game state or chat messages, and synchronizes changes instantly across all connected devices.
Firebase Remote Config stores developer-specified key-value pairs to change the behavior and appearance of your app without requiring users to download an update.
Firebase Hosting hosts the HTML, CSS, and JavaScript for your website as well as other developer-provided assets like graphics, fonts, and icons.
Firebase Storage stores files such as images, videos, and audio as well as other user-generated content.
On choosing between Cloud Firestore and the Firebase Realtime Database, the Firebase documentation says:
Firebase offers two cloud-based, client-accessible database solutions that support realtime data syncing:
Realtime Database is Firebase's original database. It's an efficient, low-latency solution for mobile apps that require synced states across clients in realtime.
Cloud Firestore is Firebase's new flagship database for mobile app development. It improves on the successes of the Realtime Database with a new, more intuitive data model. Cloud Firestore also features richer, faster queries and scales better than the Realtime Database.
*Realtime database store data only json format and it is specially used in app where data is synchronized concurrently like ola app(user location),sensex(Nifty) app where data not persist .
*Firebase Storage just only store data like memory card.It is specially used for store backend data of app.
I learnt about real-time data storage and hosting storage from this post Difference between Data Storage and Hosting Storage?
But i am still not clear about real time Database and and newly introduced file storage.
Does anybody have some brief explanation about it ?
Thanks in advance .
(As per the concern about duplicated with Difference between Data Storage and Hosting Storage? what the problem solves and what i am asking are two different things and hosting storage and file storage are different in case of google firebase )
Firebase now offers these places to store your data:
Realtime Database
Remote Config
Hosting
Storage
Cloud Firestore
The best place to store your data, depends on the type of data you want to store and the way you want to consume it.
The Firebase documentation says this about it:
The Firebase Realtime Database stores JSON application data, like game state or chat messages, and synchronizes changes instantly across all connected devices.
Firebase Remote Config stores developer-specified key-value pairs to change the behavior and appearance of your app without requiring users to download an update.
Firebase Hosting hosts the HTML, CSS, and JavaScript for your website as well as other developer-provided assets like graphics, fonts, and icons.
Firebase Storage stores files such as images, videos, and audio as well as other user-generated content.
On choosing between Cloud Firestore and the Firebase Realtime Database, the Firebase documentation says:
Firebase offers two cloud-based, client-accessible database solutions that support realtime data syncing:
Realtime Database is Firebase's original database. It's an efficient, low-latency solution for mobile apps that require synced states across clients in realtime.
Cloud Firestore is Firebase's new flagship database for mobile app development. It improves on the successes of the Realtime Database with a new, more intuitive data model. Cloud Firestore also features richer, faster queries and scales better than the Realtime Database.
*Realtime database store data only json format and it is specially used in app where data is synchronized concurrently like ola app(user location),sensex(Nifty) app where data not persist .
*Firebase Storage just only store data like memory card.It is specially used for store backend data of app.