incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: counters + replication = awful performance?
Date Wed, 28 Nov 2012 15:15:27 GMT
I may be wrong but during a bootstrap hints can be silently discarded, if
the node they are destined for leaves the ring.

There are a large number of people using counters for 5 minute "real-time"
statistics. On the back end they use ETL based reporting to compute the
true stats at a hourly or daily interval.

A user like this might benefit from DANGER counters. They are not looking
for perfection, only better performance, and the counter row keys
themselves role over in 5 minutes anyway.

Options like this are also great for winning benchmarks. When someone other
NoSQL (that is not has fast as c*) wants to win a benchmark they turn
off/on WAL, or write acks, or something that compromises their ACID/CAP
story for the purpose of winning. We need our own secret awesome-sauce
dangerous options too! jk


On Wed, Nov 28, 2012 at 4:21 AM, Rob Coli <rcoli@palominodb.com> wrote:

> On Tue, Nov 27, 2012 at 3:21 PM, Edward Capriolo <edlinuxguru@gmail.com>
> wrote:
> > I mispoke really. It is not dangerous you just have to understand what it
> > means. this jira discusses it.
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-3868
>
> Per Sylvain on the referenced ticket :
>
> "
> I don't disagree about the efficiency of the valve, but at what price?
> 'Bootstrapping a node will make you lose increments (you don't know
> which ones, you don't know how many and this even if nothing goes
> wrong)' is a pretty bad drawback. That is pretty much why that option
> makes me uncomfortable: it does give you better performance, so people
> may be tempted to use it. Now if it was only a matter of replicating
> writes only through read-repair/repair, then ok, it's pretty dangerous
> but it's rather easy to explain/understand the drawback (if you don't
> lose a disk, you don't lose increments, and you'd better use CL.ALL or
> have read_repair_chance to 1). But the fact that it doesn't work with
> bootstrap/move makes me wonder if having the option at all is not
> making a disservice to users.
> "
>
> To me anything that can be described as "will make you lose increments
> (you don't know which ones, you don't know how many and this even if
> nothing goes wrong)" and which therefore "doesn't work with
> bootstrap/move" is correctly described as "dangerous." :D
>
> =Rob
>
> --
> =Robert Coli
> AIM&GTALK - rcoli@palominodb.com
> YAHOO - rcoli.palominob
> SKYPE - rcoli_palominodb
>

Mime
View raw message