MongoDB documents of calulated values for a dashboard vs re-retrieving on each web page view? -


if have page in web app displays dashboard type statistics documents in database (counts, docs created per hour, per day etc), best pre-calculate data , store in separate document (and update needed), or assuming collections have appropriate indexes, appropriate execute queries retrieve these statistics on every load of page?

it's not necessary data has date on every page hit/load, that's why thinking maintain data need display in separate document can retrieved on page hit (or cached , re-retrieved every 5 minutes or similar).

that's pretty broad, , have feeling have identified key points. speaking, should consider these questions:

  • do need allow users apply filters? complex filters make pre-aggregation impossible.
  • related: exact same data ever queried again? if not, pre-aggregation might need happen on different levels of granularity (e.g. creating day / week / month totals , summing these, instead of individual events).
  • what relation of reads vs. writes on data? if number of writes small, might ok keep counters in real-time, instead of using read-caching.
  • what performance requirements cached , uncached queries? getting fast cached queries trivial, comes @ cost of stale data. making uncached queries faster more tricky , requires multi-level approach discussed before - doesn't if old data comes super fast, new queries take minutes.

caching works if data can't changed later (or seldomly changed), , queries remain same chance of re-occuring. nice example facebook's profiles, past years apparently cached every visitor-profile combination. first accesses slow, however...


Comments

Popular posts from this blog

cakephp - simple blog with croogo -

How to group boxplot outliers in gnuplot -

bash - Performing variable substitution in a string -