I guess my thought is that it'd be nice to minimize dependency on ZK, and eventually remove it all together. It just adds too much deployment complexity, and code complexity -- about 10000 lines of code.
I do like the notion of HBase self-hosting it's own performance data, it's what Oracle and other databases do. Ganglia is annoying to install, and often isnt. On Fri, Sep 5, 2014 at 11:10 AM, Michael Segel <michael_se...@hotmail.com> wrote: > @Ted, > > Yes, that’s the general idea or rather a specific use case for what I was > thinking. > So it would be a different mechanism to help manage the information. > I would think that it would result in faster access to the information. > > This would be very important if one were to do some query optimization… and > by using ZK… you could think beyond just HBase, but doing a query to join > data from both HBase and non HBase systems. > > Just a thought… ;-) > > -Mike > > On Sep 5, 2014, at 2:29 AM, Ted Yu <yuzhih...@gmail.com> wrote: > >> This reminds me of >> HBASE-7958 Statistics per-column family per-region >> >> Cheers >> >> >> On Thu, Sep 4, 2014 at 6:23 PM, 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 >>> >
