Can i perform data mining techniques on a Firebase's Database?
I want to classify data that i will get from the user and come with some results from it for my Android graduation project.
The project core is Data mining, so is Firebase friendly for this?
The Firebase Realtime Database API is optimized for synchronizing data between large numbers of users. It is not ideally suited for data mining, which typically requires different access patterns to the data.
Note that it's quite possible and common to combine the Firebase Realtime Database with other data storage solutions to server all needs of an app. Many developers combine Firebase with BigQuery, using the latter for their data analysis. That way your users/app can write straight to the Firebase Database (or Cloud Firestore). You'll e.g. use Cloud Functions to pass that data onto BigQuery, where you do the analysis on it. Any analysis result you'll write back to the Firebase Database, where clients can read them. With this approach Firebase functions as a proxy between your (mobile) clients and your custom cloud infrastructure.
Related
I'm using sqlite to store data in my app, i would like to sync my database with firebase so that i can do modify data from firebase and insert it into my database without updating the app. Any suggestions how can i do that.
You don't need to sync Firebase with your local database. Firebase provides you SDK to perform read/write operations in your database. You might only need to update your application if there is a schema change. That too can be achieved without keeping the computation logic in the Cloud and instead call Cloud Functions for cases where you know there are going to be a lot of schema changes.
Firebase provides you really well documented APIs and code samples. You can refer the following links for more information:
Firebase Docs -- SDKs here
Cloud Functions -- For cloud computation
Realtime Database -- Database for realtime transfer, can be costly for high usage. Generally used for PoC or low traffic projects
Firestore -- Upgraded version of Realtime DB. Generally used for high traffic.
So for my Android App which stores data of workouts I have been using a SQLite Database so far. Now I want to implement these features:
Offer workouts in real time (with Firebase Database)
Being able to access your data on other devices and maybe from an web app
later
I figured, that for this purpose Firebase would be a great fit. But switching from SQLite to Firebase would bring a few down sights in my opinion:
Every user would need to sign up. I think for some users this is a reason to
not use my app. There is no way to avoid having to sign up when using
Firebase to store the data for user, right?
I´m not sure how good the offline options of Firebase Database is. How long
will the data be accessible without a connection? Is the capacity and
performance comparable to a SQLite Database?
I thought an alternative way could be to use Firebase just for offering the workouts but keep the data about a workout (repetitions, weight, ...) in a SQLite Database. Then I could upload the Database File with Firebase and another Device could download and continue it. Could that be an option?
Any thoughts and advice are appreciated!
Every user would need to sign up. I think for some users this is a
reason to not use my app. There is no way to avoid having to sign up
when using Firebase to store the data for user, right?
Right. (Technically it is possible, however you will need to enable read / write operations to non registered uses which is a no-no and not recommended at all.)
I´m not sure how good the offline options of Firebase Database is. How
long will the data be accessible without a connection? Is the capacity
and performance comparable to a SQLite Database?
From the firebase database docs: Firebase apps automatically handle temporary network interruptions. Cached data is available while offline and Firebase resends any writes when network connectivity is restored..
So yes, you can continue writing to it even when offline and read the already cached data, but this does not solve your concern that users will have to register to use the app.
Possible solution
Use both SQLite and Firebase database:
For a registered user, always write in both SQLite and Firebase to keep them in sync (write in Firebase first and then SQLite). Another option is to write in SQLite and sync to Firebase every X minutes. Read data from Firebase when online and from SQLite when offline.
When the user is offline, you will to write data to SQLite. You will need to mark those records as non-synced so that next time it is connected you will write them to firebase.
Also, when reconnected, you'll need to somehow merge firebase data (that might have changed) and local SQLite data. The algorithm for this depends on your app.
For non-registered users, use SQLite only.
The downside to all this is that the complexity of your application increases a lot. It's up to you to decide whether it's worth it or not. :)
I am trying to develop an app whereby I want to exchange files (video, images) within the cloud storage(firebase) and client(android app).
I wanted to know if there is any sync API in firebase which keeps track of any updates i.e any changes being performed in the firebase storage and replicating the same to the client (and vice-versa if possible).
Thanks in advance !!
Go to the page of Firebase and read what the header says:
Store and sync data in real time
Furthermore:
The Firebase Realtime Database is a cloud-hosted NoSQL database that
lets you store and sync data between your users in real-time.
What Realtime means is this:
Instead of typical HTTP requests, the Firebase Realtime Database uses
data synchronization—every time data changes, any connected device
receives that update within milliseconds. Provide collaborative and
immersive experiences without thinking about networking code.
So just add Realtime Database Dependency and you are set. This itself will serve the purpose of Sync API you need.
This question already has answers here:
What's the difference between Cloud Firestore and the Firebase Realtime Database?
(5 answers)
Closed 5 years ago.
On the firebase console a Cloud Firestore tab has been added and going through the documentation it has some similar features like Realtime database. My android app already uses the Real-time database, functions, and storage and everything work fine. I would like to know how the Cloud Firestore can make my application better and what are the special features present only in Firestore that are not there in the real-time database that could improve my application.
I have a chat based application running on the real-time database and I am performing very frequent requests for small amount of data. Will switching to Firestore reduce my cost? Will it maintain or increases the speed of operation?
A developer advocate answers in blog post
The main points:
Better querying and more structured data
Designed to Scale
Easier manual fetching of data
Multi-Region support for better reliability
Different pricing model
The Cloud Firestore is an upgrade on the Real-time database although the Cloud Firestore is still in beta.
The Cloud Firestore offers
Better and faster data queries. With the C. Firestore, data at the top collections can be fetched without grabbing any sub-collections in its children node. This prevents downloading unwanted data from your db unlike the real-time db.
Scalability: The above already explain why this is more scalable.No matter how large your db is, your app will only request for necessary data unlike the real-time db.
Read more: https://firebase.google.com/docs/firestore/rtdb-vs-firestore
I have been using SQLite as my storage solution for my android applications. I want to be able add synchronization functionality to one of my apps, Firebase looks like a good solution but the problem is that I need to know if I am to use Firebase to sync data with the SQLite database or Firebase can work and totally replace SQLite. I know Firebase has offline persistence but while offline can it hold as much data as SQLite and are the queries as powerful?
Clearly this depends on the business rules for which the options are considered. So there will not be the "right" answer to this.
At least one of our team members was thinking along these lines. Here is our solution:
Do all transactional data locally on the SQLite as we do not need transactions to be across devices.
Sync the rest using Firebase.
(1) makes sure that we don't misuse Firebase's non-persistent offline availability of its client.
The docs
Even with persistence enabled, transactions are not persisted across app restarts. So you cannot rely on transactions done offline being committed to your Firebase Realtime Database. To provide the best user experience, your app should show that a transaction has not been saved into your Firebase Realtime Database yet, or make sure your app remembers them manually and executes them again after an app restart.
(2) make sure that we use Firebase's persistent offline nature to synch non-transactional data across devices once connection is (re)established.
The docs, The Firebase Realtime Database client automatically keeps a queue of all write operations that are performed while your app is offline. When persistence is enabled, this queue is also persisted to disk so all of your writes are available when the user or operating system restarts the app. When the app regains connectivity, all of the operations are sent to the Firebase Realtime Database server.
This way we achieve a state acceptable within our use.
"can it hold as much data as SQLite and are the queries as powerful?" no and no if powerful is translated as "transaction across devices", by definition of Firebase being a remote database.