Does Accumulo Have a Physical Table Limitation Like HBase?

[David Medinets <da...@gmail.com>]

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.

Re: Does Accumulo Have a Physical Table Limitation Like HBase?

[Josh Elser <jo...@gmail.com>]

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 <ma...@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 <da...@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.
>>>

Re: Does Accumulo Have a Physical Table Limitation Like HBase?

[Christopher <ct...@apache.org>]

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 <ma...@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 <da...@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.
>>

Re: Does Accumulo Have a Physical Table Limitation Like HBase?

[Mike Drob <ma...@cloudera.com>]

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 <da...@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.
>