Re: scylladb

On Sat, Mar 11, 2017 at 2:19 PM, Kant Kodali wrote: > My response is inline. > > On Sat, Mar 11, 2017 at 1:43 PM, Avi Kivity wrote: > >> There are several issues at play here. >> >> First, a database runs a large number of concurrent operations, each of >>

Re: scylladb

There is no reason to be angry. This is progress. This is the circle of live. It happens anywhere at any time. Am 12.03.2017 07:34 schrieb "Dor Laor" : > On Sat, Mar 11, 2017 at 10:02 PM, Jeff Jirsa wrote: > >> >> >> On 2017-03-10 09:57 (-0800), Rakesh

Re: scylladb

On Sat, Mar 11, 2017 at 10:02 PM, Jeff Jirsa 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 >

Re: scylladb

Why? Am 12.03.2017 07:02 schrieb "Jeff Jirsa" : > > > 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 > > > > >

Re: scylladb

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

Re: scylladb

On Sat, Mar 11, 2017 at 9:41 PM, daemeon reiydelle wrote: > Recall that garbage collection on a busy node can occur minutes or seconds > apart. Note that stop the world GC also happens as frequently as every > couple of minutes on every node. Remove that and do the simple

Re: scylladb

Recall that garbage collection on a busy node can occur minutes or seconds apart. Note that stop the world GC also happens as frequently as every couple of minutes on every node. Remove that and do the simple arithmetic. sent from my mobile Daemeon Reiydelle skype daemeon.c.m.reiydelle USA

Re: scylladb

My response is inline. On Sat, Mar 11, 2017 at 1:43 PM, Avi Kivity wrote: > There are several issues at play here. > > First, a database runs a large number of concurrent operations, each of > which only consumes a small amount of CPU. The high concurrency is need to > hide

Re: Row cache tuning

Hi, In 99% of use cases Cassandra's row cache is not something you should look into. Leveraging page cache yields good results and if accounted for can provide you with performance increase on read side. I'm not a fan of a default row cache implementation and its invalidation mechanism on updates

Re: scylladb

There are several issues at play here. First, a database runs a large number of concurrent operations, each of which only consumes a small amount of CPU. The high concurrency is need to hide latency: disk latency, or the latency of contacting a remote node. This means that the scheduler will

Re: scylladb

Here is the Java version http://docs.paralleluniverse.co/quasar/ but I still don't see how user level scheduling can be beneficial (This is a well debated problem)? How can this add to the performance? or say why is user level scheduling necessary Given the Thread per core design and the callback

Re: scylladb

Scylla uses a the seastar framework, which provides for both user-level thread scheduling and simple run-to-completion tasks. Huge pages are limited to 2MB (and 1GB, but these aren't available as transparent hugepages). On 03/11/2017 10:26 PM, Kant Kodali wrote: @Dor 1) You guys have a CPU

Re: scylladb

@Dor 1) You guys have a CPU scheduler? you mean user level thread Scheduler that maps user level threads to kernel level threads? I thought C++ by default creates native kernel threads but sure nothing will stop someone to create a user level scheduling library if that's what you are talking

Row cache tuning

Hi, I'm new to Cassandra and trying to get a better understanding on how the row cache can be tuned to optimize the performance. I came across think this article: https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html And it suggests not to even touch row

Re: scylladb

Agreed, I'd recommend to treat benchmarks as a rough guide to see where there is potential, and follow through with your own tests. On 03/11/2017 09:37 PM, Edward Capriolo wrote: Benchmarks are great for FUDly blog posts. Real world work loads matter more. Every NoSQL vendor wins their

Re: scylladb

Here's a test (by Samsung MSL) comparing Scylla to Cassandra 3.9: http://www.scylladb.com/2017/02/15/scylladb-vs-cassandra-performance-benchmark-samsung/ there's a link at the end to the original report. On 03/11/2017 09:08 PM, Bhuvan Rawal wrote: "Lastly, why don't you test Scylla yourself?

Re: scylladb

On Sat, Mar 11, 2017 at 2:08 PM, Bhuvan Rawal wrote: > "Lastly, why don't you test Scylla yourself? It's pretty easy to set up, > there's nothing to tune." > - The details are indeed compelling to have a go ahead and test it for > specific use case. > > If it works out

Re: scylladb

"Lastly, why don't you test Scylla yourself? It's pretty easy to set up, there's nothing to tune." - The details are indeed compelling to have a go ahead and test it for specific use case. If it works out good it can lead to good cost cut in infra costs as well as having to manage less servers

Re: scylladb

There is no magic 10X bullet. It's a mix of multiple factors, which can come up to less than 10X in some circumstances and more than 10X in others, as has been reported on this thread by others. TPC doesn't give _any_ advantage when you have just one core, and can give more than 10X on a

Re: scylladb

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" : > On Fri, Mar 10, 2017 at 4:45 PM, Kant Kodali wrote: > >>