Re: Query

Thanks for your comments/suggestions. Yes I understand my project needs and requirements. Surely it requires to handle huge data for what i'm exploring what suits for it. Though Cassandra is distributed, scalable and highly available, but it is NoSql means Sql part is missing and needs to be

Announcement: Atlanta Meetup, January 10th

Down and Durity - Cassandra Admin Discussion Now, you are running several Cassandra clusters (or leaning heavily that way). How do you deploy them, monitor them, and do various other administrative tasks? Come and join in a discussion and let's learn from each other. Sean Durity, our

RE: Query

A few of the many companies that rely on Cassandra are mentioned here: http://cassandra.apache.org Apple, Netflix, Weather Channel, etc. (Not nearly as good as the Planet Cassandra list that DataStax used to maintain. Boo for the Apache/DataStax squabble!) DataStax has a list of many case

Re: Read efficiency question

Thank you Janne. Yes, these are random-access (scatter) reads - I've decided on option 1; having also considered (as you wrote) that it will never make sense to look at ranges of key3. On Fri, Dec 30, 2016 at 3:40 AM, Janne Jalkanen wrote: > In practice, the

Re: Query

Actually, "noSQL" is a misleading misnomer. With C* you have CQL which is adapted from SQL syntax and purpose. For a poster boy, try Netflix. Regards, James Sent from my iPhone > On Dec 30, 2016, at 4:59 AM, Sikander Rafiq wrote: > > Thanks for your

Re: Insert with both TTL and timestamp behavior

Your last sentence is correct - TWCS and dtcs add meaning (date/timestamp) to the long writetime that the rest of Cassandra ignores. If you're trying to backload data, you'll need to calculate the TTL yourself per write like you calculate the writetime. The TTL behavior doesn't consider the

Re: Read efficiency question

In practice, the performance you’re getting is likely to be impacted by your reading patterns.  If you do a lot of sequential reads where key1 and key2 stay the same, and only key3 varies, then you may be getting better peformance out of the second option due to hitting the row and disk caches

Re: How to change Replication Strategy and RF

Thanks a lot kurt Greaves On Fri, Dec 30, 2016 at 5:58 AM, kurt Greaves wrote: > > ​If you're already using the cluster in production and require no downtime > you should perform a datacenter migration first to change the RF to 3. > Rough process would be as follows: > >