[VOTE] Release Apache Cassandra 1.1.0-beta2
There is has been quite some changes since the beta1[1] (including some non trivial ones) and so while we still have a few outstanding small issues that may need to be addressed before calling for a release candidate, a new beta seems like the reasonable thing to do. I thus propose the following artifacts for release as 1.1.0-beta2. sha1: 643d18af24574d82ba565f6fe6482225f89f5d18 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-beta2-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-104/org/apache/cassandra/apache-cassandra/1.1.0-beta2/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-104/ 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/yNMo3 (CHANGES.txt) [2]: http://goo.gl/2AFuM (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 1.1.0-beta2
+1 On Fri, Mar 23, 2012 at 5:26 AM, Sylvain Lebresne wrote: > There is has been quite some changes since the beta1[1] (including some non > trivial ones) and so while we still have a few outstanding small issues that > may need to be addressed before calling for a release candidate, a new beta > seems like the reasonable thing to do. I thus propose the following artifacts > for release as 1.1.0-beta2. > > sha1: 643d18af24574d82ba565f6fe6482225f89f5d18 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-beta2-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-104/org/apache/cassandra/apache-cassandra/1.1.0-beta2/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-104/ > > 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/yNMo3 (CHANGES.txt) > [2]: http://goo.gl/2AFuM (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 1.1.0-beta2
+1 Regards, On Fri, Mar 23, 2012 at 3:26 AM, Sylvain Lebresne wrote: > There is has been quite some changes since the beta1[1] (including some non > trivial ones) and so while we still have a few outstanding small issues > that > may need to be addressed before calling for a release candidate, a new beta > seems like the reasonable thing to do. I thus propose the following > artifacts > for release as 1.1.0-beta2. > > sha1: 643d18af24574d82ba565f6fe6482225f89f5d18 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-beta2-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-104/org/apache/cassandra/apache-cassandra/1.1.0-beta2/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-104/ > > 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/yNMo3 (CHANGES.txt) > [2]: http://goo.gl/2AFuM (NEWS.txt) >
Re: RFC: Cassandra Virtual Nodes
> The SSTable indices should still be scanned for size tiered compaction. > Do I miss anything here? > > No I don't think you did, in fact, depending on the size of your SSTable a contiguous range (or the entire SSTable) may or may not be affected by a cleanup/move or any type of topology change. There is lots of room for optimization here. After loading the indexes we actually know start/end range for an SSTable so we can include/exclude it in any such operation. -- Ben Coverston DataStax -- The Apache Cassandra Company
Re: [VOTE] Release Apache Cassandra 1.1.0-beta2
+1 On Fri, Mar 23, 2012 at 5:26 AM, Sylvain Lebresne wrote: > There is has been quite some changes since the beta1[1] (including some non > trivial ones) and so while we still have a few outstanding small issues that > may need to be addressed before calling for a release candidate, a new beta > seems like the reasonable thing to do. I thus propose the following artifacts > for release as 1.1.0-beta2. > > sha1: 643d18af24574d82ba565f6fe6482225f89f5d18 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-beta2-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-104/org/apache/cassandra/apache-cassandra/1.1.0-beta2/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-104/ > > 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/yNMo3 (CHANGES.txt) > [2]: http://goo.gl/2AFuM (NEWS.txt)
Re: RFC: Cassandra Virtual Nodes
> No I don't think you did, in fact, depending on the size of your SSTable a > contiguous range (or the entire SSTable) may or may not be affected by a > cleanup/move or any type of topology change. There is lots of room for > optimization here. After loading the indexes we actually know start/end > range for an SSTable so we can include/exclude it in any such operation. Just note that unless there is some correlation between range and these sstables being created to begin with (like with leveled), you're highly unlikely to be able to optimize here. For uniformly distributed tokens (hashed keys), all sstables are likely to have almost the entire possible token range in them. -- / Peter Schuller (@scode, http://worldmodscode.wordpress.com)
Re: RFC: Cassandra Virtual Nodes
On Sat, Mar 24, 2012 at 7:55 AM, Peter Schuller wrote: > > No I don't think you did, in fact, depending on the size of your SSTable > a > > contiguous range (or the entire SSTable) may or may not be affected by a > > cleanup/move or any type of topology change. There is lots of room for > > optimization here. After loading the indexes we actually know start/end > > range for an SSTable so we can include/exclude it in any such operation > > > Just note that unless there is some correlation between range and > these sstables being created to begin with (like with leveled), you're > highly unlikely to be able to optimize here. For uniformly distributed > tokens (hashed keys), all sstables are likely to have almost the > entire possible token range in them. > As Peter pointed out, for random partitioner, the rows of a specific range might scatter around all sstables. Unless whole sstable can be ignored, disk seek is the performance killer here. > -- > / Peter Schuller (@scode, http://worldmodscode.wordpress.com) >
