Re: scylladb

On 03/12/2017 12:19 AM, 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

> If you have thread-per-core and N (logical) cores, and have M tasks > running concurrently where M > N, then you need a scheduler to decide which > of those M tasks gets to run on those N kernel threads. Whether those M > tasks are user-level threads, or callbacks, or a mix of the two is >

Re: scylladb

One more thing. Pretty much every database that is written in C++ or Java uses native kernel threads for non-blocking I/O as well. They didn't use Seaster or Quasar but anyways I am going to read up on Seaster and see what it really does. On Sun, Mar 12, 2017 at 3:48 AM, Kant Kodali

Re: Row cache tuning

Thanks, Matija! That was insightful. I don't really have a use case in particular, however, what I'm trying to do is to figure out how the Cassandra performance can be leveraged by using different caching mechanisms, such as row cache, key cache, partition summary etc. Of course, it will also

Re: A Single Dropped Node Fails Entire Read Queries

Hi Michael, If a node suddenly fails, and there are other replicas that can still satisfy the consistency level, shouldn't the request succeed regardless of the failed node? Thanks! Shalom Sagges DBA T: +972-74-700-4035

Re: scylladb

​ On Sun, Mar 12, 2017 at 2:42 PM, Bhuvan Rawal wrote: > Looking at the costs of cloud instances, it clearly appears the cost of > CPU dictates the overall cost of the instance. Having 2X more cores > increases cost by nearly 2X keeping other things same as can be seen

Re: scylladb

