osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evolving the client protocol


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 <ariel@xxxxxxxxxxx> 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, glommer@xxxxxxxxxxxx wrote:
> >
> >
> > On 2018/04/19 07:19:27, kurt greaves <kurt@xxxxxxxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx For
> > additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>
> --
Ben Bromhead
CTO | Instaclustr <https://www.instaclustr.com/>
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer