phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-652) Use new type system bundled with HBase
Date Fri, 02 May 2014 04:56:14 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Taylor updated PHOENIX-652:
---------------------------------

    Summary: Use new type system bundled with HBase  (was: Use new type system in HBase 0.96)

> Use new type system bundled with HBase
> --------------------------------------
>
>                 Key: PHOENIX-652
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-652
>             Project: Phoenix
>          Issue Type: Task
>            Reporter: James Taylor
>
> A new type system that maintains the row order lexiographically was introduced in HBase
0.96 in [HBase-8089](https://issues.apache.org/jira/browse/HBASE-8089). We should try to have
Phoenix use this type system instead of it's own.
> Couple of open questions:
> * How will performance be affected?
> * Are there gaps in functionality that need to be addressed.
>   * One gap may be in getting the next/previous key of a compound row key (see ByteUtil.nextKey(byte[]
key) and ByteUtil.previousKey(byte[] key)).
> The biggest advantage to switch would be to get better interop with existing products
such as Hive and in general with HBase applications who adopt this type system. In this case,
Phoenix can potentially be used directly against existing HBase data, greatly increasing the
use case for [mapping to an existing HBase table](https://github.com/forcedotcom/phoenix/wiki_mapping-to-an-existing-hbase-table)
> Another advantage would be in simplifying when we have to coerce values "under-the-covers"
since fixed width types do not have a representation for null in the existing type system.
We do this conversion when a GROUP BY is done as well as when an index is created over any
fixed width type (by coercing automatically between INTEGER and DECIMAL, for example). The
new type system has a consistent representation for null, so this would potentially not be
required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message