hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Groschupf ...@media-style.com>
Subject Re: HBase Design Ideas, Part II
Date Tue, 30 May 2006 20:33:11 GMT
Hi Michael,

> However, BigTable still leaves some things on the table.  Items to
> improve include a query language and multi-row locking, among
> other things.

In my project we do not need to have multi row locking at all. I need  
to write and read as fast as possible into many rows - column pairs  
but each of them is atomically.
I'm little bit worry that the goals are to big for now and having  
such difficult to implement functionality will slow down a general  
hadoop kind of big table implementation.
I really would love to start small and grow may be later with each  

> Also, how useful do you think a general-purpose query language
> would be for HBase?  It would be fairly straightforward to implement,
> for example, a poor man's version of SQL that has different locking
> and update behavior (and which chucks out the more exotic elements).
> This might be compiled into a piece of code that is executed
> immediately, or it might be transformed into a long-lasting mapreduce
> job.

I personal don't like query languages at all - especially sql. :-)
They are only really usefully if you work on a admin gui tool and  
want to check your data, from my point of view.
Since some years I really prefer api based query mechanisms as   
hibernate or db4o provide.
For example query by example is just easy to use and can be powerful.

A query is any time a string in your code you need to maintain  
queries separately. You need to scan and update your code as soon  
your change just one column name etc.
But having a API based Query mechanism allows to develop faster from  
my experience. Keywords in my mind are  test driven development,  
refactoring, refactoring tools like eclipse etc.

Just my 2  cents. :-)
However I would love to see a big table.

View raw message