Hmmm. I don’t know. I’d rethink that position.
There are some interesting designs that would suggest that placing it in ZK would offer much better performance. And the amount of data wouldn’t really justify a separate table. I’ll have to check out the JIRA link… Just something to think about. On Sep 5, 2014, at 2:23 AM, Mikhail Antonov <olorinb...@gmail.com> wrote: > I think ZK isn't the best possible storage for statistics. A separate stats > table may be better solution. > > -Mikhail > > > 2014-09-04 15:48 GMT-07:00 Michael Segel <michael_se...@hotmail.com>: > >> So suppose I want to capture metadata about a table across all of the >> regions for that table. >> >> Has anyone used a coprocessor to capture a region’s statistics and push >> them up to ZK where its stored by (table, region, <metadata object>) and >> then a table wide value is also stored based on a computational update? >> >> So if I wanted to store the row counts for each region of a table, each >> region would update its record in ZK on each insert / delete (can you >> easily remove a tombstone?) and then update the computational value? >> (Assuming you could lock those values for a short enough time to do the >> quick computation. If not, then it can be computed on the fly) >> >> Has this been done? >> >> Thoughts? >> >> > > > -- > Thanks, > Michael Antonov
