Good idea. Please file a JIRA. Would be good to quantify the potential gain with and without FAST_DIFF encoding (the default) and/or Snappy compression.
On Sunday, June 14, 2015, yanlin wang <[email protected]> wrote: > Thanks for the reply Anil. > > Is this what you referring: > create view my view as > select a as appColumn1, b as appColum2 from table ? > > By reading the document, seems view will introduce limitations e.g schema > update issue. It would be really good if phoenix put the auto aliasing > column name support in its road map … > > > Thx > Yanlin > > > > > On Jun 14, 2015, at 5:06 PM, anil gupta <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > Hi Yanlin, > > If you are doing reads. You can use a view. > For writes, i dont think Phoenix provides anything for aliasing column > names. It would be good if we have this feature because using short column > names is a common thing in HBase. > > Thanks, > Anil Gupta > > On Sun, Jun 14, 2015 at 12:19 PM, yanlin wang <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi, >> >> Usually one method to reduce IO in hbase is to reduce the size of column >> qualifier’s length and use a dictionary to map the application column name >> to the actual column qualifier. Kiji schema project is doing exactly that. >> Is there any column name encoding support in Phoenix? if no, any plan to do >> that? Another option is that we can create phoenix table on top of kiji >> table, but kiji has its own column serializer which is based on avro and >> the Phoenix client needs to be modified to do the custom deserialization >> and mapping etc. The last resort will be putting these column name mapping >> biz into application DAO layer. Do you have any suggestion? >> >> Thx, >> Yanlin > > > > > -- > Thanks & Regards, > Anil Gupta > > >
