[Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

[Correction of the original message which contains typos in code.] Is it good for performance to put rows that are of different types but are always queried together in the same table partition? My consideration is that whether doing so will result in better memory/disk cache locality.

Re: Revisit Cassandra EOL Policy

You chose a specific point in time that is especially painful. Had you chosen most of 2014, you would have had a long period of 2.0.x that was stable. Yes, if you were deploying in April 2015, you had an unpleasant choice between an about-to-EOL 2.0 and a omg-memory-leak 2.1 – if you deploy

Re: Revisit Cassandra EOL Policy

Thanks Jack !! "Unfortunately how to get firm agreement  on what criteria should be used to judge "Production Ready" is unclear." The most reliable way of determining production ready is to go to Apache Cassandra website. At any point of time, it clearly states the most stable/production ready

Re: Revisit Cassandra EOL Policy

Yes. I am planning to raise one JIRA for that. Thanks for the suggestion. Anuj On Friday, 8 January 2016 11:06 PM, Michael Shuler wrote: On 01/08/2016 11:27 AM, Jonathan Haddad wrote: > Why wouldn't you keep a bug free version of something in production?  If >

Re: Too many compactions, maybe keyspace system?

On Thu, Jan 7, 2016 at 6:30 PM, Shuo Chen wrote:, > > I am using Cassandra 2.0.16 with 4 nodes and found too many compactions > for this cluster. This caused too much full gc and choked the system. I > have discussed the high gc in previous mails but didnot get the

Re: Revisit Cassandra EOL Policy

Because the day some unforeseen critical bug pops up in future, you won't find any support from the community as the version is already EOL. ThanksAnuj On Friday, 8 January 2016 10:57 PM, Jonathan Haddad wrote: Why wouldn't you keep a bug free version of

Re: Revisit Cassandra EOL Policy

On Fri, Jan 8, 2016 at 9:45 AM, Anuj Wadehra wrote: > *"Unfortunately how to get firm agreement on what criteria should be used > to judge "Production Ready" is unclear."* > Only you know how comfortable you are with the various types of risk that are involved in a

Re: Data rebalancing algorithm

On Thu, Jan 7, 2016 at 11:42 PM, Jonathan Haddad wrote: > num_tokens is the number of tokens per node, not per cluster. > MySQL docs are enumerated in the manual along with their scope. I have seen the enumeration in the Cassandra docs, but I don't remember seeing scope

Re: [Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

A simple denormalization is probably all that is called for - just merge the two tables into one (their union.) No need for this row type. -- Jack Krupansky On Fri, Jan 8, 2016 at 9:30 AM, Jeff Jirsa wrote: > You’ll see better performance using a slice (which is

[Off heap memory used (total)] in cfstats

Hi, When I switch a big table from STCS to LCS, I notice high off heap memory usage using nodetool cfstats. "*Off heap memory used (total)*" shows +10G usage. Eventually my nodes died because of OOM. How do I throttle off heap usage? The only thing I see in cassandra.yaml is

Re: [Off heap memory used (total)] in cfstats

Update: I check the source code: https://github.com/apache/cassandra/blob/4a0d1caa262af3b6f2b6d329e45766b4df845a88/src/java/org/apache/cassandra/tools/nodetool/Info.java#L154 Off heap memory usage comes from four parts. I rechecked cfstats to find out Bloom filter takes most of the off heap

Modeling contact list, plain table or List

Hi everyone What would perform better while modeling a simple user contact list that will be used mainly to select the recipients for/from/to messages ? a) Individual rows to each (user, contact) pair so a select would fetch all the rows to retrieve all the contacts from a given user. or

Re: Modeling contact list, plain table or List

How big is each contact list expected to be? Dozens? Hundreds? Thousands? If just dozens, a simple list column would seem sufficient. If thousands, the row (not partition) would get kind of bloated. What requirements do you have for updating? If updating contacts and lots of contacts, I think I'd

Re: [Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

You’ll see better performance using a slice (which is effectively what will happen if you put them into the same table and use query-1table-b), as each node will only need to merge cells/results once. It may not be twice as fast, but it’ll be fast enough to make it worthwhile. On 1/8/16,

Re: Revisit Cassandra EOL Policy

Thanks Robert !!! "I don't run X.Y.Z versions where Z is under 6, so in general this does not result in me not-running-a-version-I-otherwise-would-have for longer than a few months each year."Agree !! But, if you upgrade to a version greater than X.Y.6, and then it goes EOL within months, you

Re: Revisit Cassandra EOL Policy

Why wouldn't you keep a bug free version of something in production? If I found a version of *anything* that was bug free I don't think I'd ever upgrade again. On Fri, Jan 8, 2016 at 9:18 AM Anuj Wadehra wrote: > Thanks Robert !!! > > *"I don't run X.Y.Z versions where

Re: Revisit Cassandra EOL Policy

"declared Production Ready" I agree that mere GA of x.y.0 should not start the clock for EOL of x.y. Some people take the position that x.y is not production ready until x.y.5 is out. Unfortunately how to get firm agreement on what criteria should be used to judge "Production Ready" is unclear.

Re: Revisit Cassandra EOL Policy

Thanks Janne !! "If you wish to have a specific EOL policy, you need to basically buy it."We are not interested in a buying custom EOL policy. I am trying to understand  how people deal with quick EOLs in this fast paced environment.  If my concerns seem genuine, should we revisit the EOL

Re: Revisit Cassandra EOL Policy

On 01/08/2016 11:27 AM, Jonathan Haddad wrote: > Why wouldn't you keep a bug free version of something in production? If > I found a version of *anything* that was bug free I don't think I'd ever > upgrade again. There are still 0.7 users. :) To OP, if you want to ask the project for some sort

Re: Revisit Cassandra EOL Policy

Thanks Mark!!"My sense is that most users manage their own C* clusters, not dozens of other ones for other clients/customers"In our case, product is released to several customers and thus, every Cassandra upgrade needs planning, packaging, multiple product testing cycles & release. "One would

Re: Revisit Cassandra EOL Policy

Thanks Maciek !! "do you have a link to the versioning policy? The tick-tock versioning blog post [1] says that EOL happens after two major versions come out, but I can't find this stated more formally anywhere."I couldn't find any versioning policy related to EOL. I think it should be there on