> Datastax, Apple, Instaclstr, > thelastpickle and everyone else > receive different benefits You have mentioned a variety of vendors who received benefits while making major contributions back to the project. Comparing Scylla's relationship to the Cassandra ecosystem to this list is a false equivalency, and honestly one of the sillier things I've seen on this mailing list.
> The C* ecosystem can either shrink or expand. We offer to expand it. Your company has not established a precedent for this, whatsoever, since its inception. Forgive those of us that don't take you at face value with this claim. On Mon, Apr 23, 2018, 8:54 PM Dor Laor <d...@scylladb.com> wrote: > On Mon, Apr 23, 2018 at 5:28 PM, Josh McKenzie <jmcken...@apache.org> > wrote: > > > > it's not > > > reasonable to expect Scylla to contribute > > > such a huge effort to the C* server > > > > But it's reasonable that a major portion of Scylla's business model is > > profiting off those huge efforts other companies have made? > > > > Seems a little hypocritical to me. > > > > We're an open source based vendor, it's not a secret. > Last I checked, all participates on the thread should get business benefits > and we all > got benefits from following the Dynamo/BigTable path. > We never zig-zaged and have very consistent open source approach. > > We're all here to make some type of profit. > Datastax, Apple, Instaclstr, thelastpickle and everyone else receive > different benefits, > from PR benefits, commercial benefits, service credibility, expertise > benefits, personal > carrier benefits and fun too. > > The C* ecosystem can either shrink or expand. We offer to expand it. > > > > > > > > On Mon, Apr 23, 2018, 8:18 PM Dor Laor <d...@scylladb.com> wrote: > > > > > On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli <kohlisank...@gmail.com > > > > > wrote: > > > > > > > Is one of the “abuse” of Apache license is ScyllaDB which is using > > > > Cassandra but not contributing back? > > > > > > > > > > It's not that we have a private version of Cassandra and we don't > release > > > all of it or some of it back.. > > > > > > We didn't contribute because we have a different server base. We always > > > contribute where it makes sense. > > > I'll be happy to have several beers or emails about the cons and pros > of > > > open source licensing but I don't think > > > this is the case. The discussion is about whether the community wish to > > > accept our contributions, we initiated it, > > > didn't we? > > > > > > Let's be practical, I think it's not reasonable to commit C* protocol > > > changes that the community doesn't intend > > > to implement in C* in the short term (thread-per-core like), it's not > > > reasonable to expect Scylla to contribute > > > such a huge effort to the C* server. It is reasonable to collaborate > > around > > > protocol enhancements that are acceptable, > > > even without coding and make sure the protocol is enhanceable in a way > > that > > > forward compatible. > > > > > > > > > Happy to be proved wrong as I am not a lawyer and don’t understand > > various > > > > licenses .. > > > > > > > > > On Apr 23, 2018, at 16:55, Dor Laor <d...@scylladb.com> wrote: > > > > > > > > > >> On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad < > j...@jonhaddad.com > > > > > > > wrote: > > > > >> > > > > >> From where I stand it looks like you've got only two options for > any > > > > >> feature that involves updating the protocol: > > > > >> > > > > >> 1. Don't built the feature > > > > >> 2. Built it in Cassanda & scylladb, update the drivers accordingly > > > > >> > > > > >> I don't think you have a third option, which is built it only in > > > > ScyllaDB, > > > > >> because that means you have to fork *all* the drivers and make it > > > work, > > > > >> then maintain them. Your business model appears to be built on > not > > > > doing > > > > >> any of the driver work yourself, and you certainly aren't giving > > back > > > to > > > > >> the open source community via a permissive license on ScyllaDB > > itself, > > > > so > > > > >> I'm a bit lost here. > > > > >> > > > > > > > > > > It's totally not about business model. > > > > > Scylla itself is 99% open source with AGPL license that prevents > > abuse > > > > and > > > > > forces to be committed back to the project. We also have our core > > > engine > > > > > (seastar) licensed > > > > > as Apache since it needs to be integrated with the core > application. > > > > > Recently one of our community members even created a new Seastar > > based, > > > > C++ > > > > > driver. > > > > > > > > > > Scylla chose to be compatible with the drivers in order to leverage > > the > > > > > existing infrastructure > > > > > and (let's be frank) in order to allow smooth migration. > > > > > We would have loved to contribute more to the drivers but up to > > > recently > > > > we: > > > > > 1. Were busy on top of our heads with the server > > > > > 2. Happy w/ the existing drivers > > > > > 3. Developed extensions - GoCQLX - our own contribution > > > > > > > > > > Finally we can contribute back to the same driver project, we want > to > > > do > > > > it > > > > > the right way, > > > > > without forking and without duplicated efforts. > > > > > > > > > > Many times, having a private fork is way easier than proper open > > source > > > > > work so from > > > > > a pure business perspective, we don't select the shortest path. > > > > > > > > > > > > > > >> > > > > >> To me it looks like you're asking a bunch of volunteers that work > on > > > > >> Cassandra to accommodate you. What exactly do we get out of this > > > > >> relationship? What incentive do I or anyone else have to spend > time > > > > >> helping you instead of working on something that interests me? > > > > >> > > > > > > > > > > Jon, this is certainty not the case. > > > > > We genuinely wish to make true *open source* work on: > > > > > a. Cassandra drivers > > > > > b. Client protocol > > > > > c. Scylla server side. > > > > > d. Cassandra community related work: mailing list, Jira, design > > > > > > > > > > But not > > > > > e. Cassandra server side > > > > > > > > > > While I wouldn't mind doing the Cassandra server work, we don't > have > > > the > > > > > resources or > > > > > the expertise. The Cassandra _developer_ community is welcome to > > decide > > > > > whether > > > > > we get to contribute a/b/c/d. Avi has enumerated the options of > > > > > cooperation, passive cooperation > > > > > and zero cooperation (below). > > > > > > > > > > 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. > > > > > 2. The protocol change is developed outside the Cassandra process. > > > > > 3. No cooperation. > > > > > > > > > > Look, I can understand the hostility and suspicious, however, from > > the > > > C* > > > > > project POV, it makes no > > > > > sense to ignore, otherwise we'll fork the drivers and you won't get > > > > > anything back. There is another > > > > > at least one vendor today with their server fork and driver fork > and > > it > > > > > makes sense to keep the protocol > > > > > unified in an extensible way and to discuss new features > _together_. > > > > > > > > > > > > > > > > > > > >> > > > > >> Jon > > > > >> > > > > >> > > > > >> On Mon, Apr 23, 2018 at 7:59 AM Ben Bromhead <b...@instaclustr.com > > > > > > wrote: > > > > >> > > > > >>>>>> This doesn't work without additional changes, for RF>1. The > > token > > > > >> ring > > > > >>>> could place two replicas of the same token range on the same > > > physical > > > > >>>> server, even though those are two separate cores of the same > > server. > > > > >> You > > > > >>>> could add another element to the hierarchy (cluster -> > datacenter > > -> > > > > >> rack > > > > >>>> -> node -> core/shard), but that generates unneeded range > > movements > > > > >> when > > > > >>> a > > > > >>>> node is added. > > > > >>>>> I have seen rack awareness used/abused to solve this. > > > > >>>>> > > > > >>>> > > > > >>>> But then you lose real rack awareness. It's fine for a quick > hack, > > > but > > > > >>>> not a long-term solution. > > > > >>>> > > > > >>>> (it also creates a lot more tokens, something nobody needs) > > > > >>>> > > > > >>> > > > > >>> I'm having trouble understanding how you loose "real" rack > > awareness, > > > > as > > > > >>> these shards are in the same rack anyway, because the address and > > > port > > > > >> are > > > > >>> on the same server in the same rack. So it behaves as expected. > > Could > > > > you > > > > >>> explain a situation where the shards on a single server would be > in > > > > >>> different racks (or fault domains)? > > > > >>> > > > > >>> If you wanted to support a situation where you have a single rack > > per > > > > DC > > > > >>> for simple deployments, extending NetworkTopologyStrategy to > behave > > > the > > > > >> way > > > > >>> it did before > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues. > > apache.org_jira_browse_CASSANDRA-2D7544&d=DwIFaQ&c= > > adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=- > > KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=01FsBvCihZndkHTmett65RHyy- > > gs8IQENF-wXOTdbD0&e= > > > > with > > > > >>> respect to treating InetAddresses as servers rather than the > > address > > > > and > > > > >>> port would be simple. Both this implementation in Apache > Cassandra > > > and > > > > >> the > > > > >>> respective load balancing classes in the drivers are explicitly > > > > designed > > > > >> to > > > > >>> be pluggable so that would be an easier integration point for > you. > > > > >>> > > > > >>> I'm not sure how it creates more tokens? If a server normally > owns > > > 256 > > > > >>> tokens, each shard on a different port would just advertise > > ownership > > > > of > > > > >>> 256/# of cores (e.g. 4 tokens if you had 64 cores). > > > > >>> > > > > >>> > > > > >>>> > > > > >>>>> Regards, > > > > >>>>> Ariel > > > > >>>>> > > > > >>>>>> On Apr 22, 2018, at 8:26 AM, Avi Kivity <a...@scylladb.com> > > wrote: > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>> On 2018-04-19 21:15, Ben Bromhead wrote: > > > > >>>>>>> Re #3: > > > > >>>>>>> > > > > >>>>>>> Yup I was thinking each shard/port would appear as a discrete > > > > >> server > > > > >>>> to the > > > > >>>>>>> client. > > > > >>>>>> This doesn't work without additional changes, for RF>1. The > > token > > > > >> ring > > > > >>>> could place two replicas of the same token range on the same > > > physical > > > > >>>> server, even though those are two separate cores of the same > > server. > > > > >> You > > > > >>>> could add another element to the hierarchy (cluster -> > datacenter > > -> > > > > >> rack > > > > >>>> -> node -> core/shard), but that generates unneeded range > > movements > > > > >> when > > > > >>> a > > > > >>>> node is added. > > > > >>>>>> > > > > >>>>>>> If the per port suggestion is unacceptable due to hardware > > > > >>>> requirements, > > > > >>>>>>> remembering that Cassandra is built with the concept scaling > > > > >>>> *commodity* > > > > >>>>>>> hardware horizontally, you'll have to spend your time and > > energy > > > > >>>> convincing > > > > >>>>>>> the community to support a protocol feature it has no > (current) > > > use > > > > >>>> for or > > > > >>>>>>> find another interim solution. > > > > >>>>>> Those servers are commodity servers (not x86, but still > > > commodity). > > > > >> In > > > > >>>> any case 60+ logical cores are common now (hello AWS i3.16xlarge > > or > > > > >> even > > > > >>>> i3.metal), and we can only expect logical core count to continue > > to > > > > >>>> increase (there are 48-core ARM processors now). > > > > >>>>>> > > > > >>>>>>> Another way, would be to build support and consensus around a > > > clear > > > > >>>>>>> technical need in the Apache Cassandra project as it stands > > > today. > > > > >>>>>>> > > > > >>>>>>> One way to build community support might be to contribute an > > > Apache > > > > >>>>>>> licensed thread per core implementation in Java that matches > > the > > > > >>>> protocol > > > > >>>>>>> change and shard concept you are looking for ;P > > > > >>>>>> I doubt I'll survive the egregious top-posting that is going > on > > in > > > > >>> this > > > > >>>> list. > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>>> On Thu, Apr 19, 2018 at 1:43 PM Ariel Weisberg < > > > ar...@weisberg.ws > > > > >>> > > > > >>>> wrote: > > > > >>>>>>>> > > > > >>>>>>>> Hi, > > > > >>>>>>>> > > > > >>>>>>>> So at technical level I don't understand this yet. > > > > >>>>>>>> > > > > >>>>>>>> So you have a database consisting of single threaded shards > > and > > > a > > > > >>>> socket > > > > >>>>>>>> for accept that is generating TCP connections and in advance > > you > > > > >>>> don't know > > > > >>>>>>>> which connection is going to send messages to which shard. > > > > >>>>>>>> > > > > >>>>>>>> What is the mechanism by which you get the packets for a > given > > > TCP > > > > >>>>>>>> connection delivered to a specific core? I know that a given > > TCP > > > > >>>> connection > > > > >>>>>>>> will normally have all of its packets delivered to the same > > > queue > > > > >>>> from the > > > > >>>>>>>> NIC because the tuple of source address + port and > destination > > > > >>>> address + > > > > >>>>>>>> port is typically hashed to pick one of the queues the NIC > > > > >>> presents. I > > > > >>>>>>>> might have the contents of the tuple slightly wrong, but it > > > always > > > > >>>> includes > > > > >>>>>>>> a component you don't get to control. > > > > >>>>>>>> > > > > >>>>>>>> Since it's hashing how do you manipulate which queue packets > > > for a > > > > >>> TCP > > > > >>>>>>>> connection go to and how is it made worse by having an > accept > > > > >> socket > > > > >>>> per > > > > >>>>>>>> shard? > > > > >>>>>>>> > > > > >>>>>>>> You also mention 160 ports as bad, but it doesn't sound > like a > > > big > > > > >>>> number > > > > >>>>>>>> resource wise. Is it an operational headache? > > > > >>>>>>>> > > > > >>>>>>>> RE tokens distributed amongst shards. The way that would > work > > > > >> right > > > > >>>> now is > > > > >>>>>>>> that each port number appears to be a discrete instance of > the > > > > >>>> server. So > > > > >>>>>>>> you could have shards be actual shards that are simply > > colocated > > > > >> on > > > > >>>> the > > > > >>>>>>>> same box, run in the same process, and share resources. I > know > > > > >> this > > > > >>>> pushes > > > > >>>>>>>> more of the complexity into the server vs the driver as the > > > server > > > > >>>> expects > > > > >>>>>>>> all shards to share some client visible like system tables > and > > > > >>> certain > > > > >>>>>>>> identifiers. > > > > >>>>>>>> > > > > >>>>>>>> Ariel > > > > >>>>>>>>> On Thu, Apr 19, 2018, at 12:59 PM, Avi Kivity wrote: > > > > >>>>>>>>> Port-per-shard is likely the easiest option but it's too > ugly > > > to > > > > >>>>>>>>> contemplate. We run on machines with 160 shards (IBM POWER > > > > >>> 2s20c160t > > > > >>>>>>>>> IIRC), it will be just horrible to have 160 open ports. > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> It also doesn't fit will with the NICs ability to > > automatically > > > > >>>>>>>>> distribute packets among cores using multiple queues, so > the > > > > >> kernel > > > > >>>>>>>>> would have to shuffle those packets around. Much better to > > have > > > > >>> those > > > > >>>>>>>>> packets delivered directly to the core that will service > > them. > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> (also, some protocol changes are needed so the driver knows > > how > > > > >>>> tokens > > > > >>>>>>>>> are distributed among shards) > > > > >>>>>>>>> > > > > >>>>>>>>>> On 2018-04-19 19:46, Ben Bromhead wrote: > > > > >>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__issues. > > apache.org_jira_browse_CASSANDRA-2D7544&d=DwIFaQ&c= > > adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=- > > KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=01FsBvCihZndkHTmett65RHyy- > > gs8IQENF-wXOTdbD0&e= > > > ( > > > > >>>>>>>>>> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues. > > apache.org_jira_browse_CASSANDRA-2D11596&d=DwIFaQ&c= > > adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=- > > KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=RggcL9lWBe5uDAPbMWW4S_7- > > ZzYVctqUA5W6GYSwBm4&e=). > > > 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-unsubscribe@cassandra. > > apache.org > > > > >>>>>>>>>>> For additional commands, e-mail: > > > dev-h...@cassandra.apache.org > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> -- > > > > >>>>>>>>>> Ben Bromhead > > > > >>>>>>>>>> CTO | Instaclustr < > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > > instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r= > > qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0- > > uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_- > IczFSSyqkEQqOAjnyZBgb4iUeug&e= > > > > > > > > >>>>>>>>>> +1 650 284 9692 <(650)%20284-9692> <(650)%20284-9692> > > > > >>> <(650)%20284-9692> > > > > >>>>>>>>>> Reliability at Scale > > > > >>>>>>>>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and > > > Softlayer > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>> ------------------------------------------------------------ > > --------- > > > > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra. > apache.org > > > > >>>>>>>>> For additional commands, e-mail: > > dev-h...@cassandra.apache.org > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>> ------------------------------------------------------------ > > --------- > > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra. > apache.org > > > > >>>>>>>> For additional commands, e-mail: > > dev-h...@cassandra.apache.org > > > > >>>>>>>> > > > > >>>>>>>> -- > > > > >>>>>>> Ben Bromhead > > > > >>>>>>> CTO | Instaclustr < > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > > instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r= > > qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0- > > uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_- > IczFSSyqkEQqOAjnyZBgb4iUeug&e= > > > > > > > > >>>>>>> +1 650 284 9692 <(650)%20284-9692> <(650)%20284-9692> > > > > >>>>>>> Reliability at Scale > > > > >>>>>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and > > Softlayer > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> ------------------------------------------------------------ > > > > >> --------- > > > > >>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www. > > instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r= > > qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0- > > uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_- > IczFSSyqkEQqOAjnyZBgb4iUeug&e= > > > > > > > > >>> +1 650 284 9692 <(650)%20284-9692> > > > > >>> Reliability at Scale > > > > >>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer > > > > >>> > > > > >> > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > >
