accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Malaska <>
Subject Re: HBase and Accumulo
Date Wed, 19 Aug 2015 18:29:18 GMT
Sorry 10 billion a day so that is 7 Trillion records.  So many issues
around 1000 Trillion

On Wed, Aug 19, 2015 at 2:28 PM, Ted Malaska <>

> I've been doing HBase for a long time and never had an issue with region
> count limits and I have clusters with 10s of billions of records.  Many
> there would be issues around a couple Trillion records, but never got that
> high yet.
> Ted Malaska
> On Wed, Aug 19, 2015 at 2:24 PM, Josh Elser <> wrote:
>> Oh, one other thing that I should mention (was prompted off-list).
>> (definition time since cross-list now: HBase regions == Accumulo tablets)
>> Accumulo will handle many more regions than HBase does now due to a
>> splittable metadata table. While I was told this was a very long and
>> arduous journey to implement correctly (WRT splitting, merges and bulk
>> loading), users with "too many regions" problems are extremely few and far
>> between for Accumulo.
>> I was very happy to see effort/design being put into this in HBase. And,
>> just to be fair in criticism/praises, HBase does appear to me to do
>> assignments of regions much faster than Accumulo does on a small cluster
>> (~5-10 nodes). Accumulo may take a few seconds to notice and reassign
>> tablets. I have yet to notice this with HBase (which also could be due to
>> lack of personal testing).
>> Jerry He wrote:
>>> Hi, folks
>>> We have people that are evaluating HBase vs Accumulo.
>>> Security is an important factor.
>>> But I think after the Cell security was added in HBase, there is no more
>>> real gap compared to Accumulo.
>>> I know we have both HBase and Accumulo experts on this list.
>>> Could someone shred more light?
>>> I am looking for real gap comparing HBase to Accumulo if there is any so
>>> that I can be prepared to address them. This is not limited to the
>>> security
>>> area.
>>> There are differences in some features and implementations. But they
>>> don't
>>> see like real 'gaps'.
>>> Any comments and feedbacks are welcome.
>>> Thanks,
>>> Jerry

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