> Or is this a complete different thinking? Yes.
There isn't an "execution plan" when using HBase, as that term is commonly understood from RDBMS systems. The commands you issue against HBase using the client API are executed in order as you issue them. > Depending on the access pattern, we might be in a situation to use e.g. >RegEx filters on rowkeys. I wonder if there is some kind of an execution >plan when running a HBase query to better understand Exposing filter statistics (hit/skip ratio etc.) and other per-query metrics like number of store files read, how many keys examined, etc. is an interesting idea perhaps along the lines of what you ask, but HBase does not have support for that level of query performance introspection at the moment. What people do is measure the application metrics of interest and try different approaches to optimize them. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) >________________________________ >From: Steinmaurer Thomas <[email protected]> >To: [email protected] >Sent: Tuesday, July 26, 2011 11:10 PM >Subject: Something like Execution Plan as in the RDBMS world? > >Hello, > > > >we have a three part row-key taking into account that the first part is >important for distribution/partitioning when the system grows. Depending >on the access pattern, we might be in a situation to use e.g. RegEx >filters on rowkeys. I wonder if there is some kind of an execution plan >(as known in RDBMS) when running a HBase query to better understand how >HBase processes the query and what execution path it takes to generate >the result set. > > > >Or is this a complete different thinking? > > > >Thanks, > >Thomas > > > > > >
