[
https://issues.apache.org/jira/browse/HBASE-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clint Morgan updated HBASE-883:
-------------------------------
Attachment: hbase-883.patch
Thanks for the review, responded to most of it:
The stuff dealing with RowKeyCompartors is my half-arse attempt at
661. It seems to work but I have not tried it when regions start to
split, which i think is where the issues will arise.
I need RowKeyComparators, because some indexes (those that go in
reverse order, or deserialize the index keys (column values from base
table) to order by EG long values) need to sort non-lexicographically.
This WritableComparator is diff that the one in hadoop. Mine just brings the
two interfaces together, while the hadoop version is a general class
for comparing byte[]s.
Made PerfEval.fomat public
Changed package names to tableindexed
Regards including the index specs in HTD, it made sense to me. I see
the pollution concern, but indexes seem like a fundamental part of the
tables meta-data. I can rework in subsequent patch If need be.
This version has transactional tables/regions inherit from the
indexed tables/regions. This will allow the index updates to have
proper transactional behavior (when updated as part of a transaction).
I've tested this in my object-datastore layer above hbase, and passes some basic
tests. There is a reasonable deal of logic that goes into the
RowKeyGenerator as it must carefully build the index keys to get the
desired ordering. I'm building my index keys prefixed with the same
prefix used in the original keys to maintain "sharding". This
way I can do an quick index scan for data from a give domain (EG, for
a specific customer).
> Secondary Indexes
> -----------------
>
> Key: HBASE-883
> URL: https://issues.apache.org/jira/browse/HBASE-883
> Project: Hadoop HBase
> Issue Type: New Feature
> Components: client, regionserver
> Reporter: Clint Morgan
> Assignee: Clint Morgan
> Attachments: hbase-883.patch, hbase-883.patch
>
>
> I'm working on a secondary index impl. The basic idea is to maintain a
> separate table per index.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
