Store Time Efficiently in Firebase Database

Store Time efficiently in Firebase Database?

You can use time interval and just store it like a number

var interval = NSDate().timeIntervalSince1970

And when you need the date just get it like this

var date = NSDate(timeIntervalSince1970: interval)

Store data in Firebase for a limited time

Your best bet (currently) is to set up a recurring job to periodically sweep entries out of your database. You can do this with Cloud Functions for Firebase and a scheduling mechanism you provide. There is a blog and video about this.

I suggesting storing the time to delete as an abosolute date in time (like System.currenTimeMillis()) rather than as a delay so you can query the database for everything that ought to be deleted at this moment.

Is Firestore a good choice for time series data?

Probably best bet would be to use a time-series database. Looks like Warp 10 has already been mentioned (https://www.warp10.io).

The benefit of something like warp is the ability to query on the time component of your database. I believe firebase only has simple greater/lesser than queries available for time.

Storing the time and the Data in firebase Database

I think that you can achieve this simply using the Date() object's native methods like getFullYear(), getFullMonth() etc.

Here's the code.

const date = new Date();
const year = date.getFullYear();
const month = date.getFullMonth() + 1 // months start from 0
const day = date.getDay()
const hour = date.getHours();
const minutes = date.getMinutes();

const time = `Received at ${year}-${month}-${day} ${hour}:${minutes}`;

Store time values in Firebase

There is!

[ref setValue@"2pm"]

or

[ref setValue@"20160216130100"]

or

any number of other ways to represent dates. Timestamps are spiffy.

Keep in mind that while they are strings, they still represent specific times and dates. You can sort by them as well as query for them.

If you are developing on MacOS/iOS, they work well with NSDate, NSDateFormatter, NSDateComponents.

A date string:

NSDate *myDate = [[NSDate alloc] init];

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"YYYYMMdddd HH:mm:ss"];  //20160217 13:14:22
NSString *dateString = [dateFormatter stringFromDate: myDate];

[ref setValue:dateString]

You should carefully consider how you want your date formatted for consistency throughout your app and data.

I would suggest investigating the Firebase timestamp function.

How to efficiently get 7 days, 30 days summary from Firebase realtime database?

Firebase Realtime Database has no built in aggregation functions.

You have a few options:

• Load all data, and calculate the aggregates on demand.
• Keep running aggregates in the database, and update the on every write operation.
• Export the data from Firebase to a system that has better querying capabilities (like BigQuery or Data Flow), and then write the results back to Firebase.

This topic has been covered before, so I recommend checking out:

• What is the best way to show reports with firebase?
• Realtime database data structure modeling
• How to use Firebase for statistics?
• Do some work on the data on firebase database
• Sum firebase data efficiently up
• Retrieve count data from Firebase like MySQL
• Analyze Firebase data
• Create dashboard on Firebase Database for various metrics

Efficiently storing and retrieving likes

You can do both things:

1) Create a votes node with the UID as key and a value to sum up all the votes.

post:{
  //All the data
  likes:{
     $user_1:1,
     $user_2:-1,
  }
}

And then just get a SingleValue Event or a Value event(depending if you want to keep track of changes) and sum up all the children

2)You can use a transaction block and just save a value and increase or decrease it depending on the votes

(here is a link where you can find transactions for android,iOS or java)
https://firebase.google.com/docs/database/web/save-data#save_data_as_transactions

 post:{
   //All the data,
   likes:2,
 }

It really depends on how much information you want to store, and what the user can do once he/she already voted for some post,

I would recommend using both, to keep flexibility for the user to like (like in Facebook) so he can unlike something and use the transaction with number to keep it scalable.. so if a post gets 1,000,000 likes you don't have to count the 1,000,000 likes every time someone loads the post

---

Related Topics