Cone:
Did you use the AICD 4.0 or later version or prior versions?
You mean version MongoDB 4.0 and multi-document transactions (aka ACID, although I dislike that term here because it’s vague about which parts are ACID)?
When I worked with MongoDB professionally at my last job, I was using MongoDB 3.x (3.2 IIRC). So, I obviously didn’t use multi-document transactions. Would we have used the feature if it had been available? Probably not. I generally feel that you should avoid them if you at all can. When you are using multi-document transactions it probably means you are using MongoDB in a way you shouldn’t. It’s good that MongoDB has that feature, because there’s an exception to every rule, but I imagine that 90% of the time people are using multi-document transactions because they haven’t unlearned enough Oracle yet.
For what I’m doing now, as I mention later in this post, we have very simple access patterns. We want raw speed and don’t care about transactions, document APIs, or anything fancy. The top ten features we care about are speed, speed, speed, speed, speed, speed, speed, speed, uptime (aka reliable speed), and manageability (aka predictable speed). Transactions are not conducive to speed or predictability.
What do you attribute the Cassandra predominance you are seeing…force of habit by user groups or is there some reason that database managers feel it is superior to Mongo and why?
Several factors.
-
Lack of a good fit for documents. Most of what we are doing is very simple stuff. What is often referred to as key/value lookups. While MongoDB can do this too, it does mean that a lot of the interesting flexibility of MongoDB’s document oriented model is wasted. (As opposed to my last job, where the flexibility of the document model was the main reason MongoDB was chosen.)
-
Raw speed. For the access patterns I’m talking about Cassandra was tested to be much faster than MongoDB. Sure, some of this might have changed over time with new product versions, but these kinds of things tend to live on in folklore and our experts placed their bets on Cassandra. People’s arms were twisted into using Couchbase because of corporate relationships, and the performance testing has been quite good there too so people are fine with it.
-
Momentum. You can call this “force of habit” if you like, but it has a real impact. If you use Cassandra in my world, there is lots of supported software, lots of expertise, and lots of documentation. The MongoDB related software does exist, but it’s less supported, there aren’t nearly as many people you can go to for help, and there are some limitations just because “the road is less paved”.
Also, what are the typical use cases your teams would work on?
I don’t want to talk too much more about it, as I like to be pseudo-anonymous on TMF. There are too many opinions I share here when talking about stocks that I’d want to be officially professionally neutral about when talking technology to a client.
But, in general, high end stuff. I recognize that my views are somewhat skewed because of that.
If it is the [force of habit]…this would suggest, in time and with more marketing, Mongo can still win the hearts of the more pragmatic consumer.
So now we enter the area of pure speculation. In my heart of hearts, I’m a little skeptical that:
- Cassandra is really that much faster.
- Even if it is, that everyone really needs that absolute fastest performance.
For us, I don’t think it’s really “marketing” that will win the day for Mongo. But will someone come along and say “our corporate direction is Mongo, either make it work with Mongo or we’ll take our million dollars elsewhere”? I’m thinking probably yes, if Mongo’s momentum continues, at some point someone will say this to us. (Similar to what happened for us with Couchbase.) And then we will really get to see whether the performance difference is real or folklore.
Does the AICD open up the optionality more?
Nope. As an end user I’m much more excited about Atlas than any of the features in 4.0. As mentioned in my earlier post, it seems a significant portion of my clients would like to stop worrying about database management. And, unlike a lot of other things, the interfaces to a database are well defined enough that I think the SLAs would work.
