You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Paul Ambrose <pa...@mac.com> on 2010/01/05 21:49:20 UTC
[Announce] HBql
Hi,
I have been working on an abstraction layer for HBase that I hope
HBase users will find helpful.
Highlights include:
* A dialect of SQL for HBase (usable in the console, scripts, and code)
* JDBC bindings
* JDBC-like bindings that support annotated objects and generics
* Query Executors that make threaded result reading simple
* Simplified filter writing for server and/or client
* Index support
HBql is a work in progress and I am open to feedback and suggestions.
I am still working on the docs, so the examples and javadocs are pretty lame.
Have a look at: http://www.hbql.com
Cheers,
Paul
Re: [Announce] HBql
Posted by Ken Yang <ba...@gmail.com>.
Hi Paul,
I was wondering what has done "under the covers", or, how to you set
[startKey, endKey] for a Scan object. Please explain more, thanks a lot.
As a comparation, the Map-Reduce support for hBase will split a whole table
scan to several sub-tasks, each task handles a region. You can check this
implementation from hbase source codes, package
org.apache.hadoop.hbase.mapreduce
The advantage of Map-Reduce is, the task can run in more machines. And I
think it is the critical to scale out.
On Wed, Jan 6, 2010 at 1:52 PM, Paul Ambrose <pa...@mac.com> wrote:
> You create a Query Executor and assign it to a connection.
> Subsequent queries on that connection will use the query executor such that
> each key or key range of a query will be executed in the thread pool
> of the executor (as a Get or Scan under the covers). So if you create
> a query executor with 20 threads and perform a query with 1000 keys,
> HBql will execute 20 HBase gets at a time (1000 times) and return the
> results accordingly. The allocation of the gets and scans to the executor
> thread pool is done under the covers. The user simply assigns the
> executor,
> issues the query, and iterates through the results.
>
> HBql does not presently expose async queries in the client API. It is
> async
> under the covers, so surfacing it would not be hard. I think async results
> would
> be nice, so I will add it to the list.
>
> HBql also does not leverage Map-Reduce. I am all ears on suggestions.
>
> Cheers,
> Paul
>
>
> On Jan 5, 2010, at 9:27 PM, Ken Yang wrote:
>
> > Thanks, Paul.
> >
> > But about the Query Executor in HBql, I just found limited info from
> > http://www.hbql.com/statements/create-executor-pool.html
> > And I'm not sure how does it finish a scan, I mean, how does each thread
> get
> > a [startKey, endKey]?
> > Highly appreciated if there're more docs about the details :)
> >
> > And, about the operations need whole table scan, is there
> > 1) asynchronous operations supported?
> > 2) Map-Reduce leveraged?
> >
> >
> > Best Regards
> > Ken Yang [Yang ZhiYong]
> >
> > On Wed, Jan 6, 2010 at 12:58 PM, Paul Ambrose <pa...@mac.com> wrote:
> >
> >> Thanks Ken.
> >>
> >> The laws of HBase physics still apply. If you execute a single scan
> >> on all the rows of a table, it is likely to be expensive. HBql allows
> you
> >> to easily fire off N concurrent queries (as a series of N contiguous key
> >> ranges in HBql)
> >> which might give better performance. You can configure a Query
> Executor
> >> in HBql to have the appropriate number of threads. I know very little
> >> about HBase
> >> internals, so I am not sure what the expected improvement of such
> >> concurrency might be.
> >>
> >> Cheers,
> >> Paul
> >>
> >>
> >> On Jan 5, 2010, at 7:24 PM, Ken Yang wrote:
> >>
> >>> Hi Paul,
> >>>
> >>> Very impressive Job!
> >>> And I have a question, how do you handle a query which need to scan a
> >> whole
> >>> table? e.g. query on a Non-indexed column.
> >>>
> >>> Will the operation cost too much time?
> >>>
> >>>
> >>> On Wed, Jan 6, 2010 at 4:49 AM, Paul Ambrose <pa...@mac.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have been working on an abstraction layer for HBase that I hope
> >>>> HBase users will find helpful.
> >>>>
> >>>> Highlights include:
> >>>> * A dialect of SQL for HBase (usable in the console, scripts, and
> code)
> >>>> * JDBC bindings
> >>>> * JDBC-like bindings that support annotated objects and generics
> >>>> * Query Executors that make threaded result reading simple
> >>>> * Simplified filter writing for server and/or client
> >>>> * Index support
> >>>>
> >>>> HBql is a work in progress and I am open to feedback and suggestions.
> >>>> I am still working on the docs, so the examples and javadocs are
> pretty
> >>>> lame.
> >>>>
> >>>> Have a look at: http://www.hbql.com
> >>>>
> >>>> Cheers,
> >>>> Paul
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards
> >>> Ken Yang [Yang ZhiYong]
> >>
> >>
> >
> >
> > --
> > Best Regards
> > Ken Yang [Yang ZhiYong]
>
>
--
Best Regards
Ken Yang [Yang ZhiYong]
Re: [Announce] HBql
Posted by Paul Ambrose <pa...@mac.com>.
You create a Query Executor and assign it to a connection.
Subsequent queries on that connection will use the query executor such that
each key or key range of a query will be executed in the thread pool
of the executor (as a Get or Scan under the covers). So if you create
a query executor with 20 threads and perform a query with 1000 keys,
HBql will execute 20 HBase gets at a time (1000 times) and return the
results accordingly. The allocation of the gets and scans to the executor
thread pool is done under the covers. The user simply assigns the executor,
issues the query, and iterates through the results.
HBql does not presently expose async queries in the client API. It is async
under the covers, so surfacing it would not be hard. I think async results would
be nice, so I will add it to the list.
HBql also does not leverage Map-Reduce. I am all ears on suggestions.
Cheers,
Paul
On Jan 5, 2010, at 9:27 PM, Ken Yang wrote:
> Thanks, Paul.
>
> But about the Query Executor in HBql, I just found limited info from
> http://www.hbql.com/statements/create-executor-pool.html
> And I'm not sure how does it finish a scan, I mean, how does each thread get
> a [startKey, endKey]?
> Highly appreciated if there're more docs about the details :)
>
> And, about the operations need whole table scan, is there
> 1) asynchronous operations supported?
> 2) Map-Reduce leveraged?
>
>
> Best Regards
> Ken Yang [Yang ZhiYong]
>
> On Wed, Jan 6, 2010 at 12:58 PM, Paul Ambrose <pa...@mac.com> wrote:
>
>> Thanks Ken.
>>
>> The laws of HBase physics still apply. If you execute a single scan
>> on all the rows of a table, it is likely to be expensive. HBql allows you
>> to easily fire off N concurrent queries (as a series of N contiguous key
>> ranges in HBql)
>> which might give better performance. You can configure a Query Executor
>> in HBql to have the appropriate number of threads. I know very little
>> about HBase
>> internals, so I am not sure what the expected improvement of such
>> concurrency might be.
>>
>> Cheers,
>> Paul
>>
>>
>> On Jan 5, 2010, at 7:24 PM, Ken Yang wrote:
>>
>>> Hi Paul,
>>>
>>> Very impressive Job!
>>> And I have a question, how do you handle a query which need to scan a
>> whole
>>> table? e.g. query on a Non-indexed column.
>>>
>>> Will the operation cost too much time?
>>>
>>>
>>> On Wed, Jan 6, 2010 at 4:49 AM, Paul Ambrose <pa...@mac.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have been working on an abstraction layer for HBase that I hope
>>>> HBase users will find helpful.
>>>>
>>>> Highlights include:
>>>> * A dialect of SQL for HBase (usable in the console, scripts, and code)
>>>> * JDBC bindings
>>>> * JDBC-like bindings that support annotated objects and generics
>>>> * Query Executors that make threaded result reading simple
>>>> * Simplified filter writing for server and/or client
>>>> * Index support
>>>>
>>>> HBql is a work in progress and I am open to feedback and suggestions.
>>>> I am still working on the docs, so the examples and javadocs are pretty
>>>> lame.
>>>>
>>>> Have a look at: http://www.hbql.com
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Ken Yang [Yang ZhiYong]
>>
>>
>
>
> --
> Best Regards
> Ken Yang [Yang ZhiYong]
Re: [Announce] HBql
Posted by Ken Yang <ba...@gmail.com>.
Thanks, Paul.
But about the Query Executor in HBql, I just found limited info from
http://www.hbql.com/statements/create-executor-pool.html
And I'm not sure how does it finish a scan, I mean, how does each thread get
a [startKey, endKey]?
Highly appreciated if there're more docs about the details :)
And, about the operations need whole table scan, is there
1) asynchronous operations supported?
2) Map-Reduce leveraged?
Best Regards
Ken Yang [Yang ZhiYong]
On Wed, Jan 6, 2010 at 12:58 PM, Paul Ambrose <pa...@mac.com> wrote:
> Thanks Ken.
>
> The laws of HBase physics still apply. If you execute a single scan
> on all the rows of a table, it is likely to be expensive. HBql allows you
> to easily fire off N concurrent queries (as a series of N contiguous key
> ranges in HBql)
> which might give better performance. You can configure a Query Executor
> in HBql to have the appropriate number of threads. I know very little
> about HBase
> internals, so I am not sure what the expected improvement of such
> concurrency might be.
>
> Cheers,
> Paul
>
>
> On Jan 5, 2010, at 7:24 PM, Ken Yang wrote:
>
> > Hi Paul,
> >
> > Very impressive Job!
> > And I have a question, how do you handle a query which need to scan a
> whole
> > table? e.g. query on a Non-indexed column.
> >
> > Will the operation cost too much time?
> >
> >
> > On Wed, Jan 6, 2010 at 4:49 AM, Paul Ambrose <pa...@mac.com> wrote:
> >
> >> Hi,
> >>
> >> I have been working on an abstraction layer for HBase that I hope
> >> HBase users will find helpful.
> >>
> >> Highlights include:
> >> * A dialect of SQL for HBase (usable in the console, scripts, and code)
> >> * JDBC bindings
> >> * JDBC-like bindings that support annotated objects and generics
> >> * Query Executors that make threaded result reading simple
> >> * Simplified filter writing for server and/or client
> >> * Index support
> >>
> >> HBql is a work in progress and I am open to feedback and suggestions.
> >> I am still working on the docs, so the examples and javadocs are pretty
> >> lame.
> >>
> >> Have a look at: http://www.hbql.com
> >>
> >> Cheers,
> >> Paul
> >>
> >
> >
> >
> > --
> > Best Regards
> > Ken Yang [Yang ZhiYong]
>
>
--
Best Regards
Ken Yang [Yang ZhiYong]
Re: [Announce] HBql
Posted by Paul Ambrose <pa...@mac.com>.
Thanks Ken.
The laws of HBase physics still apply. If you execute a single scan
on all the rows of a table, it is likely to be expensive. HBql allows you
to easily fire off N concurrent queries (as a series of N contiguous key ranges in HBql)
which might give better performance. You can configure a Query Executor
in HBql to have the appropriate number of threads. I know very little about HBase
internals, so I am not sure what the expected improvement of such concurrency might be.
Cheers,
Paul
On Jan 5, 2010, at 7:24 PM, Ken Yang wrote:
> Hi Paul,
>
> Very impressive Job!
> And I have a question, how do you handle a query which need to scan a whole
> table? e.g. query on a Non-indexed column.
>
> Will the operation cost too much time?
>
>
> On Wed, Jan 6, 2010 at 4:49 AM, Paul Ambrose <pa...@mac.com> wrote:
>
>> Hi,
>>
>> I have been working on an abstraction layer for HBase that I hope
>> HBase users will find helpful.
>>
>> Highlights include:
>> * A dialect of SQL for HBase (usable in the console, scripts, and code)
>> * JDBC bindings
>> * JDBC-like bindings that support annotated objects and generics
>> * Query Executors that make threaded result reading simple
>> * Simplified filter writing for server and/or client
>> * Index support
>>
>> HBql is a work in progress and I am open to feedback and suggestions.
>> I am still working on the docs, so the examples and javadocs are pretty
>> lame.
>>
>> Have a look at: http://www.hbql.com
>>
>> Cheers,
>> Paul
>>
>
>
>
> --
> Best Regards
> Ken Yang [Yang ZhiYong]
Re: [Announce] HBql
Posted by Ken Yang <ba...@gmail.com>.
Hi Paul,
Very impressive Job!
And I have a question, how do you handle a query which need to scan a whole
table? e.g. query on a Non-indexed column.
Will the operation cost too much time?
On Wed, Jan 6, 2010 at 4:49 AM, Paul Ambrose <pa...@mac.com> wrote:
> Hi,
>
> I have been working on an abstraction layer for HBase that I hope
> HBase users will find helpful.
>
> Highlights include:
> * A dialect of SQL for HBase (usable in the console, scripts, and code)
> * JDBC bindings
> * JDBC-like bindings that support annotated objects and generics
> * Query Executors that make threaded result reading simple
> * Simplified filter writing for server and/or client
> * Index support
>
> HBql is a work in progress and I am open to feedback and suggestions.
> I am still working on the docs, so the examples and javadocs are pretty
> lame.
>
> Have a look at: http://www.hbql.com
>
> Cheers,
> Paul
>
--
Best Regards
Ken Yang [Yang ZhiYong]
Re: [Announce] HBql
Posted by Paul Ambrose <pa...@mac.com>.
On Jan 5, 2010, at 1:39 PM, Wim Van Leuven wrote:
> Hello Paul,
>
> Looks very interesting. One consideration, though, regarding annotated
> objects: wouldn't it be enormously interesting to (try to) reuse the JPA
> annotations?
>
Yes, I think JPA support would be cool. I have discussed it with
Patrick Linskey and he thinks we should be able to do it as a plugin
to OpenJPA.
My only fear is how much of the HBase goodness has to be set aside in
order to for it to work in the context of JPA. The HBql annotations (and mappings)
address things like unmapped columns and versioning, which are not part of JPA.
> Another very interesting aspect on easing HBase development would be some
> nifty support for necessary facets or satellites (looking for some good term
> coining here). By facets/satellites I mean the fact that some data needs
> denormalization for sake of performance. Updating the annotated source
> record should also update its facets/satellites spread across other tables.
>
> Just an idea.
>
> -----Original Message-----
> From: Paul Ambrose [mailto:pambrose@mac.com]
> Sent: dinsdag 5 januari 2010 21:49
> To: hbase-user@hadoop.apache.org
> Subject: [Announce] HBql
>
> Hi,
>
> I have been working on an abstraction layer for HBase that I hope
> HBase users will find helpful.
>
> Highlights include:
> * A dialect of SQL for HBase (usable in the console, scripts, and code)
> * JDBC bindings
> * JDBC-like bindings that support annotated objects and generics
> * Query Executors that make threaded result reading simple
> * Simplified filter writing for server and/or client
> * Index support
>
> HBql is a work in progress and I am open to feedback and suggestions.
> I am still working on the docs, so the examples and javadocs are pretty
> lame.
>
> Have a look at: http://www.hbql.com
>
> Cheers,
> Paul
>
RE: [Announce] HBql
Posted by Wim Van Leuven <wi...@highestpoint.biz>.
Hello Paul,
Looks very interesting. One consideration, though, regarding annotated
objects: wouldn't it be enormously interesting to (try to) reuse the JPA
annotations?
Another very interesting aspect on easing HBase development would be some
nifty support for necessary facets or satellites (looking for some good term
coining here). By facets/satellites I mean the fact that some data needs
denormalization for sake of performance. Updating the annotated source
record should also update its facets/satellites spread across other tables.
Just an idea.
-----Original Message-----
From: Paul Ambrose [mailto:pambrose@mac.com]
Sent: dinsdag 5 januari 2010 21:49
To: hbase-user@hadoop.apache.org
Subject: [Announce] HBql
Hi,
I have been working on an abstraction layer for HBase that I hope
HBase users will find helpful.
Highlights include:
* A dialect of SQL for HBase (usable in the console, scripts, and code)
* JDBC bindings
* JDBC-like bindings that support annotated objects and generics
* Query Executors that make threaded result reading simple
* Simplified filter writing for server and/or client
* Index support
HBql is a work in progress and I am open to feedback and suggestions.
I am still working on the docs, so the examples and javadocs are pretty
lame.
Have a look at: http://www.hbql.com
Cheers,
Paul
Re: [Announce] HBql
Posted by John Martyniak <jo...@beforedawnsolutions.com>.
This is awesome!
Good work
-John
On Jan 5, 2010, at 3:49 PM, Paul Ambrose <pa...@mac.com> wrote:
> Hi,
>
> I have been working on an abstraction layer for HBase that I hope
> HBase users will find helpful.
>
> Highlights include:
> * A dialect of SQL for HBase (usable in the console, scripts, and
> code)
> * JDBC bindings
> * JDBC-like bindings that support annotated objects and generics
> * Query Executors that make threaded result reading simple
> * Simplified filter writing for server and/or client
> * Index support
>
> HBql is a work in progress and I am open to feedback and suggestions.
> I am still working on the docs, so the examples and javadocs are
> pretty lame.
>
> Have a look at: http://www.hbql.com
>
> Cheers,
> Paul
Re: [Announce] HBql
Posted by Paul Ambrose <pa...@mac.com>.
On Jan 5, 2010, at 2:08 PM, Gibbon, Robert, VF-Group wrote:
> Woaaa this looks awesome! Questions follow
>
Thanks.
> * CREATE INDEX - works with vanilla Hbase or needs Transactional Hbase? Builds indexes as hbase tables? update triggers/scheduled rebuild of the indexes too?
I am simply calling the existing hbase index support: http://tinyurl.com/yanfslo
Note that using indexes requires some enabling
(as described in the above link and here: http://www.hbql.com/installation.html).
>
> * Query plans and optimization are now managed by HBQL? User doesn't have to worry about that?
>
The queries are still Gets and Scans (as determined by the KEYS clause of the query) and
the server and client filters are executed as either a SingleColumnValueFilter or
as an HBql RecordFilter (depending on the complexity of the expression).
To be clear, I am not looking at the query and seeing if any indexes apply and then
optimizing the query accordingly. This is still baby steps time... :-)
Cheers,
Paul
> THANKS FOR MAKING THIS YOU STAR
>
> R
>
> -----Original Message-----
> From: Paul Ambrose [mailto:pambrose@mac.com]
> Sent: Tue 1/5/2010 9:49 PM
> To: hbase-user@hadoop.apache.org
> Subject: [Announce] HBql
>
> Hi,
>
> I have been working on an abstraction layer for HBase that I hope
> HBase users will find helpful.
>
> Highlights include:
> * A dialect of SQL for HBase (usable in the console, scripts, and code)
> * JDBC bindings
> * JDBC-like bindings that support annotated objects and generics
> * Query Executors that make threaded result reading simple
> * Simplified filter writing for server and/or client
> * Index support
>
> HBql is a work in progress and I am open to feedback and suggestions.
> I am still working on the docs, so the examples and javadocs are pretty lame.
>
> Have a look at: http://www.hbql.com
>
> Cheers,
> Paul
>
RE: [Announce] HBql
Posted by "Gibbon, Robert, VF-Group" <Ro...@vodafone.com>.
Woaaa this looks awesome! Questions follow
* CREATE INDEX - works with vanilla Hbase or needs Transactional Hbase? Builds indexes as hbase tables? update triggers/scheduled rebuild of the indexes too?
* Query plans and optimization are now managed by HBQL? User doesn't have to worry about that?
THANKS FOR MAKING THIS YOU STAR
R
-----Original Message-----
From: Paul Ambrose [mailto:pambrose@mac.com]
Sent: Tue 1/5/2010 9:49 PM
To: hbase-user@hadoop.apache.org
Subject: [Announce] HBql
Hi,
I have been working on an abstraction layer for HBase that I hope
HBase users will find helpful.
Highlights include:
* A dialect of SQL for HBase (usable in the console, scripts, and code)
* JDBC bindings
* JDBC-like bindings that support annotated objects and generics
* Query Executors that make threaded result reading simple
* Simplified filter writing for server and/or client
* Index support
HBql is a work in progress and I am open to feedback and suggestions.
I am still working on the docs, so the examples and javadocs are pretty lame.
Have a look at: http://www.hbql.com
Cheers,
Paul
Re: [Announce] HBql
Posted by Stack <sa...@gmail.com>.
Excellent Paul! Be sure to add to supporting projects up on the wiki
Stack
On Jan 5, 2010, at 12:49 PM, Paul Ambrose <pa...@mac.com> wrote:
> Hi,
>
> I have been working on an abstraction layer for HBase that I hope
> HBase users will find helpful.
>
> Highlights include:
> * A dialect of SQL for HBase (usable in the console, scripts, and
> code)
> * JDBC bindings
> * JDBC-like bindings that support annotated objects and generics
> * Query Executors that make threaded result reading simple
> * Simplified filter writing for server and/or client
> * Index support
>
> HBql is a work in progress and I am open to feedback and suggestions.
> I am still working on the docs, so the examples and javadocs are
> pretty lame.
>
> Have a look at: http://www.hbql.com
>
> Cheers,
> Paul
RE: [Announce] HBql
Posted by Wim Van Leuven <wi...@highestpoint.biz>.
Ah ... yes. That's the tech also included in Google App Engine. I'm in the
process of looking into this on GAE.
-----Original Message-----
From: Fernando Padilla [mailto:fern@alum.mit.edu]
Sent: woensdag 6 januari 2010 1:40
To: hbase-user@hadoop.apache.org
Subject: Re: [Announce] HBql
I haven't used it myself, but doesn't DataNucleus have an HBase
adapter? (they support both JPA and JDO apis)
http://www.datanucleus.org/products/accessplatform_1_1/plugins/store.hbase.h
tml
On 1/5/10 1:44 PM, Leen Toelen wrote:
> Hi,
>
> I also think re-using JPA and the JP Quer Language is a great idea.
>
> Regards,
> Leen
>
> On Tue, Jan 5, 2010 at 10:39 PM, Wim Van Leuven<
> wim.vanleuven@highestpoint.biz> wrote:
>
>
>> Hello Paul,
>>
>> Looks very interesting. One consideration, though, regarding annotated
>> objects: wouldn't it be enormously interesting to (try to) reuse the JPA
>> annotations?
>>
>> Another very interesting aspect on easing HBase development would be some
>> nifty support for necessary facets or satellites (looking for some good
>> term
>> coining here). By facets/satellites I mean the fact that some data needs
>> denormalization for sake of performance. Updating the annotated source
>> record should also update its facets/satellites spread across other
tables.
>>
>> Just an idea.
>>
>> -----Original Message-----
>> From: Paul Ambrose [mailto:pambrose@mac.com]
>> Sent: dinsdag 5 januari 2010 21:49
>> To: hbase-user@hadoop.apache.org
>> Subject: [Announce] HBql
>>
>> Hi,
>>
>> I have been working on an abstraction layer for HBase that I hope
>> HBase users will find helpful.
>>
>> Highlights include:
>> * A dialect of SQL for HBase (usable in the console, scripts, and code)
>> * JDBC bindings
>> * JDBC-like bindings that support annotated objects and generics
>> * Query Executors that make threaded result reading simple
>> * Simplified filter writing for server and/or client
>> * Index support
>>
>> HBql is a work in progress and I am open to feedback and suggestions.
>> I am still working on the docs, so the examples and javadocs are pretty
>> lame.
>>
>> Have a look at: http://www.hbql.com
>>
>> Cheers,
>> Paul
>>
>>
>>
>
Re: [Announce] HBql
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I haven't used it myself, but doesn't DataNucleus have an HBase
adapter? (they support both JPA and JDO apis)
http://www.datanucleus.org/products/accessplatform_1_1/plugins/store.hbase.html
On 1/5/10 1:44 PM, Leen Toelen wrote:
> Hi,
>
> I also think re-using JPA and the JP Quer Language is a great idea.
>
> Regards,
> Leen
>
> On Tue, Jan 5, 2010 at 10:39 PM, Wim Van Leuven<
> wim.vanleuven@highestpoint.biz> wrote:
>
>
>> Hello Paul,
>>
>> Looks very interesting. One consideration, though, regarding annotated
>> objects: wouldn't it be enormously interesting to (try to) reuse the JPA
>> annotations?
>>
>> Another very interesting aspect on easing HBase development would be some
>> nifty support for necessary facets or satellites (looking for some good
>> term
>> coining here). By facets/satellites I mean the fact that some data needs
>> denormalization for sake of performance. Updating the annotated source
>> record should also update its facets/satellites spread across other tables.
>>
>> Just an idea.
>>
>> -----Original Message-----
>> From: Paul Ambrose [mailto:pambrose@mac.com]
>> Sent: dinsdag 5 januari 2010 21:49
>> To: hbase-user@hadoop.apache.org
>> Subject: [Announce] HBql
>>
>> Hi,
>>
>> I have been working on an abstraction layer for HBase that I hope
>> HBase users will find helpful.
>>
>> Highlights include:
>> * A dialect of SQL for HBase (usable in the console, scripts, and code)
>> * JDBC bindings
>> * JDBC-like bindings that support annotated objects and generics
>> * Query Executors that make threaded result reading simple
>> * Simplified filter writing for server and/or client
>> * Index support
>>
>> HBql is a work in progress and I am open to feedback and suggestions.
>> I am still working on the docs, so the examples and javadocs are pretty
>> lame.
>>
>> Have a look at: http://www.hbql.com
>>
>> Cheers,
>> Paul
>>
>>
>>
>
Re: [Announce] HBql
Posted by Paul Ambrose <pa...@mac.com>.
I was not real keen on spinning yet another dialect of SQL, but I wanted the query
language to fit HBase. So, for example, if you want to specify a filter for the server and a
filter for the client, a standard where clause is not going to work. Same goes with versioning
info and key ranges.
That said, supporting the JPA QL would not be a lot of work if that is what people want to use.
But I cannot promise to surface all the goodness of HBase.
Cheers,
Paul
On Jan 5, 2010, at 1:44 PM, Leen Toelen wrote:
> Hi,
>
> I also think re-using JPA and the JP Quer Language is a great idea.
>
> Regards,
> Leen
>
> On Tue, Jan 5, 2010 at 10:39 PM, Wim Van Leuven <
> wim.vanleuven@highestpoint.biz> wrote:
>
>> Hello Paul,
>>
>> Looks very interesting. One consideration, though, regarding annotated
>> objects: wouldn't it be enormously interesting to (try to) reuse the JPA
>> annotations?
>>
>> Another very interesting aspect on easing HBase development would be some
>> nifty support for necessary facets or satellites (looking for some good
>> term
>> coining here). By facets/satellites I mean the fact that some data needs
>> denormalization for sake of performance. Updating the annotated source
>> record should also update its facets/satellites spread across other tables.
>>
>> Just an idea.
>>
>> -----Original Message-----
>> From: Paul Ambrose [mailto:pambrose@mac.com]
>> Sent: dinsdag 5 januari 2010 21:49
>> To: hbase-user@hadoop.apache.org
>> Subject: [Announce] HBql
>>
>> Hi,
>>
>> I have been working on an abstraction layer for HBase that I hope
>> HBase users will find helpful.
>>
>> Highlights include:
>> * A dialect of SQL for HBase (usable in the console, scripts, and code)
>> * JDBC bindings
>> * JDBC-like bindings that support annotated objects and generics
>> * Query Executors that make threaded result reading simple
>> * Simplified filter writing for server and/or client
>> * Index support
>>
>> HBql is a work in progress and I am open to feedback and suggestions.
>> I am still working on the docs, so the examples and javadocs are pretty
>> lame.
>>
>> Have a look at: http://www.hbql.com
>>
>> Cheers,
>> Paul
>>
>>
Re: [Announce] HBql
Posted by Leen Toelen <to...@gmail.com>.
Hi,
I also think re-using JPA and the JP Quer Language is a great idea.
Regards,
Leen
On Tue, Jan 5, 2010 at 10:39 PM, Wim Van Leuven <
wim.vanleuven@highestpoint.biz> wrote:
> Hello Paul,
>
> Looks very interesting. One consideration, though, regarding annotated
> objects: wouldn't it be enormously interesting to (try to) reuse the JPA
> annotations?
>
> Another very interesting aspect on easing HBase development would be some
> nifty support for necessary facets or satellites (looking for some good
> term
> coining here). By facets/satellites I mean the fact that some data needs
> denormalization for sake of performance. Updating the annotated source
> record should also update its facets/satellites spread across other tables.
>
> Just an idea.
>
> -----Original Message-----
> From: Paul Ambrose [mailto:pambrose@mac.com]
> Sent: dinsdag 5 januari 2010 21:49
> To: hbase-user@hadoop.apache.org
> Subject: [Announce] HBql
>
> Hi,
>
> I have been working on an abstraction layer for HBase that I hope
> HBase users will find helpful.
>
> Highlights include:
> * A dialect of SQL for HBase (usable in the console, scripts, and code)
> * JDBC bindings
> * JDBC-like bindings that support annotated objects and generics
> * Query Executors that make threaded result reading simple
> * Simplified filter writing for server and/or client
> * Index support
>
> HBql is a work in progress and I am open to feedback and suggestions.
> I am still working on the docs, so the examples and javadocs are pretty
> lame.
>
> Have a look at: http://www.hbql.com
>
> Cheers,
> Paul
>
>