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 <[email protected]> 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]
