I want to make a large e-commerce app. Here is the node and child number I want to use. I want to make 500 nodes, each node has 1000 child and each child has 10 children like name, price, type, location, phone number, description, date, etc. And my app has daily users are 1000.
Can I use the Realtime Database for this? Users can show data without problems?
None of these sound like they go beyond the documented limits of Firebase's Realtime Database.
As usual with NoSQL database, performance will depend more on how you implement things than on the database itself though, so be sure to read the documentation on structuring data, how to secure data access and watch David's classic video series on Firebase for SQL developers.
if your data is large then we using paging in our recycler view. we integrate paging in real time to fast your application response. Real time support start position and also limit same as sql.
check this link:
Firebase android pagination
Related
In my chat application, I store the participants of a chat as their UIDs in a Map so I can so I can do queries like this:
.whereEqualTo("participantUIDs.$currentUserUid", true)
.whereEqualTo("participantUIDs.$partnerUid", true)
The problem is when I try to use this with orderBy
.whereEqualTo("participantUIDs.$currentUserUid", true)
.orderBy("lastMessageSentTimestamp")
I have to create a custom index. But this index will contain that specific user UID and I can't create an index for every user in my app. How can I circumvent this problem?
You can order the documents on the client after an unordered query. This should not be very taxing on the client app when the number of documents is less than 10,000.
Regarding:
I can't create an index for every user in my app.
That's definitely not an option, as there are some limitations when it comes to Cloud Firestore indexes:
https://firebase.google.com/docs/firestore/quotas#indexes
However, even if you manage to stay below these limits, that's not an option to manually create an index for each and every user that joins your app.
In my opinion, for your particular use-case, you should consider augmenting your data structure to allow a reverse lookup. Meaning that you should create a participantUIDs collection where you should keep the lists for each user. This technique is called denormalization and is a common practice when it comes to NoSQL databases like Cloud Firestore or Firebase Realtime Database.
But remember, there is "no perfect database structure":
What is the correct way to structure this kind of data in Firestore?
It's a little old, but I think this video might also help:
https://www.youtube.com/watch?v=u3KwKQddPoo
More info regarding why you need an index:
Why does this firestore query require an index?
P.S. You can also rely on Firebase Realtime Database when Cloud Firestore may become a little expensive. Both work really well together.
Info:
Array or Subcollection for storing events user uploaded
I need to perform two different queries in my app.
Display a global leaderboard (rank all users based on points)
Display a leaderboard only among friends of the currently logged-in user.
Currently, I have structured my database as follows.
Users (collection):
user_id (document):
...
points: number
...
Friends (sub-collection):
user_id (document):
name: string
points: number
This approach works for populating the global leaderboard as it's just:
db.collection("Users")
.orderBy("points", Query.Direction.DESCENDING)
.limit(10)
.get()
Displaying a leaderboard among friends of a user also works in this case, but updating points of a user becomes an expensive operation because of multiple duplication.
Is there a way to structure my database so I can efficiently query and update my users collection?
I think what you're doing now is probably the best way to go. Data duplication is normal for NoSQL type databases, and it's expected that you'll do multiple updates to keep everything in sync if something changes. That's totally normal.
The alternative is to keep all relevant data in a single collection somehow (don't use a subcollection to store friends), but then you'll end up with a different problem of eventually exceeding the capacity of the document that contains all the data for each user.
The bottom line here is that NoSQL databases like Firestore give you better scalability and faster queries at massive scale, at the expense of less flexible querying and more work keeping duplicated data up to date. If you would prefer more flexible querying and easier updates, then Firestore might not be the best database for your application.
I am struggling with creating Android database for my app. Below is the picture of the data I need to save/store based on the location.
On Device: I need to store sensor which comes at a frequency of 100Hz. User is going to use the app app for few hours which means there is going to be a lot of sensor data. If user is going to use the app multiple times (multiple session) after short breaks then I need to store data sensor data perssion wise on device.
What I was thinking: Create SQlite database and create a table and add column dynamically and add sensor data to that column. Each column is session. col 1 = session 1, col 2 = session 2 etc.
Is it bad to do like this then what you guys would suggest?
In cloud: Now, how should I go about creating database if this data is going to get stored on cloud (GoogleCloudPlatform specifically) per user per session wise sensor data.
Any suggestion is welcomed. Please don't mark it as broad question because I am looking for efficient method to achieve this.
Refer the image below for further explanation or ask me for further explanation.
I prefer to youse RoomDB as per your requirement and consider the facts. Because Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.
Apps that handle non-trivial amounts of structured data can benefit greatly from persisting that data locally. The most common use case is to cache relevant pieces of data. That way, when the device cannot access the network, the user can still browse that content while they are offline. Any user-initiated content changes are then synced to the server after the device is back online.
Also, I prefer to use firebase realtime DB along with room for better efficiency and reliability. If you are using roomDb and firebase for cloud storage you can use a single entity for both firebase and roomDb. It will also help you write less code and better reliability.
Because Room takes care of these concerns for you, I highly recommend using Room instead of SQLite.
For reference, Please go through this link Save data in a local database using Room
I need to do a application that incorporates a database and I'm thinking about using the Firebase Realtime database.
Basically the application is an information app. It has different categories, Shops, Restaurants, Attractions, ect. I've almost completed the Udacity course on firebase and It can do what I need, I'm just not sure it's the most efficient.
They way they explain the database is structured is having a key so my key would either be Shop, Restaurant or Attraction. Below the Shop key there would be "Shop1","Shop2","Shop3", ect. Now this is where my problem comes in, inside shop1 I'm planning to have the shop name, longitude, latitude, description, and other details about the shop. Each time I want to add a new shop I'm going to have to add a child of the shop then under the new child I'm going to have to manually type the key and value.
This will get very time consuming and I was wondering if this is the correct way of adding data to the database ?
Thanks
Is Firebase the best way to store data for an information app?
This question is primarily opinion based, but since Firebase gives you so many choices under the hood, it is becoming a pretty decent service. Being scalable and the quick response of the database is a great option.
Read more about a good Database Schema here and about populating the database, you can write cloud functions and that would be a pretty advanced level of implementation.
May be your question is "What is the best way to store data for an information app in Firebase?"
In your case, it will be difficult to save sequential key without keeping track the number of shop.
I would rather suggest using push(shopModel). If you're using push, the key will be automatically generated and it's guaranteed to be unique and order by time inserted.
I am developing a social networking android app. I am currently using parse as my back end. I am using Parse.com to store the text messages and fetch those messages.
The first problem with parse is that it runs very-2 slow.
The second problem is that I have to set limit to 1000 users. How can I access large number of users or data?
How can i fetch the results faster with large number of users?
Should i consider using any other backend like google app engine, etc.
I want to fetch and store results quickly, just like facebook and WhatsApp? I would really appreciate your ideas/feedback/suggestion. Thanks
The problem is not that parse is slow, but more likely that your data model is not optimized for use on a NoSQL database service like parse. You probably have SQL experience and created your data model like you would for a SQL database.
With NoSQL (and especially mobile apps), you need to model for queries; not normalisation and consistency.
When designing your backend, first create a list of the most commonly used queries your app will have. Then design your model around how to minimize the number of queries necessary for retrieving the dataset you need.
Why do you need to get 1000 or more users in one query?
I recommend you take a look at the data model behind the Anypic app on parse.com. The model is very simple, yet extremely versatile.
If you are a SQL-person (like I was), you need to "unlearn" your relation thinking and start thinking about query speed :-)
For a better answer you should probably paste some of your code to know how is the query you are making and how is your data model. That is the only way you can optimize your query because you cannot make Parse itself faster and you cannot remove its limits.
By the way, I work in Backbeam. It is a fast backend as a service and it has support for complex queries such as making joins. Maybe you want to give it a try.