Configurable comparators per-CF?

[Jeff Hammerbacher <ha...@cloudera.com>]

Hey,

In Hadoop, it's possible to override how two keys are compared with
WritableComparable (
http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/io/WritableComparator.html),
and the same thing is possible in Cassandra with CompareWith (
http://wiki.apache.org/cassandra/StorageConfiguration).

Would it be possible to do something similar for the unit of sorting in
HBase, the ColumnFamily?

Thanks,
Jeff

RE: Configurable comparators per-CF?

[Jonathan Gray <jg...@facebook.com>]

@Jeff, do you have specific use cases in mind?

I generally agree with Stack that with proper schema design you can do most things with the default ordering.

I would say a custom row comparator would be possible but probably overly complex.  The one thing that might make it simpler is if we eventually do make a move to ZK or something else to store META rather than as a special table in which case mixing row comparators on a single cluster may be easier.

Custom comparators per family is certainly possible but would require some rejiggering.  There have definitely been times where I would have used a reverse comparator if it was available but in every case I was able to effectively do the same thing.  The most obvious one is wanting descending numbers but I've always used Long.MAX_VALUE minus value.

JG

> -----Original Message-----
> From: saint.ack@gmail.com [mailto:saint.ack@gmail.com] On Behalf Of
> Stack
> Sent: Friday, June 18, 2010 1:46 PM
> To: user@hbase.apache.org
> Subject: Re: Configurable comparators per-CF?
> 
> On Fri, Jun 18, 2010 at 11:43 AM, Jeff Hammerbacher
> <ha...@cloudera.com> wrote:
> > In Hadoop, it's possible to override how two keys are compared with
> > WritableComparable (
> >
> http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/io/W
> ritableComparator.html),
> > and the same thing is possible in Cassandra with CompareWith (
> > http://wiki.apache.org/cassandra/StorageConfiguration).
> >
> > Would it be possible to do something similar for the unit of sorting
> in
> > HBase, the ColumnFamily?
> >
> 
> I think you are asking about row sort but you might be asking about
> sort of columns inside a row.  Let me do the former first.
> 
> Regards key order, the answer is no, not w/o introducing a raft of
> complexity.
> 
> All tables hosted by the cluster are sorted on their row key.  Tables
> are made of regions.
> 
> All cluster regions are listed in the catalog .META. table.  This
> table is like any other, also sorted.   Its key is effectively
> tablename+startkey-for-the-region.
> 
> As is, all is straight-forward when all use the same comparator.
> Hunting the region that hosts a particular row is just a case of
> comparing the sought-after key against the content of the catalog
> table.  The client knows implicitly what comparator to use.
> 
> If we let each tablle have its own comparator, then client needs to
> get metadata on each table, the comparator to use when looking for
> rows inside the table, including the comparator to use when searching
> the meta catalog table; only the comparator we used in the catalog
> table would be a bit odd in that it would be a compound of a
> comparator that first orders entries by tables and then, ordering the
> region entries of a particular table in meta, it would need to use
> that tables comparator ordering its rows.
> 
> Client doing lookups would need to be up-to-date on the metadata and
> would also need to work the compound comparator to find host regions.
> 
> I suppose the above could be done if it were wanted.
> 
> Now, if you add into the mix a comparator per column family, scanning
> a table, as we do now, you'd open a scanner per column family, only
> now each scanner has its own comparator.  Lets take the case where one
> CF's comparator sorts lexicographically from smallest to largest but
> then the next column familly's comparator sorts in reverse.   A scan
> that is to return all the content of a particular row -- i.e. across
> all CFs --  is going go seek itself into the ground (I'd imagine).
> Which comparator would we use ordering the rows in the table (for
> smallest-to-largest comparator or the reverse-order comparator or
> something else?)
> 
> On sort of columns within a row, which seems to be what the cassandra
> citation is about  -- the partitioner determines row placement on the
> cluster (is this a per-keyspace setting or one-time setting for the
> cluster, I can't tell) -- then this looks like a feature we might want
> to pick up, though, it seems like most of these comparisons can be
> achieved through appropriate schema design (and we already have
> sorting by timestamp).
> 
> St.Ack

Re: Configurable comparators per-CF?

[Stack <st...@duboce.net>]

On Fri, Jun 18, 2010 at 11:43 AM, Jeff Hammerbacher <ha...@cloudera.com> wrote:
> In Hadoop, it's possible to override how two keys are compared with
> WritableComparable (
> http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/io/WritableComparator.html),
> and the same thing is possible in Cassandra with CompareWith (
> http://wiki.apache.org/cassandra/StorageConfiguration).
>
> Would it be possible to do something similar for the unit of sorting in
> HBase, the ColumnFamily?
>

I think you are asking about row sort but you might be asking about
sort of columns inside a row.  Let me do the former first.

Regards key order, the answer is no, not w/o introducing a raft of complexity.

All tables hosted by the cluster are sorted on their row key.  Tables
are made of regions.

All cluster regions are listed in the catalog .META. table.  This
table is like any other, also sorted.   Its key is effectively
tablename+startkey-for-the-region.

As is, all is straight-forward when all use the same comparator.
Hunting the region that hosts a particular row is just a case of
comparing the sought-after key against the content of the catalog
table.  The client knows implicitly what comparator to use.

If we let each tablle have its own comparator, then client needs to
get metadata on each table, the comparator to use when looking for
rows inside the table, including the comparator to use when searching
the meta catalog table; only the comparator we used in the catalog
table would be a bit odd in that it would be a compound of a
comparator that first orders entries by tables and then, ordering the
region entries of a particular table in meta, it would need to use
that tables comparator ordering its rows.

Client doing lookups would need to be up-to-date on the metadata and
would also need to work the compound comparator to find host regions.

I suppose the above could be done if it were wanted.

Now, if you add into the mix a comparator per column family, scanning
a table, as we do now, you'd open a scanner per column family, only
now each scanner has its own comparator.  Lets take the case where one
CF's comparator sorts lexicographically from smallest to largest but
then the next column familly's comparator sorts in reverse.   A scan
that is to return all the content of a particular row -- i.e. across
all CFs --  is going go seek itself into the ground (I'd imagine).
Which comparator would we use ordering the rows in the table (for
smallest-to-largest comparator or the reverse-order comparator or
something else?)

On sort of columns within a row, which seems to be what the cassandra
citation is about  -- the partitioner determines row placement on the
cluster (is this a per-keyspace setting or one-time setting for the
cluster, I can't tell) -- then this looks like a feature we might want
to pick up, though, it seems like most of these comparisons can be
achieved through appropriate schema design (and we already have
sorting by timestamp).

St.Ack