Let's say we have a database of 10 GB with a structure like that (with more books, etc):
What happens if I open this database in the Data View of the Firebase console?
I've learned that with the realtime database it's not possible to just read the keys of an object.
How does the Data View know the subkeys of the root (such as "channels", "input") without downloading all the contained data. Further more:
Do I have to wait until "channels" is completely downloaded to see "inbox"?
Did I then cause 10 GB download costs? (assumed I wait accordingly)
If your database is large the Firebase console switches to "read-only" mode. In that mode the console uses the REST API to download a shallow listing of only the keys of the level you're seeing. This should drastically reduce the amount of data it downloads.
Related
My website provides artists with an audio visualization of their uploaded mp3 files. Firebase Storage isn't necessarily the issue, but rather a bandwidth. Every time a fan accesses the website, the website downloads the mp3 from Firebase Storage in order to access the frequency data to visualize it. Given each mp3 is ~8MB, you could see how even having 200 fans accessing the website would go over the 1GB free quota, so having thousands of people viewing the website would become expensive and not scalable. I've considered hosting on SoundCloud, but I wouldn't be able to download the mp3 data in that case, only stream. What do people commonly do in this situation, where they need to have larger files like mp3s downloaded to display to the user without quickly running out of bandwidth?
Firebase Storage isn't necessarily the issue, but rather the bandwidth. Every time a fan accesses the website, the website downloads the mp3 from Firebase Storage in order to access the frequency data to visualize it.
So most likely, that's why you're having that problem related to the bandwidth because you're downloading all audio files, each time a user opens the website. That's not how you should handle this kind of situation. Instead of downloading all audio files, you should only display the name of the files, and only download them on demand. For example, you should store the name of the files and corresponding URLs from Cloud Storage, either in Cloud Firestore or in the Realtime Database, and as soon as the user clicks the download/play button, only then does start playing/downloading them.
Given each mp3 is ~8MB, you could see how even having 200 fans accessing the website would go over the 1GB free quota, so having thousands of people viewing the website would become expensive and not scalable.
The problem isn't about scalability, it's about costs. Cloud Storage for Firebase can easily scale to millions of files. Besides that, please also bear in mind that the free quota, it's used for testing puposes and not for real-world applications. For that scenario, you should consider upgrading to the Blaze Plan.
I am developing a chrome extension for the new tab page and I am trying to find the right DB for the project. The only question that is keeping me from using Firebase Firestore is to know how the DB handles reads.
Basically, every time the user opens a new tab page I will need to fetch around 3000 (very small) documents (hopefully from cache). My issue is that since opening a new tab page is done so frequently I will be charged an absurd amount of reads because firestore is always reading 3K documents.
My question is, is Firestore smart enough to tell that in the DB data has not changed and the client should only read from the cache?
I read all about offline persistence but this question is still lingering!
Thank you for any help!
When you start a listener you read first from the cache and then from the server. The cache persistance here explains how it behaves but considering only that the listener is in the listening mode. Even then after a 30 in offline you would be charged for a full read.
I would recommend you to read this. To manage your cache on your own to awoid to much reads as you are reading a large amount of data.
I am going to build a mobile app for my dad which will have four tables namely- buyer table , seller table , buyer balance payment table and seller due payment table. I have thought of using Reactive Native and SQLite due to its offline data storage capability.
Transaction limit per day will be between 2-10 rows in buyer and seller table.
Can anyone advise whether the offline data storage is safe?
Can anyone read the data from phone storage or its hidden inside the app?
Is it possible to export/import the data weekly to personal cloud storage like google drive or Microsoft one-drive and vice versa?
Is it advisable to publish such apps to app store or can i use it without publishing?
If the app is for personal use, u don't have to publish in play store. You can create apk and install in your phone.
SQLite storage is adequate for offline storage but u might lose data if backup of the data is not been taken.
Encrypt your data before you enter it in the database. As far as I know, the SQLite database is kept in a single file somewhere in the /data/ directory. What is more, your data is kept in plain text format. This means that it will always be possible for someone to extract that data by rooting the phone, obtaining the .db SQLite file and opening it with a text editor.
If the data is sensitive, you should consider encryption.
Yes, you can take backup and storage as encrypted file in cloud.
In my personal opinion, you can use firebase or other free cloud websites to host your data. It will be more simple and secure.
Every time I close my application it has to load the data from the firebase again. Is there any way for it to already open with the last data fetched?
If you enable disk persistence, the Firebase client will write any data it sees to a local disk cache. This means that when you restart the app when there's no connectivity, the same data that you saw before is available offline on your app.
For more info, see the Firebase documentation on disk persistence and the call to enable it from Flutter.
You should explain a bit more, so we understand your use case. Anyways, i'll try to answer with what I have understood.
You can use sqflite package to cache the data, i.e. it will be stored to the local storage. Get started: https://pub.dev/packages/sqflite
It will be fairly complex, even unnecessary if the size of your data is small.
If you have huge amount of data that doesn't change frequently, then go for it.
So how it will work is like this:
First you'll check whether the data has changed in Firestore or not.
Case 1: If it didn't then you'll display data from your local sqflite db.
Case 2: If it did change, then, you'll display data from Firestore, and at the same time update your local db with the new data.
Again, this is very superfluous if your data size is be small/it changes very frequently.
I use firebase cloud storage to upload images.
The app I am working on allows users to send images to one another (a chat thing), so that one user uploads the photo and another one will download it and once it is downloaded it should be deleted from the storage.
Example of what I am talking about
User A sends a photo to User B by uploading it to firebase storage, then User B notices that User A send him an image and decides to download it, after User B downloaded the image it should be deleted from storage.
My question
What if User A sends too many images and User B never downloads any of these images. Then this means that I will end with useless images on storage taking space.
So in this case is there a way in firebase to auto delete a file after it has been uploaded after (n) amount of time (not client side)?
I am still in the middle of doing this research, but it seems like you can use life cycle rules to delete files based on the age of the file.
Here are a few examples listed in the intro of the doc.
Downgrade the storage class of objects older than 365 days to
Coldline Storage.
Delete objects created before January 1, 2013.
Keep only the 3 most recent versions of each object in a bucket with
versioning enabled