There's a disheartening amount of "here's where Cassandra is bad, and here's what it needs to do for me for free" happening in this thread.
This is open-source software. Everyone is *strongly encouraged* to submit a patch to move the needle on *any* of these things being complained about in this thread. For the Apache Way <https://www.apache.org/foundation/governance/> to work, people need to step up and meaningfully contribute to a project to scratch their own itch instead of just waiting for a random corporation-subsidized engineer to happen to have interests that align with them and contribute that to the project. Beating a dead horse for things everyone on the project knows are serious pain points is not productive. On Wed, Feb 21, 2018 at 5:45 AM, Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > On Mon, Feb 19, 2018 at 10:01 AM, Kenneth Brotman < > kenbrot...@yahoo.com.invalid> wrote: > > > > > >> Cluster wide management should be a big theme in any next major > release. > > >> > > >Na. Stability and testing should be a big theme in the next major > release. > > > > > > > Double Na on that one Jeff. I think you have a concern there about the > > need to test sufficiently to ensure the stability of the next major > > release. That makes perfect sense.- for every release, especially the > > major ones. Continuous improvement is not a phase of development for > > example. CI should be in everything, in every phase. Stability and > > testing a part of every release not just one. A major release should be > a > > nice step from the previous major release though. > > > > I guess what Jeff refers to is the tick-tock release cycle experiment, > which has proven to be a complete disaster by popular opinion. > > There's also the "materialized views" feature which failed to materialize > in the end (pun intended) and had to be declared experimental > retroactively. > > Another prominent example is incremental repair which was introduced as the > default option in 2.2 and now is not recommended to use because of so many > corner cases where it can fail. So again experimental as an afterthought. > > Not to mention that even if you are aware of the default incremental and go > with full repair instead, you're still up for a sad surprise: > anti-compaction will be triggered despite the "full" repair. Because > anti-compaction is only disabled in case of sub-range repair (don't ask > why), so you need to use something advanced like Reaper if you want to > avoid that. I don't think you'll ever find this in the documentation. > > Honestly, for an eventually-consistent system like Cassandra anti-entropy > repair is one of the most important pieces to get right. And Cassandra > fails really badly on that one: the feature is not really well designed, > poorly implemented and under-documented. > > In a summary, IMO, Cassandra is a poor implementation of some good ideas. > It is a collection of hacks, not features. They sometimes play together > accidentally, and rarely by design. > > Regards, > -- > Alex >
