3 ms·
before: mongodb is bad because it imposes we handle the case where we'd like to shard the db (which breaks joins). after: mysql is sooo much easier with joins.
by weddpros 10y ago
before: mongodb is bad because it imposes we handle the case where we'd like to shard the db (which breaks joins).
after: mysql is sooo much easier with joins. Who cares about sharding anyway.
I hope people understand distributed systems a bit better today, but I don't have high hopes.
- toast0 10y agoWithout any knowledge of mongodb; if using it means you have to handle sharding right away, and using MySQL means you have to handle sharding when you outgrow a single instance, isn't that a big deal? MySQL scales pretty well these days, I think, so you can get a huge box -- a lot of stuff will fit in 2TB of ram.
- weddpros 10y agoMySQL can't scale horizontally if you're using it like it's a relational database. No joins between shards means Sarah Mei could throw away her data model if she needs sharding. She would then need to denormalize her data to avoid joins, which is the main argument in the article. The project they were working on was a social network, a free alternative to Facebook. So I guess it's safe to say a single box, even the biggest you can imagine, could not ensure scalability. Beyond certain limits, sharding is the only option. Facebook has implemented exactly the denormalization despised in the article, and they're using MySQL, albeit just as a dumb key/value store ;-)
- toast0 10y agoI meant scale on a single box, sorry for confusion. It used to not be a great idea to get a really big SMP box to run MySQL because locking would kill performance; I think the locks are fine grained enough these days.