Looking at the costs of cloud instances, it clearly appears the cost of CPU dictates the overall cost of the instance. Having 2X more cores increases cost by nearly 2X keeping other things same as can be seen below as an example: (C3 may have slightly better processor but not more than 10-15%

Re: scylladb

@Avi I don't disagree with thread per core design and in fact I said that is a reasonable/good choice. But I am having a hard time seeing through how user level scheduling can make a significant difference even in Non-blocking I/O case. My question really is that if you already have TPC why do

Re: scylladb

btw, for an example of how user-level tasks can be scheduled in a way that cannot be done with kernel threads, see this pair of blog posts: http://www.scylladb.com/2016/04/14/io-scheduler-1/ http://www.scylladb.com/2016/04/29/io-scheduler-2/ There's simply no way to get this kind of

Re: scylladb

On Sun, Mar 12, 2017 at 12:23 AM, Avi Kivity wrote: > > > On 03/12/2017 12:19 AM, 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

Re: scylladb

If you have thread-per-core and N (logical) cores, and have M tasks running concurrently where M > N, then you need a scheduler to decide which of those M tasks gets to run on those N kernel threads. Whether those M tasks are user-level threads, or callbacks, or a mix of the two is

Re: scylladb

Sorry I made some typo's here is a better version. @Avi "User-level scheduling is great for high performance I/O intensive applications like databases and file systems." This is generally a claim made by people who want to use user-level threads but I rarely had seen any significant performance

Re: scylladb

@Avi "User-level scheduling is great for high performance I/O intensive applications like databases and file systems." This is generally a claim made by people you want to use user-level threads but I rarely had seen any significant performance gain. Since you are claiming that you do. It would

Re: scylladb

We already quantified it, the result is Scylla. Now, Scylla's performance is only in part due to the threading model, so I can't give you a number that quantifies how much just this aspect of the design is worth. Removing it (or adding it to Cassandra) is a multi-man-year effort that I can't

Re: scylladb

If someone would create a benchmark showing that Cassandra is 10x faster than Aerospike, would that mean Cassandra is 100x faster than ScyllaDB? Joking aside, I personally don't pay a lot of attention to any published benchmarks and look at them as pure marketing material. What I'm interested in

Re: scylladb

On Sun, Mar 12, 2017 at 1:38 AM, benjamin roth wrote: > 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,

Re: scylladb

On Sun, Mar 12, 2017 at 11:40 AM, Edward Capriolo wrote: > > > On Sun, Mar 12, 2017 at 1:38 AM, benjamin roth wrote: > >> There is no reason to be angry. This is progress. This is the circle of >> live. >> >> It happens anywhere at any time. >> >> Am

RE: scylladb

Will you support custom secondary indexes, triggers and UDF? I checked index code but it’s just a couple of files with commented Java code. I’m curious to test Scylladb but our application uses LWT and custom secondary indexes, I understand LWT is coming (soon?). -- Jacques-Henri Berthemet

Re: scylladb

On Sat, Mar 11, 2017 at 1:52 AM Avi Kivity wrote: > > > Lastly, why don't you test Scylla yourself? It's pretty easy to set up, > there's nothing to tune. > > Avi > I'll look seriously at Scylla when it is 3.0.12 compatible.

Incremental Repair

Hi, Our setup is as follows: 2 DCS with N nodes, RF=DC1:3,DC2:3, Hinted Handoff=3 hours, Incremental Repair scheduled once on every node (ALL DCs) within the gc grace period. I have following queries regarding incremental repairs: 1. When a node is down for X hours (where x > hinted handoff

Re: scylladb

On Sun, Mar 12, 2017 at 3:45 PM, Dor Laor wrote: > On Sun, Mar 12, 2017 at 12:11 PM, Edward Capriolo > 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. >> >>

Re: scylladb

yes. On Sun, Mar 12, 2017 at 2:01 PM, James Carman 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 wrote: > > > > On 2017-03-11

Re: scylladb

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 wrote: On 2017-03-11 22:33 (-0700), Dor Laor wrote: > On Sat, Mar 11, 2017 at 10:02 PM, Jeff Jirsa

Re: scylladb

On Sun, Mar 12, 2017 at 12:11 PM, Edward Capriolo 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 >

Re: scylladb

On 2017-03-11 22:33 (-0700), Dor Laor wrote: > 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

Repair while upgradesstables is running

Hi, What is the implication of running inc repair when all nodes have upgraded to new Cassandra rpm but parallel upgradesstables is still running on one or more of the nodes? So upgrade is like:1. Rolling upgrade of all nodes (rpm install)2. Parallel upgrade sstable on all nodes ( no issues

Re: scylladb

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)

Re: scylladb

On Sun, Mar 12, 2017 at 6:40 AM, Stefan Podkowinski wrote: > If someone would create a benchmark showing that Cassandra is 10x faster > than Aerospike, would that mean Cassandra is 100x faster than ScyllaDB? > > Joking aside, I personally don't pay a lot of attention to any

Re: scylladb

On Sun, Mar 12, 2017 at 11:15 AM, Jonathan Haddad wrote: > I don't think Jeff comes across as angry. He's simply pointing out that > ScyllaDB isn't a drop in > Agree, I take it back, it's wasn't due to this. > replacement for Cassandra. Saying that it is is very

Re: scylladb

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

Re: scylladb

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

Re: Row cache tuning

You can experiment quite easily without even needing to restart the Cassandra service. The caches (row and key) can be enabled on a table-by-table basis via a schema directive. But the cache capacity (which is the one that you referred to in your original post, set to 0 in cassandra.yaml) is a

Re: scylladb

On 2017-03-12 14:29 (-0700), James Carman 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

Re: scylladb

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

Re: Row cache tuning

I see. Thanks, Arvydas! In terms of eviction policy in the row cache, does a write operation invalidates only the row(s) which are going be modified or the whole partition? In older version of Cassandra, I believe the whole partition gets invalidated even if only one row is modified. Is that

Re: Incremental Repair

On 2017-03-12 10:44 (-0700), Anuj Wadehra wrote: > Hi, > > Our setup is as follows: > 2 DCS with N nodes, RF=DC1:3,DC2:3, Hinted Handoff=3 hours, Incremental > Repair scheduled once on every node (ALL DCs) within the gc grace period. > > I have following queries