incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avinash Lakshman <avinash.laksh...@gmail.com>
Subject Re: Commit log changes in 0.7
Date Fri, 26 Feb 2010 18:49:54 GMT
Writes will no longer be sequential if one has a commit log per CF. This
will absolutely kill write performance. We mis-configured the commit log
directory and put it on a data file directory and our write performance
degraded 10x. It may not be that bad here but you will no longer have the
benefit of sequential writes.

Avinash

On Fri, Feb 26, 2010 at 10:44 AM, Chris Goffinet <cg@chrisgoffinet.com>wrote:

>
> -Chris
>
> On Feb 26, 2010, at 10:27 AM, Ryan King wrote:
>
> > On Fri, Feb 26, 2010 at 9:22 AM, Gary Dusbabek <gdusbabek@gmail.com>
> wrote:
> >> The commit log currently has a header section whose size is constant,
> >> but is a function of the total number of defined column families.
> >> This isn't going to work with CASSANDRA-44 where CFs can be added or
> >> removed on the fly.  I see two options:
> >>
> >> 1.  hard code the size of the header to accommodate a maximum number
> >> of CFs.  I don't like this approach because it imposes a hard limit.
> >> 2.  move the header into its own file.  I don't like this because it
> >> adds complexity.
> >>
> >> Any better other ideas?
> >>
> >> Some background:  the data stored in the header indicates a) which CFs
> >> are 'dirty' and b) log replay offsets for each CF.
> >
> > 1. A separate CL per CF. You could do away with the offsets then, but
> > you lose linearization across CFs, which may be ok?
>
> This would be bad because the design of the CL being on dedicated disk and
> not having to do seeks is now lost if we are writing to sep commit logs.
>
> >
> > 2. A segmented CL - store the header once per segment. In theory you'd
> > only have to start a new segment when the list of CFs change.
> >
> > -ryan
>
>

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