3 ms·

Yeah, I know this is true, and we always try to remember to understand that the engineering decisions that were made at the time were made for good reasons give

Yeah, I know this is true, and we always try to remember to understand that the engineering decisions that were made at the time were made for good reasons given the circumstances we were facing. It helps that I was one of the people who made those decisions at the time, so I know we were making what we thought were the best decisions at the time. Still wish we had made some different ones, though!

josephg 6y ago
Hear hear! I worked at a startup a handful of years ago which decided early on that mongodb was good enough. We figured we'd move to a proper database down the road. Spoilers: That never happened - the longer we used mongo, the more expensive migrating became. We never did manage to justify the migration. As far as I know the team is still stuck with it, and paying the price. (If you're reading this and you know who you are, I'm sorry!)
- rubyist5eva 6y ago
  Never use MongoDB. Ever. It's a rule of thumb that hasn't led me astray yet. http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
  - dominotw 6y ago
    > It's a rule of thumb that hasn't led me astray yet. How can you know if your decision is correct if you never use it in the first place. Isn't it like only implementing A version of A/B and concluding that not implementing B version was a good decision.
  - jcpst 6y ago
    Meh. I read the article, and I agree with it. But that is not what you are saying. Don’t use it for relational data. Don’t use it as your primary data store. At the enterprise I work at, I’ve had success delivering features where data science would have some job that aggregates production data and dumps it to kafka. Then we’ll map it and dump it in mongo. Stick a .net core microservice on top for retrieval. Works great, has none of the problems mentioned in that article. Of course, this might not make sense if you’re not big enough to where you need kafka, kubernetes, etc But “Never use it” is certainly not good advice.
  - karmakaze 6y ago
    This part is totally misguided. > What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead. Even with a normalized relational database one wouldn't make a single query to return rows from a join of tables T1, T2, T3, etc when there are repeating relations such as the users in the social graph. This might be done sometimes paying for the duplication to save a network round trip, that's all and no different.
    - debaserab2 6y ago
      A list of activities joined to users wouldn't be a problem for an RDBMS. I'm not sure what you mean by "repeating relations".
      - karmakaze 6y ago
        The deep relations (7-table join) example in the link is something I wouldn't do (including the repeated 'user' entities) with an RDBMS, given that I expect some elements of some tables to appear multiple times, that's a waste of I/O and hard to cache. > Users have friends, friends have posts, posts have comments and likes, each comment has one commenter and each like has one liker. I would likely gather all the instances of User id in each context (user, friend, commenter, and liker) and query it separately from the JOIN query. Depends on your data which way works out better on average/worst-cases.
- zozbot234 6y ago
  > I worked at a startup a handful of years ago which decided early on that mongodb was good enough. We figured we'd move to a proper database down the road. Yeah, that can't end well. It's a bit ironic from parent poster's viewpoint but "boring", well-understood technology is generally also the easiest to migrate away from. That's one key reason to choose it at the outset even over more "innovative" and perhaps more "ergonomic" choices like mongo, that in reality aren't nearly as simple to deal with.

josephg 6y ago

Hear hear! I worked at a startup a handful of years ago which decided early on that mongodb was good enough. We figured we'd move to a proper database down the road. Spoilers: That never happened - the longer we used mongo, the more expensive migrating became. We never did manage to justify the migration. As far as I know the team is still stuck with it, and paying the price. (If you're reading this and you know who you are, I'm sorry!)

rubyist5eva 6y ago
Never use MongoDB. Ever. It's a rule of thumb that hasn't led me astray yet. http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
- dominotw 6y ago
  > It's a rule of thumb that hasn't led me astray yet. How can you know if your decision is correct if you never use it in the first place. Isn't it like only implementing A version of A/B and concluding that not implementing B version was a good decision.
- jcpst 6y ago
  Meh. I read the article, and I agree with it. But that is not what you are saying. Don’t use it for relational data. Don’t use it as your primary data store. At the enterprise I work at, I’ve had success delivering features where data science would have some job that aggregates production data and dumps it to kafka. Then we’ll map it and dump it in mongo. Stick a .net core microservice on top for retrieval. Works great, has none of the problems mentioned in that article. Of course, this might not make sense if you’re not big enough to where you need kafka, kubernetes, etc But “Never use it” is certainly not good advice.
- karmakaze 6y ago
  This part is totally misguided. > What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead. Even with a normalized relational database one wouldn't make a single query to return rows from a join of tables T1, T2, T3, etc when there are repeating relations such as the users in the social graph. This might be done sometimes paying for the duplication to save a network round trip, that's all and no different.
  - debaserab2 6y ago
    A list of activities joined to users wouldn't be a problem for an RDBMS. I'm not sure what you mean by "repeating relations".
    - karmakaze 6y ago
      The deep relations (7-table join) example in the link is something I wouldn't do (including the repeated 'user' entities) with an RDBMS, given that I expect some elements of some tables to appear multiple times, that's a waste of I/O and hard to cache. > Users have friends, friends have posts, posts have comments and likes, each comment has one commenter and each like has one liker. I would likely gather all the instances of User id in each context (user, friend, commenter, and liker) and query it separately from the JOIN query. Depends on your data which way works out better on average/worst-cases.
zozbot234 6y ago
> I worked at a startup a handful of years ago which decided early on that mongodb was good enough. We figured we'd move to a proper database down the road. Yeah, that can't end well. It's a bit ironic from parent poster's viewpoint but "boring", well-understood technology is generally also the easiest to migrate away from. That's one key reason to choose it at the outset even over more "innovative" and perhaps more "ergonomic" choices like mongo, that in reality aren't nearly as simple to deal with.