accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Does Accumulo Have a Physical Table Limitation Like HBase?
Date Tue, 29 Apr 2014 21:21:02 GMT
Having a splittable metadata table, I assume, would allow us to scale to 
more tables, each with more tablets, than HBase can. This isn't a 
quantitative measure, however.

We generally recommend that you don't create a bunch of tablets that are 
primarily empty. I've never seen Accumulo have problems if you create 
too many.

I'd agree that with enough tables, we might see ZK issues first.

On 4/29/14, 4:44 PM, Christopher wrote:
> There's possibly more ZK usage with more tables, and more
> user/security overhead with more tables, but I can't imagine that's a
> limiting factor.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Apr 29, 2014 at 3:26 PM, Mike Drob <madrob@cloudera.com> wrote:
>> I think the limitation in Accumulo is on Tablets, not Tables (module
>> cluster size, of course).
>>
>> I've never seen anything that would indicate number of tables on a system
>> to be an issue.
>>
>>
>> On Tue, Apr 29, 2014 at 3:21 PM, David Medinets <david.medinets@gmail.com>wrote:
>>
>>> I have never used HBase and I've only used Accumulo with less than 100
>>> tables. However, when I see a statement like the following about HBase,  I
>>> feel compelled to ask how it compares to Accumulo. Does anyone know?
>>>
>>>    http://phoenix.incubator.apache.org/views.html:
>>>      This is especially important in HBase, as you cannot
>>>      realistically expect to have more than perhaps up
>>>      to a hundred physical tables and continue to get
>>>      reasonable performance from HBase.
>>>

Mime
View raw message