So before buying any marketing claims from Microsoft or whoever, maybe should you try to use it extensively ?
And talking about backup, have a look at DynamoDB: http://i68.tinypic.com/n1b6yr.jpg >From my POV, if a multi-billions company like Amazon doesn't get it right or can't make it easy for end-user (without involving an unwieldy Hadoop machinery: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBPipeline.html), what Cassandra offers in term of back-up restore is more than satisfactory On Wed, Feb 21, 2018 at 8:56 PM, Kenneth Brotman < kenbrot...@yahoo.com.invalid> wrote: > Josh, > > To say nothing is indifference. If you care about your community, > sometimes don't you have to bring up a subject even though you know it's > also temporarily adding some discomfort? > > As to opening a JIRA, I've got a very specific topic to try in mind now. > An easy one I'll work on and then announce. Someone else will have to do > the coding. A year from now I would probably just knock it out to make > sure it's as easy as I expect it to be but to be honest, as I've been > saying, I'm not set up to do that right now. I've barely looked at any > Cassandra code; for one; everyone on this list probably codes more than I > do, secondly; and lastly, it's a good one for someone that wants an easy > one to start with: vNodes. I've already seen too many people seeking > assistance with the vNode setting. > > And you can expect as others have been mentioning that there should be > similar ones on compaction, repair and backup. > > Microsoft knows poor usability gives them an easy market to take over. And > they make it easy to switch. > > Beginning at 4:17 in the video, it says the following: > > "You don't need to worry about replica sets, quorum or read > repair. You can focus on writing correct application logic." > > At 4:42, it says: > "Hopefully this gives you a quick idea of how seamlessly you can > bring your existing Cassandra applications to Azure Cosmos DB. No code > changes are required. It works with your favorite Cassandra tools and > drivers including for example native Cassandra driver for Spark. And it > takes seconds to get going, and it's elastically and globally scalable." > > More to come, > > Kenneth Brotman > > -----Original Message----- > From: Josh McKenzie [mailto:jmcken...@apache.org] > Sent: Wednesday, February 21, 2018 8:28 AM > To: dev@cassandra.apache.org > Cc: User > Subject: Re: Cassandra Needs to Grow Up by Version Five! > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
