On Sun, Mar 12, 2017 at 12:11 PM, Edward Capriolo <edlinuxg...@gmail.com>
wrote:
> 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.
>
According to your definition there is no such a thing as drop and
replacement, doesn't it?
One of our users asked us to add a protocol verb that identify Scylla as
Scylla so they'll know which
is which for the time they run 2 clusters.
Look, if we'll claim we have all the features and when someone checks they
see we don't have LWT then it makes us a bad service. Usually when we get
someone (specific) interested, we map their C* usage and say what feature
isn't yet there. So far it's just lack of those not-implemented yet
features that hold users back. We do try to mimic the exact behaviour of C*.
Clearly, I can't defend a 100% drop-in replacement. Once we implement
someone's selected
featureset, then we're a drop-in replacement for them and we're not a good
match for others.
We're not after quick wins, quite the opposite.
> 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.
>
>
a. We do not pretend we know it all.
We do have a 3 year mileage with Cassandra and 2.5 with Scylla and we
gained some knowledge... before we decided to go after the C* path, we
considered
to reimplement Mongo, HDFS, Kafka and few more examples and the fact we
chose
C* shows our appreciation to this project and not the opposite.
b. YCSB is an industry standard, and that's why everybody use it.
We don't like it at all since it doesn't have prepared statements (it's
time that
someone will merge this support).
It's not a plain K/V since it's a table of 10 columns of 100b each.
We do support wide rows and learned (the hard way) their challenge,
especially
with compaction, repair and streaming. The current Scylla code doesn't
cache
wide row beyond 10MB which isn't ideal. In 1.8 (next month) we have a
partial
row caching which supposed to be very good. During the past 20 months
since
our beta we tried to focus on good out-of-the-box experience to all
real workloads
and we knowingly deferred features like LWT since we wanted a good
solid base
before we reach feature parity. If we'll do a good job with a benchmark
but a bad
one in real workload, we just shot ourselves in the foot. This was the
case around our
beta but it was just a beta. Today we think we're in a very solid
position. We still
have lots to complete around repair (which is ok but not great). There
is a work
in progress to switch out from Merkle tree to a new algorithm and
reduced latency
(almost there). We have mixed feelings about anti-compaction for
incremental repair
but we're likely to go through this route too
>
>
>
> 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/
>>>
>>>
>>>
>
