Re: [VOTE] Release 0.6.0-beta3
+1 On Wed, Mar 17, 2010 at 3:17 PM, Gary Dusbabek wrote: > +1 > > On Wed, Mar 17, 2010 at 14:17, Eric Evans wrote: > > > > It's been a bit since the last beta, and while many important fixes have > > made their way in[1], we're still not quite ready to roll a release > > candidate. I propose one more beta in order to get some of this new work > > tested while we're closing out the remaining issues[2]. > > > > Tag and artifacts for 0.6.0-beta3: > > > > SVN Tag: > > https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.0-beta3 > > 0.6.0-beta3 artifacts: > > http://people.apache.org/~eevans<http://people.apache.org/%7Eeevans> > > > > Obviously this is a +1 from me. :) > > > > [1]: > > > https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.0-beta3/CHANGES.txt > > [2]: > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310865&fixfor=12314361 > > > > -- > > Eric Evans > > eev...@rackspace.com > > > > > -- Chris Goffinet
Re: IRC channel(s)
Eric, Great. I fully support this as well, it has been getting a bit noisy :) On Thu, Mar 25, 2010 at 10:16 AM, Eric Evans wrote: > > Those of you who participate on IRC have probably noticed that we are > pretty regularly topping 200 users of late. That is an awesome indicator > of the projects vitality, but at some point increased traffic results in > decreased usefulness (at least for some). > > As a result, there is a new channel, #cassandra-dev (also on Freenode). > The idea is that this channel will be restricted to discussion of > cassandra development only, while the existing channel will continue to > be the place for support and development *against* cassandra. > > In order to make the new channel useful (and to prevent it from > diminishing #cassandra), I propose the following guidelines: > > 1. Anyone is free to join; there are no technological restrictions (i.e. > it's not moderated or invite-only). > > 2. On-topic is limited to the development *of* cassandra. Support > questions (and basically anything else) are off-topic. > > 3. If you are found to be off-topic, you'll be kindly redirected to > #cassandra (which in IMO is already an awesome resource for this). > > 4. Answering an off-topic question is considered off-topic. Goto #3 :) > > 5. The Cassandra community is an awesome bunch so I can't imagine that > one or two iterations of #3 wouldn't be enough, but... > > 5a. Repeated violation of the on-topic rule may result in additional > guidelines that specify decreasing levels of kindness and more forceful > forms of redirection. :) > > The rationale for (1) is that this isn't about exclusivity, we're merely > trying to increase usability. The rationale for (2) through (5a) is that > there is no value in having two channels unless some distinction is > enforced. > > Comments? Questions? > > -- > Eric Evans > eev...@rackspace.com > > -- Chris Goffinet
Re: [VOTE] Release 0.6.0-rc1
+1 -Chris On Mar 28, 2010, at 9:02 AM, Eric Evans wrote: > > The 0.6.0 blockers are now out of the way and things are looking good. I > propose the following tag/artifacts for 0.6.0-rc1: > > SVN Tag: > https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.0-rc1 > 0.6.0-rc1 artifacts: http://people.apache.org/~eevans > > -- > Eric Evans > eev...@rackspace.com >
Re: [VOTE] Release 0.6.0 (final)
+1 -Chris On Apr 11, 2010, at 6:55 PM, Eric Evans wrote: > > It's been about a week and half since rc1 and there aren't any serious > issues so I propose we release. The tag and artifacts below should > differ from rc1 only in that the versioning was updated. > > SVN Tag: > https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.0 > 0.6.0 artifacts: http://people.apache.org/~eevans > > Additionally, the ASF press team has put together a press release to > announce this release and our graduation to a TLP. They send these > things out on Tuesdays, so unless there are any complaints, I'd like > to limit the duration of this vote to 24 hours. > > > -- > Eric Evans > eev...@rackspace.com > > >
Re: [VOTE] Release 0.6.2
+1 -Chris On May 25, 2010, at 10:25 PM, Jonathan Ellis wrote: > +1 > > On Mon, May 24, 2010 at 4:02 PM, Eric Evans wrote: >> >> As promised, here is the 0.6.2 vote. >> >> The list of changes from 0.6.1 is longer than I'd have liked, so it >> would be great if everyone can give this one an extra-special once over. >> Don't be afraid to drop a veto if you spot any regressions from 0.6.1. >> >> SVN Tag: https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.2 >> 0.6.2 artifacts: http://people.apache.org/~eevans >> >> The vote will be open for 72 hours. >> >> Thanks! >> >> -- >> Eric Evans >> eev...@rackspace.com >> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
Re: [VOTE] Release 0.6.3
+1 -Chris On Jun 28, 2010, at 9:09 AM, Brandon Williams wrote: > On Fri, Jun 25, 2010 at 5:58 PM, Eric Evans wrote: > >> >> As promised last week, here is the proposed 0.6.3 release. There have >> been a fair number of changes[1] since 0.6.2, so please look it over >> carefully and speak up if you notice any problems. >> > > +1 > > -Brandon
Re: Almost time for 0.7 beta?
+1. Digg has been holding off until at least beta before testing. I'd love to start this as soon as possible. -Chris On Jul 24, 2010, at 7:49 PM, Jonathan Ellis wrote: > At the time of our last update [1], I estimated it would be 4 to 6 > weeks until a 0.7 beta. That was over 8 weeks ago. Although we've > never adhered to a strict release schedule, I'm feeling more and more > like we need to stop delaying getting what is already done into > peoples' hands. > > Wide row support was the main "blocker" in my mind for 0.7, and that > was complete a month ago. [2] Basic secondary index support will be > also be done in the next few days (see subtasks to [3]). I propose > rolling a beta release next Friday and a release candidate two weeks > after that; anything not ready at that point can wait until 0.7.1 or > 0.8. > > The bad news is, vector clocks [4] and the Avro client api [5] will > probably not be ready for the beta but may be ready for the release > candidate. I would be okay putting those directly into the RC since > they are completely optional and will not affect users who want to > ignore them. (That is, more than they already have, with the Clock > struct in the Thrift API.) But I don't want to slip the schedule any > more to wait for them. > > [1] http://www.mail-archive.com/dev@cassandra.apache.org/msg00404.html > [2] https://issues.apache.org/jira/browse/CASSANDRA-16 > [3] https://issues.apache.org/jira/browse/CASSANDRA-749 > [4] https://issues.apache.org/jira/browse/CASSANDRA-580 > [5] https://issues.apache.org/jira/browse/CASSANDRA-926 > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
Re: [VOTE] Release 0.6.4
+1 -Chris On Jul 30, 2010, at 6:23 AM, Jonathan Ellis wrote: > +1 > > On Tue, Jul 27, 2010 at 5:18 PM, Eric Evans wrote: >> >> As discussed last week, here is the proposed 0.6.4 release. There's >> been a fair number of changes[1] since 0.6.3, so be sure to review >> carefully and raise any issues you find here. >> >> SVN Tag: https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.4 >> 0.6.4 artifacts: http://people.apache.org/~eevans >> >> The vote will be open for 72 hours. >> >> Thanks! >> >> [1]: >> https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.4/CHANGES.txt >> >> -- >> Eric Evans >> eev...@rackspace.com >> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
Re: [DISCUSSION] High-volume counters in Cassandra
I can chime in on that part Joe. The counters weren't the reasons for launch issues. It was just actually the volume of messages we were trying to handle in the cluster, so it didn't matter if it was reads for counts or reads to normal CFs, we just had more on the count side. It is very unfortunate that it has come down to forking on Github. Digg is in the same position as Twitter on this one. We really do depend on 1072, it's now an integral part of our requirements. We have already felt the pain of trying to keep up with 1072 in our 0.6 branch. I really hope we can come to a conscious on this because I am afraid Digg might have to use Twitter's fork as well. My two cents on the issue is that, it's an important feature that the community wants, and the work needing to be done to let 1072, isn't worth the amount of effort to delay at this stage. I would much rather get the code in, support the feature and work towards refactoring a better design than completely stalling the feature. -Chris On Sep 24, 2010, at 8:11 AM, Joe Stump wrote: > > On Sep 24, 2010, at 8:01 AM, Jeremy Hanna wrote: > >> H... would there be any way that others in the project that are >> familiar with the design could help the authors to redo some of the elements >> to remove the internal clock structure and get it to work properly before >> 0.7.0 is finalized? Not sure if that's feasible, but I would just hate to >> see *unreconcilable* differences :). > > The Digg folks can chime in, but my understanding is a large part of the > issues during launch was the vector clock / increment patch they had deployed > internally. It fell over. My understanding is it was replaced by Redis. > > I don't know enough about the issues around the counters patch, but this is > definitely high on SimpleGeo's needs list. > > --Joe
Re: [VOTE] 0.7.0 beta2 (attempt #3)
+1 -Chris On Sep 28, 2010, at 1:16 PM, Jonathan Ellis wrote: > +1 > > On Tue, Sep 28, 2010 at 12:37 PM, Eric Evans wrote: It feels like 0.7.0-beta1 is becoming too distant a spec in the rear-view, and the delta[1] is becoming quite large. I propose we vote to release a new beta. >> >>> The previous vote was waved off, so here is a new one. >> >> 3rd times the charm? We shall see. >> >> SVN: https://svn.apache.org/repos/asf/cassandra/tr...@r1002257 >> 0.7.0-beta2 artifacts: http://people.apache.org/~eevans >> >> The vote will be open for 72 hours (less if there is another >> veto). >> >> [1]: https://svn.apache.org/repos/asf/cassandra/trunk/CHANGES.txt >> >> -- >> Eric Evans >> eev...@rackspace.com >> >> >> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
Re: [VOTE] 0.7.0 beta3
+1 -Chris On Oct 31, 2010, at 8:48 PM, Stu Hood wrote: > +1 > > -Original Message- > From: "Eric Evans" > Sent: Thursday, October 28, 2010 10:55am > To: dev@cassandra.apache.org > Subject: [VOTE] 0.7.0 beta3 > > > The RC1 vote[1] was vetoed due to, (among other things), the desire to > see more testing after the somewhat disruptive changes made in > CASSANDRA-1367[2]. Thus, I propose the follow artifacts for release as > beta3. > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1028349 > 0.7.0-beta3 artifacts: http://people.apache.org/~eevans > > The vote will be open for the usual 72 hours. > > [1]: http://article.gmane.org/gmane.comp.db.cassandra.devel/2346 > [2]: https://issues.apache.org/jira/browse/CASSANDRA-1367 > [3]: http://goo.gl/o0lQ (CHANGES.txt) > [4]: http://goo.gl/wFax (NEWS.txt) > > -- > Eric Evans > eev...@rackspace.com > > > > >
Re: [VOTE] 0.6.7 RC1
+1 -Chris On Nov 8, 2010, at 3:11 PM, Jonathan Ellis wrote: > +1 > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com
Re: [VOTE] 0.6.8 RC2
+1 -Chris On Nov 11, 2010, at 3:39 PM, Eric Evans wrote: > > A regression caused by CASSANDRA-1622[1] (and fixed in CASSANDRA-1727[2]) > made its way into the last release. With that fixed now (along with an > 11th hour backport of CASSANDRA-1722[3]), I propose the following > artifacts for 0.6.8. > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1034172 > 0.6.8 artifacts: http://people.apache.org/~eevans > > In the first go 'round, most people seemed happy to shorten this vote to > 24 hours, so unless there are any objections, 24 hours it is. > > [1]: https://issues.apache.org/jira/browse/CASSANDRA-1622 > [2]: https://issues.apache.org/jira/browse/CASSANDRA-1727 > [3]: https://issues.apache.org/jira/browse/CASSANDRA-1722 > [4]: http://goo.gl/iTJHD (CHANGES.txt) > > -- > Eric Evans > eev...@rackspace.com > > >
Re: [VOTE] 6.10
+1 -Chris On Jan 22, 2011, at 5:59 PM, Gary Dusbabek wrote: > doh! > > +1. > > On Wed, Jan 19, 2011 at 13:40, Eric Evans wrote: >> >> We should probably get the fix for CASSANDRA-1959 out to users of 0.6. >> I propose the following artifacts for release as 0.6.10. >> >> SVN: >> https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1060906 >> 0.6.10 artifacts: http://people.apache.org/~eevans >> >> The vote will be open for the usual 72 hours. >> >> Thanks. >> >> >> [1]: https://issues.apache.org/jira/browse/CASSANDRA-1959 >> [2]: http://goo.gl/mO01x (CHANGES.txt) >> [3]: http://goo.gl/0yn9T (NEWS.txt) >> [4]: http://goo.gl/T57iQ >> >> -- >> Eric Evans >> eev...@rackspace.com >> >>
Bringing a node back online after failure
I was looking over the Operations wiki, and with the many improvements with 0.7, I wanted to bring up a thought. The two options today for replacing a node that has lost all data is: (Recommended approach) Bring up the replacement node with a new IP address, and AutoBootstrap set to true in storage-conf.xml. This will place the replacement node in the cluster and find the appropriate position automatically. Then the bootstrap process begins. While this process runs, the node will not receive reads until finished. Once this process is finished on the replacement node, run nodetool removetoken once, supplying the token of the dead node, and nodetool cleanup on each node. (Alternative approach) Bring up a replacement node with the same IP and token as the old, and run nodetool repair. Until the repair process is complete, clients reading only from this node may get no data back. Using a higher ConsistencyLevel on reads will avoid this. For nodes that might have a drive failure, but same ip address, what do you think about supplying the node's same token + autobootstrap set to true? This process works in trunk, but not all the data seems to be streamed over from it's replicas. This would provide the option to not let a node take on reads until replicas stream the SSTables over and would eliminate the alternative approach of forcing higher consistency levels. -Chris
Re: Bringing a node back online after failure
So you would be okay if I added -Dreplace_token as the check to do that? -Chris On Jan 30, 2011, at 9:55 PM, Jonathan Ellis wrote: > I think we'd need a new operation type > (https://issues.apache.org/jira/browse/CASSANDRA-957) to go from "some > of the data gets streamed" to "all of the data gets streamed." A node > that claims a token that is in the ring is assumed to actually have > that data and IMO trying to guess when to break that would be > error-prone -- better to have some explicit signal. > > On Sun, Jan 30, 2011 at 1:38 AM, Chris Goffinet > wrote: >> I was looking over the Operations wiki, and with the many improvements with >> 0.7, I wanted to bring up a thought. >> >> The two options today for replacing a node that has lost all data is: >> >> (Recommended approach) Bring up the replacement node with a new IP address, >> and AutoBootstrap set to true in storage-conf.xml. This will place the >> replacement node in the cluster and find the appropriate position >> automatically. Then the bootstrap process begins. While this process runs, >> the node will not receive reads until finished. Once this process is >> finished on the replacement node, run nodetool removetoken once, supplying >> the token of the dead node, and nodetool cleanup on each node. >> (Alternative approach) Bring up a replacement node with the same IP and >> token as the old, and run nodetool repair. Until the repair process is >> complete, clients reading only from this node may get no data back. Using a >> higher ConsistencyLevel on reads will avoid this. >> >> For nodes that might have a drive failure, but same ip address, what do you >> think about supplying the node's same token + autobootstrap set to true? >> This process works in trunk, but not all the data seems to be streamed over >> from it's replicas. This would provide the option to not let a node take on >> reads until replicas stream the SSTables over and would eliminate the >> alternative approach of forcing higher consistency levels. >> >> -Chris >> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com
Re: Incremental counters
We no longer backport to 0.7. We're on 0.8/trunk at the moment. -Chris On Mar 23, 2011, at 9:02 PM, Robert Coli wrote: > On Wed, Mar 23, 2011 at 7:55 PM, Ian Holsman wrote: >> I was wondering if this (and supporting patches?) could be easily applied to >> 0.74, or if the current trunk is stable enough to use. >> >> I think twitter is using this in their Rainman product.. ideally they will >> release that soon as well ;-) > > https://github.com/kakugawa/cassandra/tree/twttr-cassandra-0.7-counts > > Contains a version of 0.7 with a version of the counters patch > applied. Twitter could speak to whether they are likely to continue to > update this public branch.. > > =Rob > PS - note that unless that version contains > https://issues.apache.org/jira/browse/CASSANDRA-1938, you will have to > dump and reload counts when you get to a version which does contain > it.
Re: [VOTE] Apache Cassandra 0.8.0-beta1 (take #2)
+1 -Chris On Apr 19, 2011, at 6:35 PM, Eric Evans wrote: > > Let's try this again. I propose the following artifacts for release as > 0.8.0 beta1. > > You will note the addition of three new artifacts, cql-1.0.0.tar.gz, > txcql-1.0.0.tar.gz and apache-cassandra-cql-1.0.0.jar. These are > language drivers for CQL; Be sure to include them in your review. > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1095239 > 0.8.0-beta1 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours, longer if needed. > > Thanks! > > -- > Eric Evans > eev...@rackspace.com >
Re: [VOTE] Release Apache Cassandra 0.8.0 (take #3)
+1 -Chris On May 30, 2011, at 12:04 PM, Eric Evans wrote: > OK, let's try this yet again; I propose the following artifacts for release > as 0.8.0 (final). > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8.0@r1129278 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-018/ > Driver Artifacts and Debian Package: http://people.apache.org/~eevans > > The vote will remain open for 72 hours (longer if needed). > > [1]: http://goo.gl/QY5dm (CHANGES.txt) > [2]: http://goo.gl/CrJqJ (NEWS.txt) > > -- > Eric Evans > eev...@rackspace.com > > >
Re: [VOTE] Release Apache Cassandra 1.0.4
+1 On Mon, Nov 28, 2011 at 10:41 AM, Jonathan Ellis wrote: > +1 > > On Fri, Nov 25, 2011 at 6:44 AM, Sylvain Lebresne > wrote: > > So, 1.0.3 was not as solid as one would have hoped and CASSANDRA-3510 is > > fairly bad. We've also fixed a few concurrency bugs and more, so it is > worth > > pushing all this to the use now. I thus propose the following artifacts > for > > release as 1.0.4. > > > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-1.0@1206131 > > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-248/org/apache/cassandra/apache-cassandra/1.0.4/ > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachecassandra-248/ > > > > The artifacts as well as the debian package are also available here: > > http://people.apache.org/~slebresne/ > > > > Please note that there is a unit test failure for ConsistencyLevelTest. > > However, this is a problem with the test itself, not the code (see > > CASSANDRA-3531), so I don't see a point in holding the release for that. > > > > The vote will be open for 72 hours (longer if needed). > > > > [1]: http://goo.gl/SJJvx (CHANGES.txt) > > [2]: http://goo.gl/794fz (NEWS.txt) > > > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com >
Re: [VOTE] Release Apache Cassandra 0.8.10
+1 On Wed, Feb 8, 2012 at 8:19 AM, Sylvain Lebresne wrote: > It's been close to 2 months since 0.8.9 and while things are mostly calm on > the 0.8 branch, we do have a few fixes in there that is worth releasing. > I thus propose the following artifacts for release as 0.8.10. > > Git sha1: 038b8f212eb37c98ff4f230b722bc9a76daf1658 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/0.8.10-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-209/org/apache/cassandra/apache-cassandra/0.8.10/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-209/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/ZOnuf (CHANGES.txt) > [2]: http://goo.gl/EXtfL (NEWS.txt) >
Re: [VOTE] Release Apache Cassandra 1.1.0-beta1
+1 On Thu, Feb 16, 2012 at 2:36 AM, Sylvain Lebresne wrote: > The 1.1.0 freeze has been going on for more than 2 weeks now, with not that > many big issues so far. I think it is time to release a (first) beta to > hopefully get some wider testing. Note that we still have a few tickets > opened > (and I get 2 unit tests failures, but they seem more related to tests than > anything else) but keep in mind that this is a beta and the goal is to make > testing easier. I thus propose the following artifacts for release as > 1.1.0-beta1. > > sha1: 271630d585a6f260cead493bca2fb7a1a6f8ea41 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-beta1-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-011/org/apache/cassandra/apache-cassandra/1.1.0-beta1/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-011/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/XhPHr (CHANGES.txt) > [2]: http://goo.gl/e5bjy (NEWS.txt) >
Re: RFC: Cassandra Virtual Nodes
I'm going to agree with Eric on this one. Twitter has wanted some sort of vnode support for quite sometime. We even were willing to do all the work. I have reservations about that now We have been silent due to the community and how this is more like an exclusive Datastax project than an Apache one. I share Eric's frustration and do not like this veto/control attitude I see on this thread. Sent from my iPhone On Mar 21, 2012, at 6:50 AM, Eric Evans wrote: > On Tue, Mar 20, 2012 at 9:53 PM, Jonathan Ellis wrote: >> It's reasonable that we can attach different levels of importance to >> these things. Taking a step back, I have two main points: >> >> 1) vnodes add enormous complexity to *many* parts of Cassandra. I'm >> skeptical of the cost:benefit ratio here. >> >> 1a) The benefit is lower in my mind because many of the problems >> solved by vnodes can be solved "well enough" for "most people," for >> some value of those two phrases, without vnodes. >> >> 2) I'm not okay with a "commit something half-baked and sort it out >> later" approach. > > I must admit I find this a little disheartening. The discussion has > barely started. No one has had a chance to discuss implementation > specifics so that the rest of us could understand *how* disruptive it > would be (a necessary requirement in weighing cost:benefit), or what > an incremental approach would look like, and yet work has already > begun on shutting this down. > > Unless I'm reading you wrong, your mandate (I say mandate because you > hinted at a veto elsewhere), is No to anything complex or invasive > (for some value of each). The only alternative would seem to be a > phased or incremental approach, but you seem to be saying No to that > as well. > > There seems to be quite a bit of interest in having virtual nodes (and > there has been for as long as I can remember), the only serious > reservations relate to the difficulty/complexity. Is there really no > way to put our heads together and figure out how to properly manage > that aspect? > >> On Tue, Mar 20, 2012 at 11:10 AM, Richard Low wrote: >>> On 20 March 2012 14:55, Jonathan Ellis wrote: Here's how I see Sam's list: * Even load balancing when growing and shrinking the cluster Nice to have, but post-bootstrap load balancing works well in practice (and is improved by TRP). >>> >>> Post-bootstrap load balancing without vnodes necessarily streams more >>> data than is necessary. Vnodes streams the minimal amount. >>> >>> In fact, post-bootstrap load balancing currently streams a constant >>> fraction of your data - the network traffic involved in a rebalance >>> increases linearly with the size of your cluster. With vnodes it >>> decreases linearly. >>> >>> Including removing the ops overhead of running the load balance and >>> calculating new tokens, this makes removing post-bootstrap load >>> balancing a pretty big deal. >>> * Greater failure tolerance in streaming Directly addressed by TRP. >>> >>> Agreed. >>> * Evenly distributed impact of streaming operations Not a problem in practice with stream throttling. >>> >>> Throttling slows them down, increasing rebuild times so increasing downtime. >>> * Possibility for active load balancing Not really a feature of vnodes per se, but as with the other load balancing point, this is also improved by TRP. >>> >>> Again with the caveat that more data is streamed with TRP. Vnodes >>> removes the need for any load balancing with RP. >>> * Distributed rebuild This is the 20% that TRP does not address. Nice to have? Yes. Can I live without it? I have so far. Is this alone worth the complexity of vnodes? No, it is not. Especially since there are probably other approaches that we can take to mitigate this, one of which Rick has suggested in a separate sub-thread. >>> >>> Distributed rebuild means you can store more data per node with the >>> same failure probabilities. This is frequently a limiting factor on >>> how much data you can store per node, increasing cluster sizes >>> unnecessarily. I'd argue that this alone is worth the complexity of >>> vnodes. >>> >>> Richard. >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of DataStax, the source for professional Cassandra support >> http://www.datastax.com > > > > -- > Eric Evans > Acunu | http://www.acunu.com | @acunu
