Earlier quoted context omitted.
Use PostgreSQL. https://www.postgresql.org/docs/10/static/datatype-json.html
or not, as the case may be https://www.mongodb.com/compare/mongodb-postgresql
That was a pretty trash piece of marketing.
MongoDB gets support for multi-document ACID transactions
151–160 of 245 posts
Re: MongoDB gets support for multi-document ACID transactions
#152Earlier quoted context omitted.
MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. I was going to say that I won't believe that it is on its way to being a decent database until after an article appears on https://aphyr.com/tags/jepsen saying that MongoDB actually delivers on what it claims. So I looked for the most recent analysis of MongoDB and found ht…
I have used MongoDB in production for a number of Fortune 100 sized companies. It has always been a unique database that was ideal for scenarios when your data model was document orientated. > was an overhyped steaming pile of shit for a very long time No it wasn't. This is something you heard from people who never really used it. It had its faults but it was never a pile of shit nor was it substantially worse than o…
This is something you heard from people who never really used it
I used it at a previous job. Project to move a multi-tera dataset from an Oracle box (24 CPUs, 24G RAM, SAN) to a MongoDB cluster (10 boxes, each with 48 cores, 96G RAM and internal SSD). MongoDB couldn't perform for shit, and it couldn't stay up in a usable state for more than a few hours at a time. This is with 20x the processors and 40x the memory of the system it was replacing. It's a complete joke of a product, sold on the basis of outright lies as far as what they told us and what it could actually do. Having been that badly burned I consider it an act of selfless public service to warn people off it.
If you're just using it for a personal blog that gets 10 views a day, sure it might be barely adequate for that. But I'd still use Postgres.
Re: MongoDB gets support for multi-document ACID transactions
#153Earlier quoted context omitted.
Epic had a post mortem blog post here that mentioned in passing they had stumped all the experts they could find to look at unsolveable issues they had with MongoDB. https://news.ycombinator.com/item?id=16340462 I kind of assumed the fix is going to be a rewrite with Postgres or MySQL.
- That's not what they said. - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ). MongoDB / MySQL have bad press by people that never used it in real life and just repeat what they read online.…
You can cluster with postgres & mysql, but you have to implement the clustering / sharding logic yourself.
Nowadays I would just use redis & cassandra if you need something beyond a collection of postgres instances. Most projects do not.
Re: MongoDB gets support for multi-document ACID transactions
#154Earlier quoted context omitted.
> I have a hard time understanding why devs choose / chose MongoDB. Postgres with JSON columns gets you so far, why would you go with MongoDB, given the issues it's had? Jsonb is a pretty recent addition to postgres, when compared with the MongoDB timeline. And even today postgres still doesn't have the replication/failover story that made MongoDB pretty compelling. I know, it's coming, whatever, but the point is tha…
The problem with that thinking is that the replication mattered. I'd argue it didn't, it was essentially a scam that people fell for. Who cares about failover when you're losing data due to a bad implementation? Who cares about replication when you can gain the same performance by using a performant database on a single node? Did mongodb truly allow anyone to really horizontally scale? Most places that need massive h…
The thing I don't understand about mongodb is that it makes a tradeoff for scalability.
The secret ingredient in the horizontal scaling sauce is giving up inter node ACID transactions.
Nothing prevents you from making the same tradeoff with mysql or postgresql.
Re: MongoDB gets support for multi-document ACID transactions
#155Earlier quoted context omitted.
Epic had a post mortem blog post here that mentioned in passing they had stumped all the experts they could find to look at unsolveable issues they had with MongoDB. https://news.ycombinator.com/item?id=16340462 I kind of assumed the fix is going to be a rewrite with Postgres or MySQL.
- That's not what they said. - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ). MongoDB / MySQL have bad press by people that never used it in real life and just repeat what they read online.…
I feel I need to quote the post mortem back at you so you point out where I mis read the quote.
"Our top focus right now is to ensure service availability. Our next steps are below: Identify and resolve the root cause of our DB performance issues. We’ve flown Mongo experts on-site to analyze our DB and usage, as well as provide real-time support during heavy load on weekends."
How does that disagree with my post?
Re: MongoDB gets support for multi-document ACID transactions
#156Next up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these types of databases is now that the major SQL players support JSON.
I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now ava…
How does MongoDB handle schema changes? For example, let's say I want to add a mobile phone field to a customer record type. How would I go about doing that in MongoDB?
Re: MongoDB gets support for multi-document ACID transactions
#157Earlier quoted context omitted.
I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now ava…
Its usually only after a while you realize almost every piece of meaningful data is relational. It just didn't look that way when the project started. But now you're committed on the wrong database and its very costly to switch back to SQL. Literally every project I saw using MongoDB ended up going back to SQL within the first 2 years after realizing the data is indeed very much relational and theres no clean way to…
> "I believe Datomic to be the game changing database"
Have you used it? If so, what was your use case?
Re: MongoDB gets support for multi-document ACID transactions
#158Re: MongoDB gets support for multi-document ACID transactions
#159We have been using mongo over the last three years on our project and it has been pretty smooth so far. However, lately I gave some thoughts into what our project would look like if we used PostgreSQL instead. I tried to figure out what problems Mongo solves that PostgreSQL doesn't. I am far from being a database expert, I just know enough basics to query what I need, so feel free to correct/complete the following: -…
Honestly, the existence of Mongo is mostly an indictment about how user-hostile conventional RDBMS is. The fact that other DBs can do what Mongo does is not helpful when there is no easy workflow to do what Mongo does. The fact that I theoretically implement a web-based CMS in C and it could be more performant than all these web-language CMS products doesn't mean that C is better for making a CMS.
> "Honestly, the existence of Mongo is mostly an indictment about how user-hostile conventional RDBMS is."
That's nonsense. I've taught people to use SQL before, even people with little to no programming experience. After the initial concepts were understood it was fairly easy to gradually expand knowledge over time.
The basic SQL keywords to start getting useful information out of a RDBMS are:
SELECT
FROM
WHERE
INNER JOIN
LEFT JOIN
ON
AS
AND
OR
Those 9 keywords give you a good starting point for exploring SQL. It's really not hard. You could probably learn enough to get started in a couple of hours, and it's easy to expand your knowledge as and when you need to once you've got the basics sorted.
Re: MongoDB gets support for multi-document ACID transactions
#160MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…
It's linked in the RethinkDB essay, but it's always worth explicitly calling out the "Worse Is Better" essay: http://dreamsongs.com/RiseOfWorseIsBetter.html Ignore its lessons at your peril. Your job isn't to build an engineering masterpiece. Your job, as pg says, is to build something people want.
Shipping early and working on stability later may work for something like a video game but not for a database my system depends on thanks