Probable release date for cassandra 2.1 ??

Hi, I am looking feature(CASSANDRA-4511) which allows Index on Collections. Any idea about release date of Cassandra 2.1 ?? Till this releases, i am thinking to take source code of 2.1 and build it on my machine to test the required feature.

Re: Help on Designing Cassandra table for my usecase

@Thunder I just came to know about (CASSANDRA-4511) which allows Index on Collections and that will be part of release 2.1. I hope in that case my problem will be solved by changing your designed table with tag column as set and defining seconda

Re: Probable release date for cassandra 2.1 ??

I was looking at this on wednesday and spoke with Sylvain. Currently there's other bugs in 2.1 that broke secondary indexes. Once those other bugs are fixed, I plan to test index on collections. peter On Fri, Jan 10, 2014 at 7:15 AM, Naresh Yadav wrote: > Hi, > > I am looking > feature(CASSAN

Re: Help on Designing Cassandra table for my usecase

@Naresh Too many indices or indices with high cardinality should be discouraged and are always performance issues. A set will not contain duplicate values. -Vivek On Fri, Jan 10, 2014 at 5:48 PM, Naresh Yadav wrote: > @Thunder > I just came to know about > (CASSANDRA-4511

Re: Help on Designing Cassandra table for my usecase

@vivek thanks for pointing that out..Other than primary key defining only one secondary index tags and in my case same tags will be repeating itself across period for sure for a metric=Sales AND also across metric Sales, Cost also can be same set of tags to some extent not always.. Thanks Naresh

java.lang.StackOverflowError with big IN list

Hello I'm getting stack overflow when running prepared queries with IN parameter and binding big list in it. Is it known limitation and I must implement manual paging or change logic to get around this, or is it some bug maybe... java.lang.StackOverflowError at org.apache.cassandra.utils.F

Re: Help on Designing Cassandra table for my usecase

indexes on columns with high cardinality is a general database issue, so it's not unique to cassandra or nosql. On Fri, Jan 10, 2014 at 7:35 AM, Vivek Mishra wrote: > @Naresh > Too many indices or indices with high cardinality should be discouraged > and are always performance issues. A set wil

Re: Can't start service with error: java.lang.IllegalStateException: Unable to contact any seeds

Hi, did you configured ip address in the setting "seeds:" in cassandra.yaml? Jason On Fri, Jan 10, 2014 at 1:20 PM, Francisco Dalla Rosa Soares < dallar...@gmail.com> wrote: > Hello everyone, > > I've tried to google all I could and also asking at ServerFault first but > as I got no answer I de

Re: java.lang.StackOverflowError with big IN list

It must be a very large IN clause, which is probably not advisable. But it shouldn't cause this error, and since it's an easy fix to prevent it, if you file a JIRA I'll post a patch. On 10 January 2014 13:08, Дмитрий Шохов wrote: > Hello I'm getting stack overflow when running prepared queries

Re: Help on Designing Cassandra table for my usecase

It does sound like that could work for you. From the sample data it doesn't look like tag will be high cardinality (relative to number of rows) so as long as you won't have rows with too many tags (collections are best kept small, but they claim can be in the hundreds but not to exceed 64k) I do

Re: java.lang.StackOverflowError with big IN list

https://issues.apache.org/jira/browse/CASSANDRA-6567 Thank you! 2014/1/10 Benedict Elliott Smith > It must be a very large IN clause, which is probably not advisable. But it > shouldn't cause this error, and since it's an easy fix to prevent it, if > you file a JIRA I'll post a patch. > > > On

Re: Optimal Way to Tune For Searchs For Missing Keys

Hi Rob, It sounds like Cassandra is actually a very good fit with this use case. I have been experiencing slower performance in my app than I was expecting. Although I am fairly sure now its something else now rather than this part of the app. It was just with such a lot of queries I was keen to k

Read/Write consistency issue

Hi Using Cassandra 2.0.0. 3 node cluster Replication 2. Using consistency ALL for both read and writes. I have a single thread that reads a value, updates it and writes it back to the table. The column type is big int. Updating counts for a timestamp. With single thread and consistency ALL , I e

Re: Read/Write consistency issue

Cassandra is a last-write wins kind of a deal. The last write is determined by the timestamp. There are two problems with this: 1. If your clocks are not synchronized, you¹re totally screwed. Note that the 2nd and 3rd to last operations occurred just 2 milliseconds apart. A clock skew of 2 millisec

RE: Read/Write consistency issue

That, or roll your own locking. Means multiple updates, but it works reliably. tc From: Robert Wille [mailto:rwi...@fold3.com] Sent: Friday, January 10, 2014 4:25 PM To: user@cassandra.apache.org Subject: Re: Read/Write consistency issue Cassandra is a last-write wins kind of a deal. The last w

Re: Read/Write consistency issue

Actually, locking won¹t fix the problem. He¹s getting the problem on a single thread. I¹m pretty sure that if updates can occur within the same millisecond (or more, if there is clock skew), there is literally nothing you can do to make this pattern work. Robert From: Todd Carrico Reply-To:

RE: Read/Write consistency issue

Is it possible to pin to a node, instead of letting the client find the next node (round robin)? Sorry, a C* noob here... tc From: Robert Wille [mailto:rwi...@fold3.com] Sent: Friday, January 10, 2014 4:35 PM To: user@cassandra.apache.org Subject: Re: Read/Write consistency issue Actually, loc

Re: Read/Write consistency issue

My understanding is that it's generally a Cassandra anti-pattern to do read-before-write in any case, not just because of this issue. I'd agree with Robert's suggestion earlier in this thread of writing each update independently and aggregating on read. Steve On Fri, Jan 10, 2014 at 2:35 PM, Ro

Re: Read/Write consistency issue

Yes this is pretty close to the ultimate anti-pattern in Cassandra. Whenever possible, we encourage models where your updates are idempotent, and not dependent on a read before write. Manoj is looking for what is essentially strong ordering in a distributed system, which always has inherent trade-o

Re: Read/Write consistency issue

Interested in knowing more on why read-before-write is an anti-pattern. In the next month or so, I intend to use Cassandra as a doc store. One very common operation will be to read the document, make a change, and write it back. These would be interactive users modifying their own documents, so rap

Re: Read/Write consistency issue

It is bad because of the risk of concurrent modifications. If you don't have some kind of global lock on the document/row, then 2 readers might read version A, reader 1 writes version B based on A, and reader 2 writes version C based on A, overwriting the changes in B. This is *inherent* to the not

RE: Read/Write consistency issue

I think the anti-pattern is more about the read/write trying to be atomic. You might want to logically lock your record unless you are pretty sure you have figured out how to keep users from overwriting each others edits is all. tc From: Robert Wille [mailto:rwi...@fold3.com] Sent: Friday, Janu

Impact of running major compaction with Size Tiered Compaction - version 1.1.11

Hi We have a 6 node cluster in two DCs, Cassandra version 1.1.11, RF=3 in each DC. The DataStax Documentation says the following: Initiate a major compaction through nodetool compact

RE: Read/Write consistency issue

I've solved this for other systems, and it might work here. Add a Guid as a field to the record. When you update the document, check to make sure the Guid hasn't changed since you read it. If the Guid is the same, go ahead and save the document along with a new Guid. This keeps you from lockin

Re: Read/Write consistency issue

Thanks all for the response. I will change to keeping writes idempotent and aggregate at a later stage. But considering my read , write , read operations are sequential and from the same thread and with Consistency ALL, the write should not return until all replicas have committed. So I am expecti

Re: Read/Write consistency issue

Hi Robert, Just to clarify a bit, there's nothing inherently wrong with a read-modify-write cycle as you would use for a document store. The read-before-write antipattern refers to depending on a read immediately before a write, as was being done in the original post. Generally, such a read is don

Re: Read/Write consistency issue

That really should work, unless I'm missing something. If you retry your test with either 1.2.13 or 2.0.4 (as opposed to earlier releases of either branch), and triple check your observations to make sure that your single threaded code is doing what you think it is, and still see the behaviour, I

Re: Read/Write consistency issue

As was pointed out earlier, Consistency.ALL is still subject to the possibility of clock drift between nodes, and there is also the problem of using the exact same timestamp, which is increasingly likely to happen the faster you update, and the more data points you process. Better to design with Ca

Re: Read/Write consistency issue

For single thread, consistency ALL it should work. I believe you do something different. What are these three numbers exactly? old=60616 val =19 new =60635 On Fri, Jan 10, 2014 at 1:50 PM, Manoj Khangaonkar wrote: > Hi > > Using Cassandra 2.0.0. > 3 node cluster > Replication 2. > Using consiste

Re: java.lang.StackOverflowError with big IN list

In the mean time you can try upping the value of your -Xss setting in cassandra-env.sh to see if just a little push will take the problem away. On 01/10/2014 10:18 AM, Дмитрий Шохов wrote: https://issues.apache.org/jira/browse/CASSANDRA-6567 Thank you! 2014/1/10 Benedict Elliott Smith

Re: Read/Write consistency issue

old is the value that was read from the column. val is the value that needs to be added to it. new is (old + val) that is written back to the column. regards On Fri, Jan 10, 2014 at 4:36 PM, Andrey Ilinykh wrote: > For single thread, consistency ALL it should work. I believe you do > somethin

Re: Impact of running major compaction with Size Tiered Compaction - version 1.1.11

On Fri, Jan 10, 2014 at 3:21 PM, Dwight Smith wrote: > Initiate a major compaction through nodetool compact m/docs/1.1/references/nodetool#nodetool-compact>. A major compaction > merges all SSTables into one. Though major compaction can free disk space > used by accumula

Re: Optimal Way to Tune For Searchs For Missing Keys

Cassandra great database for searching things that dont exist! How often do you get to say that? On Friday, January 10, 2014, Charlie Mason wrote: > Hi Rob, > It sounds like Cassandra is actually a very good fit with this use case. I have been experiencing slower performance in my app than I was

Re: Read/Write consistency issue

There is a solution to this problem that I forgot about. The client can provide the timestamps. If you provide your own timestamps using a monotonically increasing sequence, then your code will work since it makes you immune to clock drift and multiple transactions in the same millisecond. If you a

Re: Gotchas when creating a lot of tombstones

Hi Robert, It sounds like you have done a fair bit investigating and testing already. Have you considered using a time based data model to avoid doing deletions in the database? Regards, Anthony On Thu, Jan 9, 2014 at 1:26 PM, sankalp kohli wrote: > With Level compaction, you will have some da

Re: Gotchas when creating a lot of tombstones

I essentially am using a time-based data model. But, if I don¹t delete obsolete data, my database will quickly become many times larger than necessary. After a year, it would probably be 20x the size it would be if I cleaned out obsolete data. Based on an analysis of my schema and access patterns,

Re: java.lang.StackOverflowError with big IN list

I had a problem in my code that produced a big IN list (several tens of thousands). I got a timeout error, not a stack overflow. 2.0.4 with java driver 2.0 rc3. From: Dave Brosius Reply-To: Date: Friday, January 10, 2014 at 5:53 PM To: Subject: Re: java.lang.StackOverflowError with big IN

Re: Gotchas when creating a lot of tombstones

I am on the very extreme end of ad serving. Cookies are very ephemeral. Some live a long time like 20 days, but the majority of our entries are valid only for a single day. If have a gc grace set to 10 days our data store is 10 larger then it "needs" to be. We clean up very aggressively all the tim