Earlier quoted context omitted.
> it's an unlikely success story that deserves admiration Well, it's a success story due to marketing, smart marketing, clever marketing, and more marketing, not due to lots of technical merits. And it was not the first document store to appear, just the most successful. For starters, CouchDB was previous to MongoDB.
Couch was a nightmare to use, mingo made all the friction to get it into products go away, especialy when teamed with dynamic languages.
MongoDB shares jump more than 30% in $192M IPO
91–100 of 425 posts
Re: MongoDB shares jump more than 30% in $192M IPO
#92Earlier quoted context omitted.
It really is an interesting story. They aren't best in class in any of the metrics we think of as mattering. It's not the highest scale system out there. It's not the most durable. Or the most available. Hell it's not even particularly reliable (at least throughout its history). It is however..simple. Very simple. It's easy to reason about. It's easy to setup. For 90% of use cases it's very easy to administer. It tur…
> It's easy to reason about. ...until it's not. Then it's really not.
Re: MongoDB shares jump more than 30% in $192M IPO
#93Earlier quoted context omitted.
RDBMS makes sense for most applications. Most applications store data that can be fit to the relational model. Most applications aren't big data or data mining OLAP. Most RDBMSs can do key-value stores very well now. Most applications also care more about consistency over availability, which is what RDBMSs do (CAP theorem). Many NoSQL data stores choose availability and partitioning and sacrifice consistency (i.e., "…
You don't seem to know this, but no traditional RDBMSs actually provide CAP consistency, for that they would have to use at least two-phase commit or something, but they don't. So, they all are noCAP databases. Electronic health or financial records are way safer in a proper eventually consistent database, like orders of magnitude safer, but everyone just takes the risk with some insurance at best to cover the losses…
Re: MongoDB shares jump more than 30% in $192M IPO
#94Earlier quoted context omitted.
> That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.
What is an example of non-relational data? A tree is relational. Each child has a relation to its parent. I can't imagine data that has no relation (no connection) to anything else. Maybe what you meant was heterogeneous (e.g. data elements that do not all have the same attributes) - but even then I can't readily come up with an example.
In years past, people called these "data warehouses" and essentially took snapshots of their production DBs and denormalized the hell out of them so that aggregations wouldn't crash the server.
Re: MongoDB shares jump more than 30% in $192M IPO
#95I don't understand why everyone is so happy when IPOs go up and make it sound like a good event. I see it as the founders needlessly missing out on 30% of money (in this case), which ends up going in the pockets of the Wall Street middle men that get first access to the stock offering.
If you IPO at 24 and it jumps to 32, hopefully it is still 30 when you can sell. If you IPO at 32 and it drops to 26 cause there is no buzz, you make a lot less when you sell.
Re: MongoDB shares jump more than 30% in $192M IPO
#96Earlier quoted context omitted.
They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The…
These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.h...
Re: MongoDB shares jump more than 30% in $192M IPO
#97Earlier quoted context omitted.
Except when you poison mindshare. For example, I used Mongo back in the early days. Was terrible. I will now never use it again. I don't care if it shoots lasers. It is dead to me. Obviously the happy developer count is way more than the hate it for life count, so I am the odd man out here. Perhaps many users never actually had many GB of data or had to deal with the data loss side of things?
[apparently my opinion is unwanted]
Re: MongoDB shares jump more than 30% in $192M IPO
#98MongoDB isn't usually seen favorably but everyone must admit that it's an unlikely success story that deserves admiration. Think about it. Bringing a database to the market with a completely different paradigm, growing it to the enterprise-production-ready level, and creating a billion-dollar business around is no small deal. Yes, they did ride the NoSQL zeitgeist but they survived when others had no major success. U…
If they had done so by presenting a product that was picked up due to it's merit and continued to gain traction based on that then I'd be rather impressed. Instead the story of MongoDB seems to be how extremely well targeted marketing and sales can build a so-so product into a huge IPO, there have been performance comparisons showing it isn't even the best at what it does so this IPO is riding on the network effect o…
It is extremely difficult to do good marketing and sales and they did it.
Solve a customer problem while building a healthy business... a success story in my book.
Re: MongoDB shares jump more than 30% in $192M IPO
#99Earlier quoted context omitted.
You don't seem to know this, but no traditional RDBMSs actually provide CAP consistency, for that they would have to use at least two-phase commit or something, but they don't. So, they all are noCAP databases. Electronic health or financial records are way safer in a proper eventually consistent database, like orders of magnitude safer, but everyone just takes the risk with some insurance at best to cover the losses…
In certain environments, it is better to fail then to have data that isn't immediately consistent. Finance and healthcare are two such systems. Availability is not always paramount. https://en.wikipedia.org/wiki/Database_transaction https://en.wikipedia.org/wiki/Atomicity_(database_systems)
Although I kind of got used to RDBMS crowd not understanding consistency, it's just another technology cult.