On Mon, Mar 13, 2017 at 12:17 AM, benjamin roth <brs...@gmail.com> wrote:
> @Dor,Jeff:
>
> I think Jeff pointed out an important fact: You cannot stop CS, swap
> binaries and start Scylla. To be honest that was AFAIR the only "Oooh :(" I
> had when reading the Scylla "marketing material".
>
If you're on 2.1.x you can. You will need to stop your running cluster and
many users cannot do that.
If you do have ability to sustain downtime, take a snapshot and thus your
data is safe.
There is a way to do it online, explained below
>
> If that worked it would be very valuable from both Scylla's and a users'
> point of view. As a user I would love to give scylla a try as soon as it
> provides all the features my application requires. But the hurdle is quite
> high. I have to create a separate scylla cluster and I have to migrate a
> lot of data and I have to manage somehow that my application can use (r+w)
> both CS + Scylla at the same time to not run any risk of data loss or dead
> end road if something goes wrong. And still: I would not be able to
>
So there are two options to do double writes, one is do it on the client
side and send to the two separate clusters.
Another option is we have a CQL-proxy small go application. You install it
on all of your C* nodes and it duplicated the CQL
traffic to remote Scylla cluster.
When you do the above you start Scylla from a C* snapshot/backup or sstable
load the previous data (works for 2.x and 3.y)(first start the double
writes). If you have a double cluster, you have zero risk if something goes
wrong.
> compare CS + Scylla for my workload totally fair as the conditions
> changed. New hardware, maybe partial dataset, probably only "test traffic".
>
50% of users run on AWS so it's easy to use the same conditions.
If you're on physical machines, just give us half the hardware and see we
cope with it - meaning
err on our side (as long as you don't use crappy hardware which will cap
us).
The advantage is that you can run in this mode weeks/months until you're
absolute sure things work fine.
Most of our users who came from C* did it.
> However, if I was able to just replace a single node in an existing
> cluster I'd have:
>
Everybody wanted it but
> 1. Superlow hurdle to give it a try: No risk, no effort
>
Yes there is risk. We considered that and even toyed with such an
implementation.
The risk is that this node will be part of the cluster and although it
supposed to behave and you'll
have replicas, something may go wrong and your cluster's RPC will suffer.
The Cassandra RPC wasn't documented as changed over the releases, I bet you
cannot mix&match a 2.1 with 3.4
and can only do latest x.minor -> (x+1).0
In addition, in case there is an issue, whose fault would it be?
Lastly, we have our own internal RPC with various optimizations.
> 2. Fair comparison by comparing new node against some equally equipeed old
> node in the same cluster with the same workload
>
Even if it would work, the new node won't run faster unless CL=1 which is
rare.
> 3. Easy to make a decision if to continue or not
>
> That would be totally awesome!
>
>
> 2017-03-12 23:16 GMT+01:00 Kant Kodali <k...@peernova.com>:
>
>> I don't think ScyallDB guys started this conversation in the first place
>> to suggest or promote "drop-in replacement". It was something that is
>> brought up by one of the Cassandra users and ScyallDB guys just clarified
>> it. They are gracious enough to share the internals in detail.
>>
>> honestly, I find it weird when I see questions like whether a question
>> belongs to a mailing list or not especially in this case. If one doesn't
>> like it they can simply not follow the thread. I am not sure what is the
>> harm here.
>>
>>
>>
>> On Sun, Mar 12, 2017 at 2:29 PM, James Carman <ja...@carmanconsulting.com
>> > wrote:
>>
>>> Well, looking back, it appears this thread is from 2015, so apparently
>>> everyone is okay with it.
>>>
>>> Promoting a value-add product that makes using Cassandra easier/more
>>> efficient/etc would be cool, but coming to the Cassandra mailing list to
>>> promote a "drop-in replacement" (use us, not Cassandra) isn't cool, IMHO.
>>>
>>>
>>> On Sun, Mar 12, 2017 at 5:04 PM Kant Kodali <k...@peernova.com> wrote:
>>>
>>> yes.
>>>
>>> On Sun, Mar 12, 2017 at 2:01 PM, James Carman <
>>> ja...@carmanconsulting.com> wrote:
>>>
>>> Does all of this Scylla talk really even belong on the Cassandra user
>>> mailing list in the first place?
>>>
>>>
>>>
>>>
>>> On Sun, Mar 12, 2017 at 4:07 PM Jeff Jirsa <jji...@apache.org> wrote:
>>>
>>>
>>>
>>> On 2017-03-11 22:33 (-0700), Dor Laor <d...@scylladb.com> wrote:
>>> > On Sat, Mar 11, 2017 at 10:02 PM, Jeff Jirsa <jji...@gmail.com> wrote:
>>> > > On 2017-03-10 09:57 (-0800), Rakesh Kumar wrote:
>>> > > > Cassanda vs Scylla is a valid comparison because they both are
>>> > > compatible. Scylla is a drop-in replacement for Cassandra.
>>> > >
>>> > > No, they aren't, and no, it isn't
>>> > >
>>> >
>>> > Jeff is angry with us for some reason. I don't know why, it's natural
>>> that
>>> > when a new opponent there are objections and the proof lies on us.
>>>
>>> I'm not angry. When I'm angry I send emails with paragraphs of
>>> expletives. It doesn't happen very often.
>>>
>>> This is an open source ASF project, it's not about fighting for market
>>> share against startups who find it necessary to inflate their level of
>>> compatibility to sell support contracts, it's about providing software that
>>> people can use (with a license that makes it easy to use). I don't work for
>>> a company that makes money selling Cassandra based solutions and you're not
>>> an opponent.
>>>
>>> >
>>> > Scylla IS a drop in replacement for C*. We support the same CQL (from
>>> > version 1.7 it's cql 3.3.1, protocol v4), the same SStable format
>>> (based on
>>> > 2.1.8).
>>>
>>> Scylla doesn't even run on all of the supported operating systems, let
>>> alone have feature parity or network level compatibility (which you'd
>>> probably need if you REALLY want to be drop-in
>>> stop-one-cassandra-node-swap-binaries-start-it-up compatible, which is
>>> what your site used to claim, but obviously isn't supported). You support a
>>> subset of one query language and can read and write one sstable format. You
>>> do it with great supporting tech and a great engineering team, but you're
>>> not compatible, and if I were your cofounder I'd ask you to focus on the
>>> tech strengths and not your drop-in compatibility, so engineers who care
>>> about facts don't grow to resent your public lies.
>>>
>>> I've used a lot of databases in my life, but I don't know that I've ever
>>> had someone call me angry because I pointed out that database A wasn't
>>> compatible with database B, but I guess I'll chalk it up to 2017 and the
>>> year of fake news / alternative facts.
>>>
>>> Hugs and kisses,
>>> - Jeff
>>>
>>>
>>>
>>
>
