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 0D8F17FFA for ; Sun, 2 Oct 2011 14:45:34 +0000 (UTC) Received: (qmail 52741 invoked by uid 500); 2 Oct 2011 14:45:33 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 52670 invoked by uid 500); 2 Oct 2011 14:45:32 -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 52658 invoked by uid 99); 2 Oct 2011 14:45:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Oct 2011 14:45:32 +0000 X-ASF-Spam-Status: No, hits=4.0 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates 74.125.82.169 as permitted sender) Received: from [74.125.82.169] (HELO mail-wy0-f169.google.com) (74.125.82.169) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Oct 2011 14:45:25 +0000 Received: by wyf22 with SMTP id 22so3159266wyf.14 for ; Sun, 02 Oct 2011 07:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GJT2D8Un9jOurVyR3nsPIa6WiPZECnE8d6c/LFNZ2Hw=; b=ME4u0WFTXVk+KPjKt+RUxUDaoGuS338VH4VjUIibmz4YZWHKXYqaQX3hLG6AyH3C8j qmvJHYms7VwPNN5ufG4dD2izj3XTLQfaQAx3zLhwhs3xHHXyPVwyZNQfjMIRJ33i5/6v aQx4FDsZETC/vrIZQtcl3Kqh0F/iAl3XICMWs= MIME-Version: 1.0 Received: by 10.216.21.74 with SMTP id q52mr2188701weq.36.1317566704461; Sun, 02 Oct 2011 07:45:04 -0700 (PDT) Received: by 10.216.17.208 with HTTP; Sun, 2 Oct 2011 07:45:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Oct 2011 07:45:04 -0700 Message-ID: Subject: Re: Multiple WALs From: Ted Yu To: dev@hbase.apache.org Content-Type: multipart/alternative; boundary=0016364d1e6563290104ae51e776 X-Virus-Checked: Checked by ClamAV on apache.org --0016364d1e6563290104ae51e776 Content-Type: text/plain; charset=ISO-8859-1 Take it easy. You were the reporter: you started the discussion thread and logged JIRA. In the future, please keep as much detail from the discussion as possible in the JIRA. Cheers On Sat, Oct 1, 2011 at 10:22 PM, Akash Ashok wrote: > Uh Oh! Its showing the reporter of the problem as me but it wasn't me in > reality :) I am not able to modify it. Please feel free to change it :) > > Cheers, > Akash A > > On Sun, Oct 2, 2011 at 10:38 AM, Akash Ashok > wrote: > > > I've opened up a JIRA for this > > https://issues.apache.org/jira/browse/HBASE-4529 > > > > Cheers, > > Akash A > > > > > > On Sun, Oct 2, 2011 at 6:04 AM, karthik tunga >wrote: > > > >> Hey Stack, > >> > >> Along with the log replaying part, logic is also needed for log roll > over. > >> This, I think, easier compared to the merging of the logs. Any edits > less > >> than the last sequence number on the file system can be removed from > all > >> the WALs. > >> > >> Cheers, > >> Karthik > >> > >> On 1 October 2011 18:05, Jesse Yates wrote: > >> > >> > I think adding the abstraction layer and making it not only pluggable, > >> but > >> > configurable would be great. > >> > > >> > It would be nice to be able to tie into a service that logs directly > to > >> > disk, rather than go through HDFS giving some potentially awesome > >> speedup > >> > at > >> > the cost of having to write a logging service that handles > replication, > >> > etc. > >> > Side note, Accumulo is using their own service to storing the WAL, > >> rather > >> > than HDFS and I suspect that plays a big role in people's claim of its > >> > ability to do 'outperform' HBase. > >> > > >> > -Jesse Yates > >> > > >> > On Sat, Oct 1, 2011 at 2:04 PM, Stack wrote: > >> > > >> > > Yes. For sure. Would need to check that the split can deal w/ > >> > > multiple logs written by the one server concurrently (sort by > sequence > >> > > edit id after sorting on all the rest that makes up a wal log key). > >> > > > >> > > St.Ack > >> > > > >> > > On Sat, Oct 1, 2011 at 1:36 PM, karthik tunga < > >> karthik.tunga@gmail.com> > >> > > wrote: > >> > > > Hey, > >> > > > > >> > > > Doesn't multiple WALs need some kind of merging when recovering > from > >> a > >> > > crash > >> > > > ? > >> > > > > >> > > > Cheers, > >> > > > Karthik > >> > > > > >> > > > > >> > > > On 1 October 2011 15:17, Stack wrote: > >> > > > > >> > > >> +1 on making WAL pluggable so we can experiment. Being able to > >> write > >> > > >> multiple WALs at once should be easy enough to do (the WAL split > >> code > >> > > >> should be able to handle it). Also a suggestion made a while back > >> was > >> > > >> making it so hbase could be configured to write two filesystems > -- > >> > > >> there'd be hbase.rootdir as now -- and then we'd allow specifying > >> > > >> another fs to use for writing WALs (If not specified, we'd just > use > >> > > >> hbase.rootdir for all filesystem interactions as now). > >> > > >> > >> > > >> St.Ack > >> > > >> > >> > > >> On Sat, Oct 1, 2011 at 10:56 AM, Dhruba Borthakur < > >> dhruba@gmail.com> > >> > > >> wrote: > >> > > >> > I have been experimenting with the WAL settings too. It is > >> obvious > >> > > that > >> > > >> > turning off the wal makes ur transactions go faster, HDFS > >> write/sync > >> > > are > >> > > >> not > >> > > >> > yet very optimized for high throughput small writes. > >> > > >> > > >> > > >> > However, irrespective of whether I have one wal or two, I have > >> > seeing > >> > > the > >> > > >> > same throughput. I have experimented with an HDFS setting that > >> > allows > >> > > >> > writing/sync to multiple replicas in parallel, and that has > >> > increased > >> > > >> > performance for my test workload, see > >> > > >> > https://issues.apache.org/jira/browse/HDFS-1783. > >> > > >> > > >> > > >> > About using one wal or two, it will be nice if we can separate > >> out > >> > the > >> > > >> wal > >> > > >> > API elegantly and make it pluggable. In that case, we can > >> experiment > >> > > >> HBase > >> > > >> > with multiple systems. Once we have it pluggable, we can make > the > >> > > habse > >> > > >> wal > >> > > >> > go to a separate HDFS (pure SSD based maybe?). > >> > > >> > > >> > > >> > -dhruba > >> > > >> > > >> > > >> > > >> > > >> > On Sat, Oct 1, 2011 at 8:09 AM, Akash Ashok < > >> thehellmaker@gmail.com > >> > > > >> > > >> wrote: > >> > > >> > > >> > > >> >> Hey, > >> > > >> >> I've see that setting writeToWAL(false) boosts up the writes > >> like > >> > > crazy. > >> > > >> I > >> > > >> >> was just thinking having MuiltipleWAL on HBase. I understand > >> that > >> > > this > >> > > >> is a > >> > > >> >> consideration in BigTable paper that a WAL per region is not > >> used > >> > > >> because > >> > > >> >> it > >> > > >> >> might result in a lot of disk seeks when there are large > number > >> of > >> > > >> reasons. > >> > > >> >> But how about having as many WALs as the number of HardDrives > in > >> > the > >> > > >> >> system. > >> > > >> >> I see that the recommended configs for HBase are 4 - 12 hard > >> drives > >> > > per > >> > > >> >> node. This might kick the writes up a notch. > >> > > >> >> > >> > > >> >> Would like to know the general opinion on this one? > >> > > >> >> > >> > > >> >> Cheers, > >> > > >> >> Akash A > >> > > >> >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > > >> > Connect to me at http://www.facebook.com/dhruba > >> > > >> > > >> > > >> > >> > > > > >> > > > >> > > >> > > > > > --0016364d1e6563290104ae51e776--