Going for an alternative design now: queries will update only when they're requested. (This means we can accept data at a much higher rate, then aggregate it later on)
This new design will bring in some behaviour changes: we'll count old events, and we need to make sure that we run a query and get valid results before we know that those results are replaced.

The old events behaviour might not be our ultimate goal: it may be more fitting for Regard to only process events from after the point where a query was added (ie, from a point where users have agreed for their data to be processed in this way)
Each org/product should have a separate event data store. This needs to be per-node due to the way AppendValue is supposed to work.
Initial implementation of a version of the query engine that only updates queries when they're actually made (will be somewhat more efficient when users are generating lots of events but results are only being viewed occasionally)
Oops. Really need some classes to manage the structure of the data store. Was writing events to the wrong place again.
Had moved the location of the query results (yep, basically the same problem twice. Some refactoring needed, I feel)
Hm, move to a different store to make it so that deleting results as the result of adding a new query will delete them across all nodes
Need to erase the query status when a query is updated as well