The simple claim that "Scylla IS a drop in replacement for C*" shows that
they clearly don't know as much as they think they do.

Even if it did supposedly "support everything" it would not actually work
like that. For example, some things in Cassandra work "the way they work" .
They are not specifically defined in a unit test or a document that
describes how they are supposed to work. During a massive code port you can
not reason if the code still works the same way in all situations.

Example, without using SEDA and using something else it definitely wont
work the same way when the thread pools fill up and it starts blocking,
dropping, whatever. There is so much implicitly undefined behavior.

Also just for argument sake. YCSB proves nothing. Nothing. It generates
key-value data, and well frankly that is not the primary use case of
Cassandra..... So again. Know what you don't know.





On Sun, Mar 12, 2017 at 2:15 PM, Jonathan Haddad <j...@jonhaddad.com> wrote:

> I don't think Jeff comes across as angry.  He's simply pointing out that
> ScyllaDB isn't a drop in replacement for Cassandra.  Saying that it is is
> very misleading.  The marketing material should really say something like
> "drop in replacement for some workloads" or "aims to be a drop in
> replacement".  As is, it doesn't support everything, so it's not a drop in.
>
>
> On Sat, Mar 11, 2017 at 10:34 PM 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.
>> We go through great deal of doing it and we don't just throw comments
>> without backing.
>>
>> 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). In 1.7 release we support cql uploader
>> from 3.x. We will support the SStable format of 3.x natively in 3 month
>> time. Soon all of the feature set will be implemented. We always have been
>> using this page (not 100% up to date, we'll update it this week):
>> http://www.scylladb.com/technology/status/
>>
>> We add a jmx-proxy daemon in java in order to make the transition as
>> smooth as possible. Almost all the nodetool commands just work, for sure
>> all the important ones.
>> Btw: we have a RESTapi and Prometheus formats, much better than the hairy
>> jmx one.
>>
>> Spark, Kairosdb, Presto and probably Titan (we add Thrift just for legacy
>> users and we don't intend
>> to decommission an api).
>>
>> Regarding benchmarks, if someone finds a flaw in them, we'll do the best
>> to fix it.
>> Let's ignore them and just here what our users have to say:
>> http://www.scylladb.com/users/
>>
>>
>>

Reply via email to