[
https://issues.apache.org/jira/browse/HBASE-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566993#comment-13566993
]
Enis Soztutar commented on HBASE-7716:
--------------------------------------
Thanks for feedback.
bq. How do you propose carrying entity information on the Row?
As I imagine, this can be a part of the KV structure. We can either keep just
an int, corresponding to the length of the row group, and use prepend row key
group to the actual row key. Or we can keep that as a separate field in KV.
bq. You imply that this functionality should be necessary for management of
.META.. Can you elaborate? Is there a related ticket?
Collected my thoughts at HBASE-7721.
bq. Is there a way for the user to change their mind about their entity groups?
Say a group grows too large; can I manually split it?
You have to rewrite the data because, key group will be a part of KV. This
would be the main limitation, but let's say you want to do smt like this as in
megastore Entity Groups, ie. in a single row, then you have the same problem of
what if the row grows too big.
bq. Row keys are fully optional, and backwards compatible.
It should have read row key <b>groups</b> are fully optional, and backwards
compatible. Meaning that if you are not using them, nothing changes for you.
bq. FWIW, I think this feature can be emulated today using SplitPolicy
configuration and application-level rowkey prefix management. Perhaps a
demonstration application is in order?
Yes this can be somehow emulated by custom row key prefix + custom region split
policy + custom coprocessors + custom filters. Not a thing an average user can
do, plus you have to do this per table. That is why I am in favor of the native
approach of adding a row group to the data model.
The best example, I think, is local transactions in META: HBASE-7721.
bq. Row groups are not predefined, and are dynamic.
I think I have to reword this. I was thinking row groups as a part of KV, not
dynamic in the sense that you can change the row group of a row on the fly.
They are dynamic in the sense that, you don't have to define them in table
creation time (like column families).
In your example, you would use "com.example.www" as the row group while you are
adding the records.
> Row Groups / Row Family / Entity Groups in HBase
> ------------------------------------------------
>
> Key: HBASE-7716
> URL: https://issues.apache.org/jira/browse/HBASE-7716
> Project: HBase
> Issue Type: New Feature
> Components: Client, regionserver
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 0.98.0
>
> Attachments: Entity Groups in HBase.txt
>
>
> This issue is to discuss the possible addition to the HBase data model for
> "Row Groups".
> As we are nearing 1.0, discussing this for 0.98 seems the right time,
> especially given that we have custom region split policies, local
> transactions, and API overhaul around data types -> bytes.
> Row Groups are semantic groupings of rows in the Hbase data model. All rows
> within a given row group share the same row group key.
> Row groups are similar to column families in HBase or locality groups in
> BigTable, but transposed to rows instead of columns. All the rows within a
> row group physically belong together, and served by a single region. This
> means that region boundaries cannot split the row group.
> Row groups are not predefined, and are dynamic. There can be one row group
> per row.
> Row keys are fully optional, and backwards compatible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
