The current implementation is enabled by setting the geostream.cache to a path on disk where the files are stored. Calls to api.Geostreams.binDatapoints(...) and api.Geostreams.searchDatapoints(...) will use cacheFetch() to retrieve the response from the cache if available or create it, put it in the cache and then return it. The files on disk are stored by hashing the request. Two files are stored on disk under the hash, the response as a json text file (without spaces) and a .json file that includes the actual request as json (for inspection of the raw files). For example:
Here are two example queries from a .json file:
Here is an example of the response:
Current potential issues:
- Lots of files are created on disk
- Files on disk don't seem to include since and until, result in potentially more data being sent to the client
- Admin has to prime the cache (sometimes we forget)
- Move the cache to postgresql.
- Each aggregate datapoint could be a row in a table so that queries could be more specific to a certain range / sensor / stream.
- Keep aggregations (yearly, semi, seasonal, monthly, daily, hourly) in separate tables.
- For example bins_year would include all yearly averages.
- Columns could be (id:int:, sensor:int, stream:int, year:int, data:json, averages:json).
- The data column could store the current total and count for each variable updating running averages.
- The averages column could store the current average. This way returning the actual values will not require any further computation.
- Each new added datapoint triggers updates on the aggregations tables. This will only update one row per table.