Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7CE2D1884D for ; Wed, 19 Aug 2015 19:27:15 +0000 (UTC) Received: (qmail 14342 invoked by uid 500); 19 Aug 2015 19:27:08 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 14251 invoked by uid 500); 19 Aug 2015 19:27:08 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 14235 invoked by uid 99); 19 Aug 2015 19:27:08 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Aug 2015 19:27:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 02217182108 for ; Wed, 19 Aug 2015 19:27:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id PNWAXgqVgb5c for ; Wed, 19 Aug 2015 19:27:06 +0000 (UTC) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 6500A207D6 for ; Wed, 19 Aug 2015 19:27:06 +0000 (UTC) Received: by ykbi184 with SMTP id i184so15631740ykb.2 for ; Wed, 19 Aug 2015 12:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0mBSIBEabsBbZO2ijG4o8QzlADqVg0qdB/VxkzMYqlY=; b=emZWkQK56bmzJm6bzJUw47WUTWnX4p259JCmJCLlEO0zy8jEExYWyeJXPEEv9ZphNC wqKEBVp5AhaHU+ChPpim0AsEeOt24bTKV6KiFW8WqWBW/KlvPxZIkDpeLEc6c+MQIeu2 hjBlvfGVoA0yRXEZF9MNcK3Z3M8E8VeP+0fy6V8bE12cdJdK+MWId3XwNCeoa8ypJGfM Q7NnrOb1TcqIC0WAkhwlHRE3DRtMPagQUE2N6KH0Dec55nxoosK8VZPjN9Giogq2cZVS Q6a/9wYaaT5bblkM3v/X1X21esqh6hhsjrsrDbW6Xnx/bneYbIppk1+ZxywXyXZ/Emlq KYRQ== X-Received: by 10.170.69.7 with SMTP id l7mr15834303ykl.114.1440012425353; Wed, 19 Aug 2015 12:27:05 -0700 (PDT) Received: from hw10447.local (pool-68-134-10-53.bltmmd.fios.verizon.net. [68.134.10.53]) by smtp.googlemail.com with ESMTPSA id g197sm1514386ywb.46.2015.08.19.12.27.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Aug 2015 12:27:04 -0700 (PDT) Message-ID: <55D4D88B.8020600@gmail.com> Date: Wed, 19 Aug 2015 15:27:07 -0400 From: Josh Elser User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dev@accumulo.apache.org CC: dev@hbase.apache.org Subject: Re: HBase and Accumulo References: <55D4C9CD.80708@gmail.com> <55D4CB62.8010008@gmail.com> <20150819184735.GA28733@ll.mit.edu> In-Reply-To: <20150819184735.GA28733@ll.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alright, I have to ask... are you referring to the paper that cites Accumulo performance without write-ahead logs enabled? I have some serious reservations about the relevance of that paper to this conversation and just want to make sure people aren't led astray by what the actual takeaway should be. Jeremy Kepner wrote: > A big difference between Accumulo and HBase is the published performance numbers. > The Accumulo community has done a good job of continuing to publish up-to-date performance > numbers in peer-reviewed venues which allow Accumulo to claim best in the world performance. > > The HBase community hasn't been doing that so much. It would be great if they did because > the HBase points on the graphs are old and it would be good to get new ones. > > > On Wed, Aug 19, 2015 at 02:30:58PM -0400, Josh Elser wrote: >> Like I've said many times now, it's relative to your actual problem. >> If you don't have that much data (or intend to grow into that much >> data), it's not an issue. Obviously, this is the case for you. >> >> However, it is an architectural difference between the two projects >> with known limitations for a single metadata region. It's a >> difference as what was asked for by Jerry. >> >> Ted Malaska wrote: >>> 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 >>>>> >>>>>