hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Async Table API
Date Sun, 31 May 2015 01:22:55 GMT
On Fri, May 29, 2015 at 3:34 AM, Jurriaan Mous <jurmous@jurmo.us> wrote:

> Dear HBase Developers,
> I am currently working on issue HBASE-13784 <
> https://issues.apache.org/jira/browse/HBASE-13784> to provide an Async
> Table api which builds on my previous work in HBASE-12684 <
> https://issues.apache.org/jira/browse/HBASE-12684>
>  which added a new AsyncRpcClient.
> For this I am proposing a new AsyncTable interface and implementation.
> This way the method signatures will not conflict with Table methods and
> AsyncTable can be more lightweight since it does not need Executors and
> more.

That'll be sweet if more lightweight than Table implementation.

> Also some existing Table implementations like RemoteHTable are difficult
> to turn async so a new interface is easier.

New (Async)Table Interface with asyncy ops  sounds right to me.

Looking at list of methods, it doesn't look like an implementation will be
able to implement Table and AsyncTable ... but that is fine I'd say
(different chassis involved).

> With a new interface we enable ourselves to rethink a bit of the API to be
> simpler.
> I am currently proposing the following methods in the simpler AsyncTable
> interface:
> exists(Get): ResponsePromise<Boolean>
> exists(List<Get>): ResponsePromise<Boolean[]>
> get(Get): ResponsePromise<Result>
> get(List<Get>): ResponsePromise<Result[]>
> mutate(Mutation): ResponsePromise<Void> - Instead of separate Put, Delete,
> Increment, IncrementValue and Append methods
> checkAndMutate(byte[], byte[], byte[], CompareOp, byte[], Mutation):
> ResponsePromise<Void> - Will not accept Append and Increment

Over in issue, you are thinking 'not accept Append and Increment' because
they are one-at-a-time-nonce-dependent... Is the above call one-at-a-time?

> checkAndMutate(byte[], byte[], byte[], CompareOp, byte[], RowMutations):
> ResponsePromise<Void> - Will not accept Append and Increment

The thinking on the above method is that if doing bulk checkAndMutate, that
they should all be inside a single row?

> getScanner(Scan): ResponsePromise<Void> - AsyncResultScanner
> coprocessorService(byte[]): AsyncCoprocessorRpcService
> coprocessorService(Class<T extends Service>, byte[] startkey, byte[]
> endkey, Batch.Call<T,R> callable): ResponsePromise<Map<byte[], R>>
> batchCoprocessorService(Descriptors.MethodDescriptor, Message, byte[]
> startKey, byte[] endKey, R responsePrototype): ResponsePromise<Map<byte[],
> R>>
> To send multiple mutations you need to use a BufferedMutator which handles
> writeBuffers internally. I will look into making it possible to use it with
> Promises.

> Batch operations will be able to be done by a PromiseKeeper which is a
> promise to which other promises can be added.
PromiseKeeper is a loaded term! See https://promisekeepers.org/#what ...

> There will be a new AsyncResultScanner which handles incoming batches of
> result. It will not be possible to do next on it since this does not makes
> sense in an async context. There will be however a way to request a new
> batch with a promise.
I like this.... no next. What you thinking as means of specifying
'batches'? We've been trying to move away from specifying batches in terms
of row count to instead do batches of a particular size (See HBASE-13441).

> If you have any insights/comments/suggestions/questions please add them to
> the issue. There is also already a first working patch with get and exists
> methods.
> https://issues.apache.org/jira/browse/HBASE-13784 <
> https://issues.apache.org/jira/browse/HBASE-13784>
Nice work Jurriaan,

> Thanks!
> Jurriaan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message