Speed Up Fetching Posts For My Social Network App by Using Query Instead of Observing a Single Event Repeatedly

Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly

Is there anyway to run Firebase realtime database queries with multiple keys?

If you're asking whether you can get posts from multiple userUID values with a single query, that is not possible.

If you're asking whether you can pass a list of postUID values to retrieve, that is also not possible.

In both cases the solution is to execute a separate query/read operation for each of the values, and merge the results in your application code. This is not nearly as slow as you may think, since Firebase pipelines the requests over a single web socket connection - which is quite efficient. For more on this, see Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly

How to get child of child value from firebase whose parent value is unknown in java

After reading the various answers on this topic linked above by Mr. @Frank van Puffelen and spending some times over it, the problem is finally solved now without changing my database structure.
Below is screenshot of the result which I wanted:

Here is my modified and working code :

private void retrieveData() {

    final String shift = kvName.getText().toString();
    final String employeeCode = empCode.getText().toString();

    final DatabaseReference aparRef = dbRef.child("Apar").child(shift);

    aparRef.addValueEventListener(new ValueEventListener() {
        @Override
        public void onDataChange(@NonNull DataSnapshot dataSnapshot) {

            list = new ArrayList<>();

            if (dataSnapshot.exists()) {

                for (DataSnapshot dataS1 : dataSnapshot.getChildren()) {

                    if (dataS1.hasChild(employeeCode)) {


                        AparData aparData = dataS1.child(employeeCode).getValue(AparData.class);
                        list.add(aparData);

                        rvAPAR.setHasFixedSize(true);
                        rvAPAR.setLayoutManager(new LinearLayoutManager(Apar.this));
                        rvAPAR.setItemAnimator(new DefaultItemAnimator());
                        aparAdapter = new AparAdapter(Apar.this, list);
                        rvAPAR.setAdapter(aparAdapter);

                    } else {
                        Toast.makeText(Apar.this, "No Data Found!!", Toast.LENGTH_SHORT).show();
                    }

                }
            } else {
                Toast.makeText(Apar.this, "Not Data Found!!", Toast.LENGTH_SHORT).show();
            }
        }

        @Override
        public void onCancelled(@NonNull DatabaseError databaseError) {

        }
    });

}

Is it possible to query multiple keys in a single query?

This is not possible. You must request them each individually. All queries for a node always get the entire node, including all of its nested children. Children cannot be selectively included or excluded.

It's worth noting also that there is not much overhead in making multiple requests. The data for each query is pipelined over a single socket connection, so as long as you keep that connected saturated with requests, you are not losing very much perceived performance.

query for blog FIREBASE + REACTJS

Firebase doesn't have an equivalent of SQL join statements. If you want to get data for two different entities (blog/members and user in your case), you have two options:

1. Read the data for each member after you get the relevant blog.
2. Duplicate the relevant data for each user into each blog they're a member of.

Neither of these is pertinently better than the other, although the second is more common under folks that optimize for read throughput, while the former is more common under folks that are newer to NoSQL data modeling.

Some recommended reading to get to grips with this:

• NoSQL data modeling.
• The video series Firebase for SQL developers.
• Getting to know Cloud Firestore, which is about Firestore but covers many principles that equally apply to the Realtime Database.
• Join two nodes in Firebase
• Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly, which explains why client-side joins are not as slow as you may think.

DB Best Practice to track user timestamp data with NoSQL DB (using firebase)

Honestly the difference between the options is small, and the best option depends on your use-case more than anything else.

---

In all three scenarios you can get the usage for a user for an app for a range of days with a single operation. In the first two cases, that'd be firebase.database().ref(uid).child(appNameOrUsage).orderByKey().startAt(firstKeyToReturn).limitToFirst(30). In the third scenario that'd take a firebase.database().ref(uid).child("usage").orderByChild("timestamp").startAt(firstTimeStampOfMonth).endAfter(lastTimestampOfMonth).

Even if you needed multiple requests, that's not nearly as slow as you may think because Firebase pipelines the requests over a single socket connection as explained here: Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly

---

In NoSQL databases it is typically best to store the data as you show it on the screen. Since you seem to want to show usage per month, I'd actually recommend to (also) store the aggregated usage per month, and per app per month.

Storing duplicate data may be counter-intuitive if you come from a SQL background, but is actually quite common in NoSQL land - and often a primary reason why these database scale so well when it comes to read operations.

So here I'd probably store all aggregates you might want, so:

• per user across all time
• per user for each month
• per user per all across all time
• per user per app for each month
• across all users across all time
• across all users for each month
• etc

The write logic becomes more complex this way, but reading the data for a chart becomes really simple. That's another common pattern in NoSQL databases.

---

Finally: Firebase Realtime Database, like most NoSQL databases, are not well suited for executing ad-hoc queries. If that is what you need, consider a better solution for the use-case, such as BigQuery if the datasets may become arbitrarily large.

How Can I Use Data More Efficiently (Economically) With Firebase?

There is no singular correct answer here, it all depends on the need of your application and your comfort level with various solutions.

Duplicating the data is a common approach in Firebase (and other NoSQL databases), since it means you get the necessary data with the minimum number of API calls, and thus is often the most scalable solution.

On the other hand, performing additional load operations is quite fast on Firebase since it pipelines the requests over a single connection, so the data model with just IDs is quite feasible too.

In the end, only you can choose. Since you mention cost, that'd be something you can quickly measure/estimate between both models and then use the pricing table/calculator to determine what fits those needs best.

---

Related Topics