4 ms·

This is from 2013 - honest question from someone that doesn't know, is it still relevant?

hobs 10y ago
If you read the post, the problem wasn't Mongo as much as they chose the new hotness (document db/graph model) when in reality their problem was already well solved by a RDBMS and tabular model, they had classic problems like duplicate data and performance issues when they tried to use a document db as a RDBMS. They changed over and everything was fine.
- 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 ago
    Without 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 ago
      MySQL 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 ago
        I 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.
- SmellTheGlove 10y ago
  OK, I read it, and that was my reaction as well, but I wasn't sure if it was due to my lack of Mongo knowledge or not. Apparently I understood it! :) I always struggle with when not to use an RDBMS, because I work with Teradata at the office and so far it hasn't let me down and there's been little pressure to find something new. And my industry (insurance) does not do new for the sake of new.

hobs 10y ago

If you read the post, the problem wasn't Mongo as much as they chose the new hotness (document db/graph model) when in reality their problem was already well solved by a RDBMS and tabular model, they had classic problems like duplicate data and performance issues when they tried to use a document db as a RDBMS. They changed over and everything was fine.

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 ago
  Without 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 ago
    MySQL 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 ago
      I 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.
SmellTheGlove 10y ago
OK, I read it, and that was my reaction as well, but I wasn't sure if it was due to my lack of Mongo knowledge or not. Apparently I understood it! :) I always struggle with when not to use an RDBMS, because I work with Teradata at the office and so far it hasn't let me down and there's been little pressure to find something new. And my industry (insurance) does not do new for the sake of new.