0

I am developing an Android app that uses MongoDB to store user records in document format. I will have several records that contain information about a GPS track such as start longitude and latitude, finish longitude and latitude, total time, top speed and total distance.

My question is regarding average speed. Should I let my app compute the average speed and store that as a field in the document, or should I compute this by only getting time and distance?

I will have thousands of records that should be sorted based on average speed and the most reasonable seems to store the average speed in the document as well. However, that breaks away from traditional SQL Acid thinking where speed would be calculated outside the DB.

The current document structure for the record collection is like this:

DocumentID (record)
DocumentID (user)
Start lnlt
Finish lnlt
Start time/date/gmt
End time/date/gmt
Total distance
Total time
Top speed
KMZ File
Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
Karl
  • 517
  • 7
  • 18

2 Answers2

1

You should not talk abount ACID properties once you made a choice to use document oriented DB such as Mongo. Now, you have answered the question yourself:

" the most reasonable seems to store the average speed in the document as well."

We programmers have the tendency of ignoring the reasonable or simple approaches. We always try to question our selves whenever the solution we find looks obvious or common sense ;-).

Anyways, my suggestion is to store it as you want the sort to be performed by DB and not the application. This means that if any of the variables that influence the average speed change after initial storage then you should remember to update the result field as well.

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
1

My question is regarding average speed. Should I let my app compute the average speed and store that as a field in the document, or should I compute this by only getting time and distance?

As @Panegea rightly said, MongoDB does not rely on ACID properties. It relies on your app being able to control the distributed nature of it self, however that being said calculating the average speed outside of the DB isn't all that bad and using an atomic operator like $set will stop oddities when not using full ACID queries.

What you and @Panegea talk about is a form of pre-aggregation of your needed value to a pre-defined field on the document. This is by far a recommended approach not only in MongoDB but also in SQL (like the total shares on a facebook wall post) where querying for the aggregation of a computed field would be tiresome and very difficult for the server, or just not wise.

Edit

You clould achieve this with the aggregation framework: http://docs.mongodb.org/manual/applications/aggregation/ as well, might wanna take a look there, but pre-aggregation is by far the fastest method.

Sammaye
  • 43,242
  • 7
  • 104
  • 146
  • I am aware of the aggregate frameworks capability to support calculated fields but didn't include it as it is only available in the latest release. – Aravind Yarram Nov 02 '12 at 11:29
  • Thanks for the answers guys. The variables will never change after the document is created. I will let the app populate the fields including average speed since there will be many queries for that field throughout the app. – Karl Nov 03 '12 at 09:44
  • On a side note, there was also another field for the type of vehicle used to create the record. Initially I wanted to simply link to that vehicle's document ID to fetch the type, but considering there will be many queries for sorting based on both vehicle type and average speed it makes more sense to have that value present in the record document as well. Coming from Excel I am used to simplifying the structure as much as possible to minimize errors. But given that the relevant fields are static after creation I will optimize for readability and speed instead. – Karl Nov 03 '12 at 09:45