cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From benjamin roth <brs...@gmail.com>
Subject Re: scylladb
Date Sat, 11 Mar 2017 07:59:02 GMT
Thanks a lot for your detailed explanation!
I am very curious about the future development of Scylladb! Especially
about mvs and lwt!

Am 11.03.2017 02:05 schrieb "Dor Laor" <dor@scylladb.com>:

> On Fri, Mar 10, 2017 at 4:45 PM, Kant Kodali <kant@peernova.com> wrote:
>
>> http://performanceterracotta.blogspot.com/2012/09/numa-java.html
>> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per
>> formance-enhancements-7.html
>> http://openjdk.java.net/jeps/163
>>
>>
> Java can exploit NUMA but it's not as a efficient as can be done in c++.
> Andrea Arcangeli is the engineer behind Linux transparent huge pages(THP),
> he
> reported to me and the idea belongs to Avi. We did it for KVM's sake but
> it was designed to any long running process like Cassandra.
> However, the entire software stack should be aware. If you get a huge page
> (2MB)
> but keep in it only 1KB you waste lots of mem. On top of this, threads
> need to
> touch their data structures and they need to be well aligned, otherwise
> the memory
> page will bounce between the different cores.
> With Cassandra it gets more complicated since there is a heap and off-heap
> data.
>
> Do programmers really track their data alignment? I doubt it.
> Do users run C* with the JVM numa options and the right Linux THP options?
> Again, I doubt.
>
> Scylla on the other side is designed for NUMA. We have 2-level sharding.
> The inner shards are transparent
> to the user and are per-core (hyper thread). Such a shard access RAM only
> within its numa node. Memory
> is bonded to each thread/numa node. We have our own malloc allocator built
> for this scheme.
>
>
>
>> If scyllaDB has efficient Secondary indexes, LWT and MV's then that is
>> something. I would be glad to see how they perform.
>>
>>
> MV will be in 1.8, we haven't measured performance yet. We did measure our
> counter implementation
> and it looks promising (4X better throughput and 4X better latency on a
> 8-core machine).
> The not-written yet LWT will kick-a** since our fully async engine is
> ideal for the larger number
> of round trips the LWT needs.
>
> This is with the Linux tcp stack, once we'll use our dpdk one, performance
> will improve further ;)
>
>
>
>>
>> On Fri, Mar 10, 2017 at 10:45 AM, Dor Laor <dor@scylladb.com> wrote:
>>
>>> Scylla isn't just about performance too.
>>>
>>> First, a disclaimer, I am a Scylla co-founder. I respect open source a
>>> lot,
>>> so you guys are welcome to shush me out of this thread. I only
>>> participate
>>> to provide value if I can (this is a thread about Scylla and our users
>>> are
>>> on our mailing list).
>>>
>>> Scylla is all about what Cassandra is plus:
>>>  - Efficient hardware utilization (scale-up, performance)
>>>  - Low tail latency
>>>  - Auto/dynamic tuning (no JVM tuning, we tune the OS ourselves, we have
>>> cpu scheduler,
>>>    I/O userspace scheduler and more to come).
>>>  - SLA between compaction, repair, streaming and your r/w operations
>>>
>>> We started with a great foundation (C*) and wish to improve almost any
>>> aspect of it.
>>> Admittedly, we're way behind C* in terms of adoption. One need to start
>>> somewhere.
>>> However, users such as AppNexus run Scylla in production with 47
>>> physical nodes
>>> across 5 datacenters and their VP estimate that C* would have at least
>>> doubled the
>>> size. So this is equal for a 100-node C* cluster. Since we have the same
>>> gossip, murmur3 hash,
>>> CQL, nothing stops us to scale to 1,000 nodes. Another user (Mogujie)
>>> run 10s of TBs per node(!)
>>> in production.
>>>
>>> Also, since we try to compare Scylla and C* in a fair way, we invested a
>>> great deal of time
>>> to run C*. I can say it's not simple at all.
>>> Lastly, in a couple of months we'll reach parity in functionality with
>>> C* (counters are in 1.7 as experimental, in 1.8 counters will be stable and
>>> we'll have MV as experimental, LWT will be
>>> in the summer). We hope to collaborate with the C* community with the
>>> development of future
>>> features.
>>>
>>> Dor
>>>
>>>
>>> On Fri, Mar 10, 2017 at 10:19 AM, Jacques-Henri Berthemet <
>>> jacques-henri.berthemet@genesys.com> wrote:
>>>
>>>> Cassandra is not about pure performance, there are many other DBs that
>>>> are much faster than Cassandra. Cassandra strength is all about
>>>> scalability, performance increases in a linear way as you add more nodes.
>>>> During Cassandra summit 2014 Apple said they have a 10k node cluster. The
>>>> usual limiting factor is your disk write speed and latency, I don’t see
how
>>>> C++ changes anything in this regard unless you can cache all your data in
>>>> memory.
>>>>
>>>>
>>>>
>>>> I’d be curious to know how ScyllaDB performs with a 100+ nodes cluster
>>>> with PBs of data compared to Cassandra.
>>>>
>>>> *--*
>>>>
>>>> *Jacques-Henri Berthemet*
>>>>
>>>>
>>>>
>>>> *From:* Rakesh Kumar [mailto:rakeshkumar464@outlook.com]
>>>> *Sent:* vendredi 10 mars 2017 09:58
>>>>
>>>> *To:* user@cassandra.apache.org
>>>> *Subject:* Re: scylladb
>>>>
>>>>
>>>>
>>>> Cassanda vs Scylla is a valid comparison because they both are
>>>> compatible.  Scylla is a drop-in replacement for Cassandra.
>>>> Is Aerospike a drop-in replacement for Cassandra? If yes, and only if
>>>> yes, then the comparison is valid with Scylla.
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> *From:* Bhuvan Rawal <bhu1rawal@gmail.com>
>>>> *To:* user@cassandra.apache.org
>>>> *Sent:* Friday, March 10, 2017 11:59 AM
>>>> *Subject:* Re: scylladb
>>>>
>>>>
>>>>
>>>> Agreed C++ gives an added advantage to talk to underlying hardware with
>>>> better efficiency, it sound good but can a pice of code written in C++ give
>>>> 1000% throughput than a Java app? Is TPC design 10X more performant than
>>>> SEDA arch?
>>>>
>>>>
>>>>
>>>> And if C/C++ is indeed that fast how can Aerospike (which is itself
>>>> written in C) claim to be 10X faster than Scylla here
>>>> http://www.aerospike.com/benchmarks/scylladb-initial/ ? (Combining
>>>> your's and aerospike's benchmarks it appears that Aerospike is 100X
>>>> performant than C* - I highly doubt that!! )
>>>>
>>>>
>>>>
>>>> For a moment lets forget about evaluating 2 different databases, one
>>>> can observe 10X performance difference between a mistuned cassandra cluster
>>>> and one thats tuned as per data model - there are so many Tunables in yaml
>>>> as well as table configs.
>>>>
>>>>
>>>>
>>>> Idea is - in order to strengthen your claim, you need to provide
>>>> complete system metrics (Disk, CPU, Network), the OPS increase starts to
>>>> decay along with the configs used. Having plain ops per second and 99p
>>>> latency is blackbox.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Bhuvan
>>>>
>>>>
>>>>
>>>> On Fri, Mar 10, 2017 at 12:47 PM, Avi Kivity <avi@scylladb.com> wrote:
>>>>
>>>> ScyllaDB engineer here.
>>>>
>>>> C++ is really an enabling technology here. It is directly responsible
>>>> for a small fraction of the gain by executing faster than Java.  But it is
>>>> indirectly responsible for the gain by allowing us direct control over
>>>> memory and threading.  Just as an example, Scylla starts by taking over
>>>> almost all of the machine's memory, and dynamically assigning it to
>>>> memtables, cache, and working memory needed to handle requests in flight.
>>>> Memory is statically partitioned across cores, allowing us to exploit NUMA
>>>> fully.  You can't do these things in Java.
>>>>
>>>> I would say the major contributors to Scylla performance are:
>>>>  - thread-per-core design
>>>>  - replacement of the page cache with a row cache
>>>>  - careful attention to many small details, each contributing a little,
>>>> but with a large overall impact
>>>>
>>>> While I'm here I can say that performance is not the only goal here, it
>>>> is stable and predictable performance over varying loads and during
>>>> maintenance operations like repair, without any special tuning.  We measure
>>>> the amount of CPU and I/O spent on foreground (user) and background
>>>> (maintenance) tasks and divide them fairly.  This work is not complete but
>>>> already makes operating Scylla a lot simpler.
>>>>
>>>>
>>>>
>>>> On 03/10/2017 01:42 AM, Kant Kodali wrote:
>>>>
>>>> I dont think ScyllaDB performance is because of C++. The design
>>>> decisions in scylladb are indeed different from Cassandra such as getting
>>>> rid of SEDA and moving to TPC and so on.
>>>>
>>>>
>>>>
>>>> If someone thinks it is because of C++ then just show the benchmarks
>>>> that proves it is indeed the C++ which gave 10X performance boost as
>>>> ScyllaDB claims instead of stating it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 9, 2017 at 3:22 PM, Richard L. Burton III <
>>>> mrburton@gmail.com> wrote:
>>>>
>>>> They spend an enormous amount of time focusing on performance. You can
>>>> expect them to continue on with their optimization and keep crushing it.
>>>>
>>>>
>>>>
>>>> P.S., I don't work for ScyllaDB.
>>>>
>>>>
>>>>
>>>> On Thu, Mar 9, 2017 at 6:02 PM, Rakesh Kumar <
>>>> rakeshkumar464@outlook.com> wrote:
>>>>
>>>> In all of their presentation they keep harping on the fact that
>>>> scylladb is written in C++ and does not carry the overhead of Java.  Still
>>>> the difference looks staggering.
>>>> ______________________________ __________
>>>> From: daemeon reiydelle <daemeonr@gmail.com>
>>>> Sent: Thursday, March 9, 2017 14:21
>>>> To: user@cassandra.apache.org
>>>> Subject: Re: scylladb
>>>>
>>>> The comparison is fair, and conservative. Did substantial performance
>>>> comparisons for two clients, both results returned throughputs that were
>>>> faster than the published comparisons (15x as I recall). At that time the
>>>> client preferred to utilize a Cass COTS solution and use a caching solution
>>>> for OLA compliance.
>>>>
>>>>
>>>> .......
>>>>
>>>> Daemeon C.M. Reiydelle
>>>> USA (+1) 415.501.0198 <+1%20415-501-0198>
>>>> London (+44) (0) 20 8144 9872 <+44%2020%208144%209872>
>>>>
>>>> On Thu, Mar 9, 2017 at 11:04 AM, Robin Verlangen <robin@us2.nl<mailto:robin@us2
>>>> .nl <robin@us2.nl>>> wrote:
>>>> I was wondering how people feel about the comparison that's made here
>>>> between Cassandra and ScyllaDB : http://www.scylladb.com/techno
>>>> logy/ycsb-cassandra-scylla/#re sults-of-3-scylla-nodes-vs-30-
>>>> cassandra-nodes
>>>> <http://www.scylladb.com/technology/ycsb-cassandra-scylla/#results-of-3-scylla-nodes-vs-30-cassandra-nodes>
>>>>
>>>> They are claiming a 10x improvement, is that a fair comparison or maybe
>>>> a somewhat coloured view of a (micro)benchmark in a specific setup? Any
>>>> pros/cons known?
>>>>
>>>> Best regards,
>>>>
>>>> Robin Verlangen
>>>> Chief Data Architect
>>>>
>>>> Disclaimer: The information contained in this message and attachments
>>>> is intended solely for the attention and use of the named addressee and may
>>>> be confidential. If you are not the intended recipient, you are reminded
>>>> that the information remains the property of the sender. You must not use,
>>>> disclose, distribute, copy, print or rely on this e-mail. If you have
>>>> received this message in error, please contact the sender immediately and
>>>> irrevocably delete this message and any copies.
>>>>
>>>> On Wed, Dec 16, 2015 at 11:52 AM, Carlos Rolo <rolo@pythian.com<mailto:rolo@
>>>> pythian.com <rolo@pythian.com>>> wrote:
>>>> No rain at all! But I almost had it running last weekend, but stopped
>>>> short of installing it. Let's see if this one is for real!
>>>>
>>>> Regards,
>>>>
>>>> Carlos Juzarte Rolo
>>>> Cassandra Consultant
>>>>
>>>> Pythian - Love your data
>>>>
>>>> rolo@pythian | Twitter: @cjrolo | Linkedin: linkedin.com/in/carlosjuzarter
>>>> olo <http://linkedin.com/in/carlosjuzarterolo><http://linkedin.com/in/car
>>>> losjuzarterolo <http://linkedin.com/in/carlosjuzarterolo>>
>>>> Mobile: +351 91 891 81 00 <+351%20918%20918%20100><
>>>> tel:+351%20918%20918%20100 <+351%20918%20918%20100>> | Tel: +1 613
565
>>>> 8696 x1649 <+1%20613-565-8696><tel:+1%20613-565-8696
>>>> <+1%20613-565-8696>>
>>>> www.pythian.com<http://www.pyt hian.com/ <http://www.pythian.com/>>
>>>>
>>>> On Wed, Dec 16, 2015 at 12:38 AM, Dani Traphagen <
>>>> dani.traphagen@datastax.com<m ailto:dani.traphagen@datastax. com
>>>> <dani.traphagen@datastax.com>>> wrote:
>>>> You'll be the first Carlos.
>>>>
>>>> [Inline image 1]
>>>>
>>>> Had any rain lately? Curious how this went, if so.
>>>>
>>>> On Thu, Nov 12, 2015 at 4:36 AM, Jack Krupansky <
>>>> jack.krupansky@gmail.com<mail to:jack.krupansky@gmail.com>> wrote:
>>>> I just did a Twitter search on scylladb and did not see any tweets
>>>> about actual use, so far.
>>>>
>>>>
>>>> -- Jack Krupansky
>>>>
>>>> On Wed, Nov 11, 2015 at 10:54 AM, Carlos Alonso <info@mrcalonso.com
>>>> <mailto:inf o@mrcalonso.com <info@mrcalonso.com>>> wrote:
>>>> Any update about this?
>>>>
>>>> @Carlos Rolo, did you tried it? Thoughts?
>>>>
>>>> Carlos Alonso | Software Engineer | @calonso<https://twitter.com/c
>>>> alonso <https://twitter.com/calonso>>
>>>>
>>>> On 5 November 2015 at 14:07, Carlos Rolo <rolo@pythian.com<mailto:rolo@
>>>> pythian.com <rolo@pythian.com>>> wrote:
>>>> Something to do on a expected rainy weekend. Thanks for the information.
>>>>
>>>> Regards,
>>>>
>>>> Carlos Juzarte Rolo
>>>> Cassandra Consultant
>>>>
>>>> Pythian - Love your data
>>>>
>>>> rolo@pythian | Twitter: @cjrolo | Linkedin: linkedin.com/in/carlosjuzarter
>>>> olo <http://linkedin.com/in/carlosjuzarterolo><http://linkedin.com/in/car
>>>> losjuzarterolo <http://linkedin.com/in/carlosjuzarterolo>>
>>>> Mobile: +351 91 891 81 00 <+351%20918%20918%20100><tel:%2B351%2091%20891%2081%
>>>> 2000 <%2B351%2091%20891%2081%25%202000>> | Tel: +1 613 565 8696
x1649
>>>> <+1%20613-565-8696><tel:%2B1%20613%20565%208 696%20x1649
>>>> <%2B1%20613%20565%208%20696%20x1649>>
>>>> www.pythian.com<http://www.pyt hian.com/ <http://www.pythian.com/>>
>>>>
>>>> On Thu, Nov 5, 2015 at 12:07 PM, Dani Traphagen <
>>>> dani.traphagen@datastax.com<m ailto:dani.traphagen@datastax. com
>>>> <dani.traphagen@datastax.com>>> wrote:
>>>> As of two days ago, they say they've got it @cjrolo.
>>>>
>>>> https://github.com/scylladb/sc ylla/wiki/RELEASE-Scylla-0.11- Beta
>>>> <https://github.com/scylladb/scylla/wiki/RELEASE-Scylla-0.11-Beta>
>>>>
>>>>
>>>> On Thursday, November 5, 2015, Carlos Rolo <rolo@pythian.com<mailto:rolo@
>>>> pythian.com <rolo@pythian.com>>> wrote:
>>>> I will not try until multi-DC is implemented. More than an month has
>>>> passed since I looked for it, so it could possibly be in place, if so I may
>>>> take some time to test it.
>>>>
>>>> Regards,
>>>>
>>>> Carlos Juzarte Rolo
>>>> Cassandra Consultant
>>>>
>>>> Pythian - Love your data
>>>>
>>>> rolo@pythian | Twitter: @cjrolo | Linkedin: linkedin.com/in/carlosjuzarter
>>>> olo <http://linkedin.com/in/carlosjuzarterolo><http://linkedin.com/in/car
>>>> losjuzarterolo <http://linkedin.com/in/carlosjuzarterolo>>
>>>> Mobile: +351 91 891 81 00 <+351%20918%20918%20100><tel:%2B351%2091%20891%2081%
>>>> 2000 <%2B351%2091%20891%2081%25%202000>> | Tel: +1 613 565 8696
x1649
>>>> <+1%20613-565-8696><tel:%2B1%20613%20565%208 696%20x1649
>>>> <%2B1%20613%20565%208%20696%20x1649>>
>>>> www.pythian.com<http://www.pyt hian.com/ <http://www.pythian.com/>>
>>>>
>>>> On Thu, Nov 5, 2015 at 9:37 AM, Jon Haddad <jonathan.haddad@gmail.com>
>>>> wrote:
>>>> Nope, no one I know.  Let me know if you try it I'd love to hear your
>>>> feedback.
>>>>
>>>> > On Nov 5, 2015, at 9:22 AM, tommaso barbugli <tbarbugli@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi guys,
>>>> >
>>>> > did anyone already try Scylladb (yet another fastest NoSQL database
>>>> in town) and has some thoughts/hands-on experience to share?
>>>> >
>>>> > Cheers,
>>>> > Tommaso
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> [datastax_logo.png]<http://www .datastax.com/
>>>> <http://www.datastax.com/>>
>>>>
>>>> DANI TRAPHAGEN
>>>>
>>>> Technical Enablement Lead | dani.traphagen@datastax.com<ma ilto:dani.traphagen@datastax.c
>>>> om <dani.traphagen@datastax.com>>
>>>>
>>>> [twitter.png]<https://twitter. com/dtrapezoid
>>>> <https://twitter.com/dtrapezoid>> [linkedin.png] <https://www.linkedin.com/pub/
>>>> dani-traphagen/31/93b/b85
>>>> <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>>  [https://lh5.googleusercontent
>>>> .com/WcFJcWZHKXnxu01V6zJIQapcG onoazqsv8O7_DtfhW-qbTRHxDjfX2o
>>>> wDNmQhgojRx5Y4mLEc-KiAeeTJjT0V mKiiIld8UP86AgQPJDK2o6oC6BhTmu
>>>> b4NLZ_MO9-E7l9Q
>>>> <https://lh5.googleusercontent.com/WcFJcWZHKXnxu01V6zJIQapcGonoazqsv8O7_DtfhW-qbTRHxDjfX2owDNmQhgojRx5Y4mLEc-KiAeeTJjT0VmKiiIld8UP86AgQPJDK2o6oC6BhTmub4NLZ_MO9-E7l9Q>]
>>>> <https://github.com/dtrapezoid >
>>>>
>>>> [http://datastax.com/all/image s/cs_logo_color_sm.png
>>>> <http://datastax.com/all/images/cs_logo_color_sm.png>]
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> -Richard L. Burton III
>>>>
>>>> @rburton
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>

Mime
View raw message