[anonymous7077]

"it is not ACID the worst possible way" Vow what a great revelation.

"Cassandra is not row level consistent,[21] meaning that inserts and updates into the table that affect the same row that are processed at approximately the same time may affect the non-key columns in inconsistent ways. One update may affect one column while another affects the other, resulting in sets of values within the row that were never specified or intended." This is not true. Cassandra is row level atomic but I guess it also depends on the version you use maybe. Can you talk about which version and provide a test that satisfies your assertion ?

"there are several things that needs to be tuning (like GC) that is not trivial to do". Do you know that Go's GC is way less advanced than Java GC as of today? This is admitted by Google's Go team lead.

I guess these days people can make up whatever they want without providing any valid tests that prove their assertions. It all comes down to is either love & hate of a programming language or someone wants to put some fancy sounding tools in their resume!!

[StreamBright]

> This is not true. Cassandra is row level atomic

You can go ahead and try to convince people who experienced this in production.

http://datanerds.io/post/cassandra-no-row-consistency/

I could provide you all of the versions but it is irrelevant from the angle that the version my clients have in production are affected.

> Do you know that Go's GC is way less advanced than Java GC as of today?

Not only I know, I work as a consultant who actually configures it so that it provides the best performance for the workload a customer has. I made a large sum by changing the settings that most Cassandra installations have. In fact, all of my clients were running Cassandra with the default settings in production and failed miserably to have a stable service. In one occasion there was almost 1 minute GC time on average, causing nodes marked as down, read and write tied up as well. Facebook and Netflix has production engineers with these skills so they can make it happen for them but clients not having such engineering resources are either reaching out consultancies or try to hire somebody with the skills. What does your question have to do with the topic?

> I guess these days people can make up whatever they want without providing any valid tests that prove their assertions.

I guess these days people can go on HN and write down some of their experiences that they encountered in their professional life.

[nemothekid]

> Do you know that Go's GC is way less advanced than Java GC as of today? This is admitted by Google's Go team lead.

I won't comment on the other points - but I managed a medium sized Cassandra cluster for a couple of years, and the GC point is valid. It has nothing to do with Java's GC being more advanced. It's easier to bypass the Go GC with stack allocations (not possible in Java), and many of Cassandra's processes (compaction, repair) end up being very GC heavy. GC tuning ends up being a function of your workload and if you ignore it, background processes like repair can adversely affect projection nodes, or throw nodes in a loop. - and adversely giving the node more memory can make things worse. Cassandra has left a bad taste in my mouth for Java-based databases.

[StreamBright]

Yeah I can show you one of the systems:

GC of death:

https://imgur.com/a/6RAX7

Write latency:

https://imgur.com/a/Us0MO

Typical Cassandra user has these sort of problems. I have one client where they identified the issue (data modeling) and fixed it by redesigning their tables before I got there. Some of the Cassandra users are not even aware. The company where the pictures are from engaged me because the system did not meet with business requirements anymore. Could not insert data into the cluster, their ETL jobs were running for 20 hours and if one failed they did not have data for their business. We could speed it up to run it for 4 hours without remodeling the data. With remodeling it Cassandra was not the bottleneck anymore.

[riku_iki]

These graphs are meaningless in a vacuum, you don't know how would behave alternative Go based solution on similar hardware under the similar load.

[StreamBright]

Sure, this is why there is a production system surrounding them. I am not really interested in theoretical possibilities just observing reality here.

[riku_iki]

What I am saying is that you are observing one side of reality. It is very possible that even with this kind of graphs, Cassandra is capable to handle much larger traffic then custom Go solution.

Cassandra is usually competitive in open benchmarks.

[riku_iki]

> stack allocations (not possible in Java)

JVM does stack allocation whenever it is possible, you can learn about this by googling "escape analysis".

[StreamBright]

> This is not true. Cassandra is row level atomic

http://cassandra.apache.org/doc/latest/faq/index.html#what-h...

"What happens if two updates are made with the same timestamp? Updates must be commutative, since they may arrive in different orders on different replicas. As long as Cassandra has a deterministic way to pick the winner (in a timestamp tie), the one selected is as valid as any other, and the specifics should be treated as an implementation detail. That said, in the case of a timestamp tie, Cassandra follows two rules: first, deletes take precedence over inserts/updates. Second, if there are two updates, the one with the lexically larger value is selected."

Does this sound to you as atomic? My expectation of atomic is that 2 things changing the same value are ordered and both executed. "lexically larger value is selected" does not qualify for me as atomic.