ets keep it side for now and it's only possible
> when we have cluster setup.
>
> On 29/08/19, 06:21, "Dor Laor" wrote:
>
> On Wed, Aug 28, 2019 at 5:43 PM Jon Haddad wrote:
>
> > > Arguably, the other alternative to server-side denormalization is
&
On Wed, Aug 28, 2019 at 5:43 PM Jon Haddad wrote:
> > Arguably, the other alternative to server-side denormalization is to do
> the denormalization client-side which comes with the same axes of costs and
> complexity, just with more of each.
>
> That's not completely true. You can write to any
The main point is that we decided to take a strategic decision to invest in
the client
side. We always wanted to get to the state but for natural reasons, it took
us a while.
The client side changes aren't just about a small feature here and there or
stop at
thread per core. Think about the changes
g flag
but maybe we're ahead of ourselves, let us pick a starting point and let a
developer dive in to one of these
first. Avi is welcome to over rule me ;)
> On Mon, Apr 23, 2018 at 6:17 PM, Dor Laor wrote:
>
> > On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli
> > wrote:
>
its and fun too.
The C* ecosystem can either shrink or expand. We offer to expand it.
>
> On Mon, Apr 23, 2018, 8:18 PM Dor Laor wrote:
>
> > On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli
> > wrote:
> >
> > > Is one of the “abuse” of Apache license is Sc
te
such a huge effort to the C* server. It is reasonable to collaborate around
protocol enhancements that are acceptable,
even without coding and make sure the protocol is enhanceable in a way that
forward compatible.
Happy to be proved wrong as I am not a lawyer and don’t understand various
>
On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad wrote:
> From where I stand it looks like you've got only two options for any
> feature that involves updating the protocol:
>
> 1. Don't built the feature
> 2. Built it in Cassanda & scylladb, update the drivers accordingly
>
> I don't think you h
We at Scylla, implemented repair in a similar way to the Cassandra reaper.
We do
that using an external application, written in go that manages repair for
multiple clusters
and saves the data in an external Scylla cluster. The logic resembles the
reaper one with
some specific internal sharding opti
+ The C* coordinator send async write requests to the replicas.
This is very important since it allows it to return a low latency
reply to the client once the CL is reached. You wouldn't want
to serialize the replicas one after the other.
+ The client <-> server sync/async isn't related
