WRT to #3 To fit in the existing protocol, could you have each shard listen on a different port? Drivers are likely going to support this due to https://issues.apache.org/jira/browse/CASSANDRA-7544 ( https://issues.apache.org/jira/browse/CASSANDRA-11596). I'm not super familiar with the ticket so their might be something I'm missing but it sounds like a potential approach.
This would give you a path forward at least for the short term. On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > Hi, > > I think that updating the protocol spec to Cassandra puts the onus on the > party changing the protocol specification to have an implementation of the > spec in Cassandra as well as the Java and Python driver (those are both > used in the Cassandra repo). Until it's implemented in Cassandra we haven't > fully evaluated the specification change. There is no substitute for trying > to make it work. > > There are also realities to consider as to what the maintainers of the > drivers are willing to commit. > > RE #1, > > I am +1 on the fact that we shouldn't require an extra hop for range scans. > > In JIRA Jeremiah made the point that you can still do this from the client > by breaking up the token ranges, but it's a leaky abstraction to have a > paging interface that isn't a vanilla ResultSet interface. Serial vs. > parallel is kind of orthogonal as the driver can do either. > > I agree it looks like the current specification doesn't make what should > be simple as simple as it could be for driver implementers. > > RE #2, > > +1 on this change assuming an implementation in Cassandra and the Java and > Python drivers. > > RE #3, > > It's hard to be +1 on this because we don't benefit by boxing ourselves in > by defining a spec we haven't implemented, tested, and decided we are > satisfied with. Having it in ScyllaDB de-risks it to a certain extent, but > what if Cassandra decides to go a different direction in some way? > > I don't think there is much discussion to be had without an example of the > the changes to the CQL specification to look at, but even then if it looks > risky I am not likely to be in favor of it. > > Regards, > Ariel > > On Thu, Apr 19, 2018, at 9:33 AM, glom...@scylladb.com wrote: > > > > > > On 2018/04/19 07:19:27, kurt greaves <k...@instaclustr.com> wrote: > > > > > > > > 1. The protocol change is developed using the Cassandra process in > > > > a JIRA ticket, culminating in a patch to > > > > doc/native_protocol*.spec when consensus is achieved. > > > > > > I don't think forking would be desirable (for anyone) so this seems > > > the most reasonable to me. For 1 and 2 it certainly makes sense but > > > can't say I know enough about sharding to comment on 3 - seems to me > > > like it could be locking in a design before anyone truly knows what > > > sharding in C* looks like. But hopefully I'm wrong and there are > > > devs out there that have already thought that through. > > > > Thanks. That is our view and is great to hear. > > > > About our proposal number 3: In my view, good protocol designs are > > future proof and flexible. We certainly don't want to propose a design > > that works just for Scylla, but would support reasonable > > implementations regardless of how they may look like. > > > > > > > > Do we have driver authors who wish to support both projects? > > > > > > Surely, but I imagine it would be a minority. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For > > additional commands, e-mail: dev-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Reliability at Scale Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
