After having implemented a redis-based cache for the measure data, I am kind of feeling like storing (caching) the measure data in a db (with one row per measure) is a better idea:
We can restrict what we fetch to only within the interval we're interested in at the SQL level, instead of having to fetch a gigantic blob and filter it
Faster writes (no need to recreate an entire blob filled with data every time we update)
Can take advantage of the Django ORM, which helps eliminate common mistakes
Below is a tentative schema. I'm not sure if we want to do this right away, or after we've implemented more of the front end. The latter may make more sense, though I think this design should scale to all the things we've discussed doing.
--
tentative schema:
OS
name (string)
Channel
name (string)
Measure
name (string)
(OS/Channel/Measure will probably be loaded from fixtures, at least initially)
Series
os (fk)
channel (fk)
measure (fk)
(at some point in the future, we might want to add arbitrary "dimensions" to the series, so we can also aggregate filtered versions of specific series-- but for now, YAGNI)
After having implemented a redis-based cache for the measure data, I am kind of feeling like storing (caching) the measure data in a db (with one row per measure) is a better idea:
Below is a tentative schema. I'm not sure if we want to do this right away, or after we've implemented more of the front end. The latter may make more sense, though I think this design should scale to all the things we've discussed doing.
--
tentative schema:
OS
Channel
Measure
(OS/Channel/Measure will probably be loaded from fixtures, at least initially)
Series
(at some point in the future, we might want to add arbitrary "dimensions" to the series, so we can also aggregate filtered versions of specific series-- but for now, YAGNI)
Version
Datum