hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: HBase as a file repository
Date Tue, 04 Apr 2017 18:00:47 GMT
On Thu, Mar 30, 2017 at 1:01 PM, Daniel JeliƄski <djelinski1@gmail.com>
wrote:

> ...
> Now. HBase Get in Java API is an atomic operation in the sense that it does
> not complete until all data is retrieved from the server. It takes 100 ms
> to retrieve a 1MB cell (file), and only after retrieving I am able to start
> serving it to the end user. For larger cells the wait time is even longer,
> and response times longer than 100 ms are bad for user experience. I would
> like to start streaming the file over HTTP as soon as possible.



What's the recommended approach to avoid or reduce the delay between when
> HBase starts sending the response and when the application can act on it?


As is, Cells are indivisible as are 'responses' when we promise a
consistent view. Our implementation has us first realize the response in
memory on the server-side before we ship the client. We do not have support
for streaming responses (though this an old request that has come up in
many forms [1]). Until we have such support, there'll be this lag you
describe whether MOB or not.

Thanks,
St.Ack
1. See HBASE-2677 REST interface improvements, or HBASE-8691
High-Throughput Streaming Scan API, or more recently one of the
justifications for taking up grpc in issues like: HBASE-13467 Prototype
using GRPC as IPC mechanism

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