ve (or even better if you are interested to contribute your
> ideas/improvements in our community).
>
> Finally I want to thank you guys for your work on HBase, it was really nice
> to use your APIs, and HBaseTestingUtility was a life-saver to test my
> implementation.
>
> Than
If you have discrete sets of Puts that happen across different threads, you
may want to consider using Table.put(List puts) instead of
BufferedMutator.
-Solomon
On Wed, Feb 10, 2016 at 6:58 PM, Stack wrote:
> A flush every time you add to BufferedMutator? That will result in an rpc
> each time.
It sounds like you want a Get rathe than a scan. *table.get(new
Get("id100".**getBytes()));* should do the trick.
On Tue, Jan 19, 2016 at 7:17 AM, Rajeshkumar J
wrote:
> Hi,
>
> I have implemented Range scan using Java API as shown below
>
> Scan scan = new Scan();
> Co
This forum discusses hbase. Bigtable has different characteristics, even
though the interface is HBase's. Try the "ask a question" link on the
BIgtable support page: https://cloud.google.com/bigtable/docs/support
On Wed, Dec 9, 2015 at 11:43 PM, Shouguo Li wrote:
> Hi guys
>
> I'm trying to ge
I would think that a single BM ought to perform well over time, although
I'd be interested in hearing otherwise.
FWIW, BM's criteria for sending batch requests is more about size of the
puts rather than the number of puts.
On Wed, Oct 28, 2015 at 6:17 PM, Artem Ervits wrote:
> Thanks Enis, woul
It looks like you're using hbase 1.0 based on the fact that you're getting
a cast to Mutation rather than to Put; is that right?
There isn't an advantage of doing a write(putList) vs. a write(singlePut).
Under the covers, the context.wirte() does a single mutation, but doesn't
actually send that m
The docs you referenced are for 1.0. Table and BufferedMutator were
introduced in 1.0. In 0.98, you should continue using HTable and
autoflush.
On Wed, May 13, 2015 at 9:57 AM, Serega Sheypak
wrote:
> We are using CDH 5.4, it's on .0.98 version
>
> 2015-05-13 16:49 GMT+03:00
BufferedMutator is the preferred alternative for autoflush starting in
HBase 1.0. Get a connection via ConnectionFactory, then
connection.getBufferedMutator(tableName). It's the same functionality as
autoflush under the covers.
On Wed, May 13, 2015 at 9:41 AM, Ted Yu wrote:
> Please take a loo
I've run into this as well. I ended up using the mavnen shading tool to
work around this. Hadoop uses an older version of guava, IIRC. Changing
this is non trivial, although I think it's super important to do.
-Solomon
On Wed, Apr 1, 2015 at 9:35 AM, Enrico Olivelli - Diennea <
enrico.olive...
HConnection is also deprecated. It would be better to do:
Connection connection = ConnectionFactory.createConnection(conf);
On Wed, Mar 18, 2015 at 7:55 AM, OM PARKASH Nain wrote:
> Hi,
> I am using hbase connection pooling using
>
> HConnection hConnection=HConnectionManager.createCo
I'd like to get the hbase thrift server to use the new client (Table,
RegionLocator...). The ThriftServer uses HTablePool to manage Tables.
Is HTablePool a concept worth updating to the new interfaces in the guise
of TablePool? Should we use a single Table that has an ExecutorService
with a large
an we can't so the new API better though.
> > HTablePool is still in 1.0, so this would be thinking ahead to the fancy
> > new Table-based API. If we drop these two methods from Table, we can ship
> > with a feature gap between old and new API, resolve this in 1.1. Folks
>
cal if we're contemplating something that requires
> a breaking API change? Do we have that here? I'm not sure.
>
> On Fri, Dec 19, 2014 at 12:02 PM, Solomon Duskis
> wrote:
> >
> > Is this critical to sort out before 1.0, or is fixing this a post-1.0
> > enh
Is this critical to sort out before 1.0, or is fixing this a post-1.0
enhancement?
-Solomon
On Fri, Dec 19, 2014 at 2:19 PM, Andrew Purtell wrote:
>
> I don't like the dropped writes either. Just pointing out what we have now.
> There is a gap no doubt.
>
> On Fri, Dec 19, 2014 at 11:16 AM, Nick
14 matches
Mail list logo
