Jay N
Jay N

Reputation: 418

Firebase Realtine .indexOn

I understand that using .indexOn is better for performance but to understand further here's my question whether or not I should design my tree nodes differently.

Let's say I want to search for a name and see if it exists. I could have:

names
   jack : true
   john: true

or

people
   UID1
      name : jack
      age : 10

If I had .indexOn at "name" in the "people" node. Would it have the same cost/performance as the first tree? The reason I ask is because I want to avoid making as many tree nodes as possible.

Upvotes: 1

Views: 48

Answers (1)

Frank van Puffelen
Frank van Puffelen

Reputation: 598728

The cost for reading from the Firebase Realtime Database is based on the bandwidth that is transferred. In the first JSON, you'd only be reading true, while in the second snippet you'd end up reading the entire UID1 node. So that would be (marginally) more expensive.

If on the other hand, you also look up the user profile after reading jack: true from the first JSON, then that approach probably reads more data and would thus be (again: marginally) more expensive.


In the first JSON snippet, you can look jack directly based on their path, without needing a query. A direct lookup is the fastest way to read a node.

In the second JSON snippet you're going to need a query. When you have only a few users, the performance is going to be quite similar. But as the number of users grows, this query will start taking more time (even when you've defined an index to ensure it happens server-side).

But this performance difference won't be very noticeable until you have hundreds of thousands of users. Before that it is likely dwarfed by the impact of network performance.

Upvotes: 1

Related Questions