NoSQL Cassandra developer community sets sights on JDK 11 as sped-up 4.0 beta finally hits the streets

The beta version of Apache Cassandra 4.0, the most significant new release of column-oriented NoSQL database in years according to those involved, hit the downloads centre this week, with the promise of a 5x scaling speed improvement, new observability features and less "unnecessary garbage". Although official support for Java …

[PeterCorless]

Might want to check into the Urban Dictionary definitions of "muppet."

"A person who is ignorant and generally has no idea about anything."

"An alternative term for idiot or moron. Usually used in the UK to describe someone who is incompetant or gormless. Taken from the name for the popular Jim Henson Puppets."

"a person who defies explanation with regard to common sense and logic, exhubing [sic] an air of confidence that is mutually exclusive to that of their accomplishments or ability"

And those were the sharable ones SFW.

https://www.urbandictionary.com/define.php?term=Muppet

Otherwise, congrats on getting 4.0 to beta.

[Kevin McMurtrie]

Will people come back?

Lots of people have horror stories where Cassandra goes from "shiny new thing" to "tech debt" faster than a project can be finished. The data model was a perfect fit for Cassandra's features when the project started, then another table needs to be mutable and deterministic updates are gone.

[Anonymous Coward]

Re: Will people come back?

Thats the whole problem with NoSQL databases. Your document format has to match your problem. But as soon as the requirements change and the document format is non optimal (or worse upside down) you're utterly screwed because non optimal can mean doing the equivalent of a nested table scan for every document for every query. Sure, relational DBs can suffer from relationship and normalisation issues too , but the relational nature of the DB, the ability to modify indexes and primary/foreign keys plus SQL itself usually mean you can usually still get reasonable performance even as the DB design and the requirements diverge quite a long way. Try and modify the document format in a NoSQL DB and you'll probably break everything.

[Anonymous Coward]

They want performance but they wrote it in Java?

Err, yeah. Obviously someone thought that was a good idea, probably after an evening in the pub.

[Kevin McMurtrie]

Re: They want performance but they wrote it in Java?

At crazy levels of concurrency, Java can actually have an advantage. C++ has to pay a penalty for maintaining wrappers or shared reference counters when temporary objects are given to multiple threads. At some point the GC pauses in Java add up to less time. In the case of data servers, high concurrency caches are absolutely trivial to write in Java because because expunged elements live exactly as long as needed to satisfy all threads using it.

Of course, Java has the flexibility to suck too. Write Java that looks like C++ and it runs like C++. Add frameworks to give it scripted language features and it runs as slow as a scripted language. The latter style is quite trendy.

[Anonymous Coward]

Re: They want performance but they wrote it in Java?

There's nothing olbligatory about using shared pointers or temporary objects with C++ threads. In fact for performance and greater functionality you can simply use posix C pthreads (on unix anyway) in C++ which are a thin wrapper to the raw OS interface.