Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <ad585aed-795e-fa40-9b16-706f4921efc5@apache.org>
References: <CALVQ-8GcNSBBM2f5bX83jLtyw3_XLkg5Bkgrv74s2UKK_pxKsg@mail.gmail.com>
 <ad585aed-795e-fa40-9b16-706f4921efc5@apache.org>
From: Pedro Gordo <pedro.gordo1986@gmail.com>
Date: Fri, 9 Jun 2017 10:44:53 +0100
Message-ID: <CALVQ-8H2f-BjsHnU8ng0we3Hba_OZHK2+NJNtrz7nNzvU-03fw@mail.gmail.com>
Subject: Re: New contribution - Burst Hour Compaction Strategy
To: Stefan Podkowinski <spod@apache.org>
Cc: Cassandra DEV <dev@cassandra.apache.org>
Content-Type: multipart/alternative; boundary="f403043ecdf042015d055183d20a"
archived-at: Fri, 09 Jun 2017 09:45:05 -0000

--f403043ecdf042015d055183d20a
Content-Type: text/plain; charset="UTF-8"

Hi Stefan

Thanks for pointing these out. So far, I've only worked collaboratively
with SVN, so I wasn't sure how best to address this part of the development
with Git. I'll create a document explaining what I've done, hopefully until
the end of this week, so that people at least can discuss the strategy
while I work out how to address Git history. Would it be best to post
updates to this thread, or should I continue with comments in the JIRA
ticket?

I initially thought about developing in v3.0, but then I read here
<http://cassandra.apache.org/doc/latest/development/patches.html?highlight=tick%20tock>
that
only bug fixes would be accepted for 3.0, and the 3.11 was just a stability
release. I guess I'll need to redo a lot of commits, so what would be the
best branch to do them on?

Best regards

Pedro Gordo

On 9 June 2017 at 09:10, Stefan Podkowinski <spod@apache.org> wrote:

> Hello Pedro
>
> Thanks for being interested in contributing to Apache Cassandra.
> Creating a new compaction strategy is not an easy task and there are
> several things you can do to make it more obvious for other developers
> to understand what you're up to.
>
> First of all, if using github, changes to the code base should be done
> by having a separate branch in your own fork of the Apache repository.
> This will make it possible for others to quickly compare your changes to
> the current code base using the web interface. Technically using a new
> repo works as well, but isn't as convenient for others, e.g. it starts
> by not communicating which Cassandra branch was used as basis for you
> changes.
>
> Talking about git, I'd also suggest to learn more about creating a git
> history for your code that is easy to review. E.g. you may want to
> squash some of the "code clean up" style commits.
>
> As mentioned, implementing a new compaction strategy is quite an effort
> and the theories and motivations behind this is at least as interesting
> as the actual implementation. Therefor it could be a good idea to have a
> design document describing your work on a different abstraction level.
> It will also make it more likely to get other people involved in the
> discussion, as not everyone will have to check the source code for the
> details.
>
> -Stefan
>
>
> On 08.06.2017 09:31, Pedro Gordo wrote:
> > Hi all
> >
> > As part of my MSc project, I've done a new compaction strategy for
> > Cassandra, called Burst Hour Compaction Strategy. You can find the JIRA
> > ticket here: https://issues.apache.org/jira/browse/CASSANDRA-12201
> >
> > In a nutshell, the background compaction for this strategy is only
> > triggered during a predefined interval, freeing the resources during
> other
> > times of the day. It also tries to make keys unique across all the
> > SSTables, when these keys that are present in more than a configurable
> > number of tables. Please check the JIRA ticket for a full description.
> >
> > The code can be found here: https://github.com/sedulam/CASSANDRA-12201
> >
> > Please let me know what you think, or improvements that can be done (some
> > ideas are in the ticket description). Since I'm new to Cassandra, I
> imagine
> > that a lot of assumptions might not be the best, e.g. 100MB for the
> maximum
> > table size.
> >
> > I'm looking forward to working with this community!
> >
> > All the best
> > Pedro Gordo
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

--f403043ecdf042015d055183d20a--