A useful way to think about Mongo collections is in terms of Who, What, When, Where, Why, and How. Mongo has the following optimizations for different types of data:
Where - GeoJSON
When - ObjectID timestamps
Who - Meteor Account Strings
How - JSON for decision trees
Which leaves the default document in Mongo roughly representing a 'What'.
Auditing Collection Queries
The following example will log all of your collection queries to the server console in realtime.
Creating Records in a Legacy Database
You can default to the normal Mongo format by defining your collections with the idGeneration field.
Filtering with Regexes
Simple pattern for filtering subscriptions on the server, using regexes, reactive session variables, and deps autoruns.
And the HTML that is used on the client:
This pattern itself is pretty straight forward, but the regexes may not be. If you're not familiar with regexes, here are some useful tutorials and links:
Geospatial Collections - Learning More
Geospatial collections generally involve storing GeoJSON in the Mongo database, streaming that data to the client, accessing the browser's
window.navigator.geolocation, loading up a Map API, converting GeoJSON to LatLngs, and plotting on the map. Preferably all in realtime. Here are a list of resources to get you started:
- mongodb optimally stores it's data in geoJSON
- HTML geolocation
- Maps API picker
- Google map.data.loadGeoJson
- 2dsphere indexes
- create a 2dsphere index
- query a 2dsphere index
- geospatial indexes and queries
Getting the _id of the most recently created document
You can get it either synchronously:
Inserting data into a document
Many beginners to Mongo struggle with basics, such as how to insert an array, date, boolean, session variable, and so forth into a document record. This example provides some guidance on basic data inputs.
Observers & Worker Functions
If the Node event loop acts like a bicycle chain, the server-side collection observer is like a derailleur. It's a gearing mechanism that is going to sit on the data collection as the data comes in. It can be very performant, as all race bicycles have derailleurs. But it's also a source for breaking the whole system. It's a high speed reactive function, which can blow up on you. Be warned.
Note the limit of 20 is the size of the derailleur.... how many teeth it has; or, more specifically, how many items are in the cursor as it's walking over the collection. Be careful about using the 'var' keyword in this kind of function. Write as few objects to memory as possibly, and focus on object reuse inside the added method. When the opslog is turned on, and this thing is going full speed, it's a prime candidate for exposing nasty memory leaks if it's writing down objects onto the memory heap faster than the Node garbage collector is able to clean things up.
The above solution won't scale horizontally well, because each Meteor instance will be trying to update the same record. So, some sort of environment detection is necessary for this to scale horizontally.
percolatestudios:synced-cron package for an excellent example of synchronizing service workers across multiple machines in a cluster.
Using MongoDB for time series data is a very well document and established use-case, with official whitepapers and presentations. Read and watch the official documentation from MongoDB before trying to invent your own schemas for time series data.
In general, you'll want to create "buckets" for your timeseries data:
And then increment those buckets as data feeds into your application. This increment can be put in a Meteor Method, a collection observer, a REST API endpoint, and various other places.
For a more complete Meteor example, see the examples from the Clinical Meteor track: