Hi Kristoffer, Yes, you're correct - for a non aggregate, non join query, the underlying result set is backed by the bloated HBase Result and KeyValue/Cell. See PHOENIX-1489 - maybe we can continue the discussion there? Your comments here would be valuable over there too. Thanks, James
On Wed, Dec 17, 2014 at 2:43 PM, Kristoffer Sjögren <sto...@gmail.com> wrote: > Correct me if i'm wrong here but it seems that columns not part of the > primary key are stored as a column qualifiers. And each key value in HBase > store both the qualifier name and the value. So both qualifier name and > value are transferred from region server to client, for all column values > and rows. > > This is especially bad for some of our tables which have 2-3 column keys and > 20-25 column values. And the problem gets worse when column value names > sometimes are 20-30 characters long. > > Any suggestions on how to reduce this overhead? > > Cheers, > -Kristoffer > > > > > On Wed, Dec 17, 2014 at 4:51 PM, Kristoffer Sjögren <sto...@gmail.com> > wrote: >> >> Hi >> >> I have done some tracing and it seems like _each_ 'select' result contain >> (redundant?) column names? This cause a lot of overhead when having >> descriptive column names. Especially when values in these columns are very >> small. >> >> Is this correct? Is it possible to make result sets less chatty? >> >> Cheers, >> -Kristoffer >> >
