[
https://issues.apache.org/jira/browse/HBASE-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401899#comment-13401899
]
Enis Soztutar commented on HBASE-5612:
--------------------------------------
At the recent HBase hackaton, and the BOF sessions, we had some discussions
about adding some kind of schemas/data types to hbase, and Ian gave a short
talk about it. Other than the use cases for this jira, having optional
schema-data has the advantages of:
- HBase internals can make use of data types (like the block level encoding,
comparators for sub-fields in keys, etc)
- HBase shell can make use of the data types, and display the data correctly
- Hive/Pig can better map their own data-types to hbase types, and their
schemas to hbase schema, instead of managing it themselves.
- Client written coprocessors or system level coprocessors can do data
validation according to the schema and data types.
So, what I am trying to say is that we can start to think of a bigger picture
for the data types, rather than doing something only for compression/block
encoding. WDTY?
> Data types for HBase values
> ---------------------------
>
> Key: HBASE-5612
> URL: https://issues.apache.org/jira/browse/HBASE-5612
> Project: HBase
> Issue Type: Improvement
> Reporter: Mikhail Bautin
> Assignee: Mikhail Bautin
>
> In many real-life applications all values in a certain column family are of a
> certain data type, e.g. 64-bit integer. We could specify that in the column
> descriptor and enable data type-specific compression such as variable-length
> integer encoding.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
