> We have too many documents per day to materialize in memory, so querying
per day and aggregating the results isn’t really possible.
You don't really need to, that's part of the point. You can paginate
across a partition with most client drivers, and materializing this view is
just copying data
We do get a large number of documents getting counts each day, which is why I’m
thinking the running totals table be ((doc_id), day) rather than ((day),
doc_id). We have too many documents per day to materialize in memory, so
querying per day and aggregating the results isn’t really possible.
I
You're right that there's no way to use the counter data type to
materialize a view ordered by the counter. Computing this post hoc is the
way to go if your needs allow for it (if not, something like Summingbird or
vanilla Storm may be necessary).
I might suggest that you make your primary key fo
