Notes on building realtime database with Firebase

Tram Ho

1. Use Flatten data structures instead of nesting data:

eg nesting structure:

Must be converted to: -> Flatten structure (Denormalization)

2. Create a data structure so you can scale without affecting performance while fetch data:

Examples of groups & users & their relationship. In the case of a lot of groups & lots of users, then querying which user belongs to which groups or a group contains which users will become very expensive if we do not use the following trick. Index user & group data for faster searching.

In the above example, when looking at a glance, we see 1 data redundancy: alovelace contains group techpionners and group techpionners contains the user again alovelace!!!
That is the redundancy needed to make the querying data fast, in our case we have millions of groups & millions of users. If standing in position 1 user -> the query gets the groups that that user joins at low cost. Or stand in a group: we can immediately query out the members of the group.

Note in this section: when using changes, the data must change 2 places, so when using in code should pay attention.

3. How to update data in multiple places (path) in the database with 1 call of the API:

When erasing can also use this technical with parameter pass null & call UpdateChildrenAsync ()

4. Notes on using realtime database to save money

  • The database billing is based on the amount of database storage and network traffic (all outbound network traffic). $ 5/1 Gb per month, billed every 1 day.
  • Outbound network traffic includes the cost of connection and encryption from all database activity and data downloaded for reading by the client .. all types of connections … have to pay ..

Estimated payout like?

Use the usage tab:

  • connections: the number of concurrent connections to db
  • Storage: storage of the database, not including data in other firebase products (only db)
  • Downloads: Total downloaded bytes, including protocal & encryption overhead.
  • Load: Indicates the amount of db being used.

How to optimize the cost?

According to google’s guidance, there are some best practices as follows:

  • Using Native SDK instead of using REST API minimizes SSL cost & can use local cache.
  • Check bugs constantly: Check sync too much data? or regular sync -> wasteful. Running sync in the background & sync is there as expected?
  • Reduce connectivity: optimize bandwidth if possible. Often times, multiple REST requests can be more expensive than connecting with the native SDK. If the project must use a REST API, consider using HTTP keep-alive or server-client events to minimize the cost of SSL handshakes.
  • Index queries: see how to index the database here. This reduces the total amount of bandwidth you use for querying. Tools to determine which data is not indexed here.
  • Optimize listening events: Add a query to limit the data your listening returns and use listening to download only updates for the data e.g. use on () instead of once (
  • Optimize storage: attach additional parameters to the user tables and data tables, then run cleanup jobs to clean up temporary data …
  • Use the rule: Avoid potential costs, unauthorized activities on the database. For example avoiding hackers continuously downloading components in the database -> costs.
Share the news now

Source : Viblo