4 ms·

I'm a bit surprised that Stripe uses Mongo? For financial transactions? Is it the primary backing store or a cache? I always thought of Mongo as the DB with

by chubot 4y ago

I'm a bit surprised that Stripe uses Mongo? For financial transactions? Is it the primary backing store or a cache? I always thought of Mongo as the DB with questionable durability and performance claims ... i.e. the "quick and dirty" DB. And also under-featured compared to relational DBs. But I haven't used it so maybe that is not accurate.

gqewogpdqa 4y ago
MongoDB is used by enterprises all over the world. It's true that it's the easiest DB to get started with, and it's also true that in the distant past (pre 3.0, back in ~2015), they had some issues. But they now run the financial backends of companies as varied as banks and coinbase and... https://www.mongodb.com/who-uses-mongodb https://www.mongodb.com/who-uses-mongodb
- jandrewrogers 4y ago
  MongoDB 3.x was broken too[0]. Their reputation for consistently shipping databases with fundamental design defects is well-deserved. Data loss was a hallmark of that product across multiple major versions. Maybe they've suddenly turned a new leaf in the last couple years but I wouldn't want to bet my business on it. Most of the companies I know that use it, use it for data that doesn't matter such that data loss isn't a big deal. [0] https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3
  - docmechanic 4y ago
    I wrote for the technical writing team at MongoDB when this "security issue" made the news. The precise problem was whether authentication was turned off/on by default for the default database, I believe, during installation. Product management initially chose this configuration to make it quicker for evaluators to get something up and running as quick as possible. The assumption was that no developer would actually use that in production. Further, the documentation clearly stated that this default configuration option was not secure. Blaming that data loss on MongoDB rather than the noob dev who deployed that evaluation configuration is as erroneous as the logic used by the noob dev. We hear it from developers all the time, so let me repeat it: User error. It's a thing.
    - magicalhippo 4y ago
      > We hear it from developers all the time, so let me repeat it: User error. It's a thing. And as developers, we should do our best to prevent the user from being able to make those errors.
      - docmechanic 4y ago
        Agreed. Unfortunately, getting most developers to pay attention to their users has historically been quite difficult. Asking them to distinguish between differing levels of technical expertise with the product within the same audience and for a specific context - noob devs with no product experience in this case - requires empathy for the user that is missing in most developers.
    - chubot 4y ago
      That evaluation isn't about security; it's about durability -- does the database actually save your data under all circumstances? In this Jepsen analysis, we develop new tests which show the MongoDB v0 replication protocol is intrinsically unsafe, allowing the loss of majority-committed documents. In addition, we show that the new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4. While the v0 protocol remains broken, fixes for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite. It does look like it was fixed though. I remember some mealy mouthing but maybe I got them confused with others subject to Jepsen tests ...
      - dilyevsky 4y ago
        The parent refers to an issue from 2016 when 30000 (!) dbs on the internet got deleted/ransomed. The fact they blame the customers for this and totally confuse this with data loss is kinda telling huh? Sounds like data integrity wasn’t a big thing internally at mongo after all
        docmechanic 4y ago
        I think we're conflating two different issues.
rglover 4y ago
AFAIK, most of the FUD around Mongo came from this article (and the subsequent "telephone" game that followed it): 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.... In practice, Mongo is a solid-enough database with its most valuable asset being its query language. I've worked on projects where it handles millions of records without any issue. Reaching this size of footprint is difficult unless you have a massive user base or you're working with transactional data. FWIW, the project in mind has a disk size of ~5GB which isn't much at all. Imagine most projects won't even get close to testing the limits of MongoDB and base their opinions of it on hearsay. Disclaimer: I'm a developer not a full-blown DB admin so I'm sure there's a specialist who has more details about specific performance issues.
- throw1234651234 4y ago
  Mongo FUD has more to do with the fact that RDS...es work better with almost any line of business application. The ONLY application I have ever seen Mongo, or any other key:document store work well is integrating with form.io for custom forms. And even then, RDS might have been a better choice.
  - rglover 4y ago
    Work better in what way? Speed? Reliability? Scalability? And is that based on direct experience or indirect?
    - cynusx 4y ago
      Simple operations like joining data together or filtering a table for a specific value are way more performant. They are also extremely common operations. Mongodb became obsolete when postgresql added the json column type.
    - throw1234651234 4y ago
      Extensive experience with the lower-end (in terms of revenue) Fortune 1000 companies. Every single cloud and MongoDB pushes horizontal scaling and sharding. This rarely a necessity in practice. Traditional RDS normalization is almost always necessary to keep clean data. As I said, I have used MongoDB extensively for non-normalized, client created forms, and it was fine for that, but I wouldn't do it again given the choice now. In more simple terms - when I work for a staffing agency and delete a profession from the database, I want the DB to yell at me about FK constraints that needs to be considered (e.g. millions of jobs and candidates set to that profession_id)

by chubot 4y ago

gqewogpdqa 4y ago

MongoDB is used by enterprises all over the world. It's true that it's the easiest DB to get started with, and it's also true that in the distant past (pre 3.0, back in ~2015), they had some issues. But they now run the financial backends of companies as varied as banks and coinbase and... https://www.mongodb.com/who-uses-mongodb https://www.mongodb.com/who-uses-mongodb

jandrewrogers 4y ago
MongoDB 3.x was broken too[0]. Their reputation for consistently shipping databases with fundamental design defects is well-deserved. Data loss was a hallmark of that product across multiple major versions. Maybe they've suddenly turned a new leaf in the last couple years but I wouldn't want to bet my business on it. Most of the companies I know that use it, use it for data that doesn't matter such that data loss isn't a big deal. [0] https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3
- docmechanic 4y ago
  I wrote for the technical writing team at MongoDB when this "security issue" made the news. The precise problem was whether authentication was turned off/on by default for the default database, I believe, during installation. Product management initially chose this configuration to make it quicker for evaluators to get something up and running as quick as possible. The assumption was that no developer would actually use that in production. Further, the documentation clearly stated that this default configuration option was not secure. Blaming that data loss on MongoDB rather than the noob dev who deployed that evaluation configuration is as erroneous as the logic used by the noob dev. We hear it from developers all the time, so let me repeat it: User error. It's a thing.
  - magicalhippo 4y ago
    > We hear it from developers all the time, so let me repeat it: User error. It's a thing. And as developers, we should do our best to prevent the user from being able to make those errors.
    - docmechanic 4y ago
      Agreed. Unfortunately, getting most developers to pay attention to their users has historically been quite difficult. Asking them to distinguish between differing levels of technical expertise with the product within the same audience and for a specific context - noob devs with no product experience in this case - requires empathy for the user that is missing in most developers.
  - chubot 4y ago
    That evaluation isn't about security; it's about durability -- does the database actually save your data under all circumstances? In this Jepsen analysis, we develop new tests which show the MongoDB v0 replication protocol is intrinsically unsafe, allowing the loss of majority-committed documents. In addition, we show that the new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4. While the v0 protocol remains broken, fixes for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite. It does look like it was fixed though. I remember some mealy mouthing but maybe I got them confused with others subject to Jepsen tests ...
    - dilyevsky 4y ago
      The parent refers to an issue from 2016 when 30000 (!) dbs on the internet got deleted/ransomed. The fact they blame the customers for this and totally confuse this with data loss is kinda telling huh? Sounds like data integrity wasn’t a big thing internally at mongo after all
      - docmechanic 4y ago
        I think we're conflating two different issues.

rglover 4y ago

AFAIK, most of the FUD around Mongo came from this article (and the subsequent "telephone" game that followed it): 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.... In practice, Mongo is a solid-enough database with its most valuable asset being its query language. I've worked on projects where it handles millions of records without any issue. Reaching this size of footprint is difficult unless you have a massive user base or you're working with transactional data. FWIW, the project in mind has a disk size of ~5GB which isn't much at all. Imagine most projects won't even get close to testing the limits of MongoDB and base their opinions of it on hearsay. Disclaimer: I'm a developer not a full-blown DB admin so I'm sure there's a specialist who has more details about specific performance issues.

throw1234651234 4y ago
Mongo FUD has more to do with the fact that RDS...es work better with almost any line of business application. The ONLY application I have ever seen Mongo, or any other key:document store work well is integrating with form.io for custom forms. And even then, RDS might have been a better choice.
- rglover 4y ago
  Work better in what way? Speed? Reliability? Scalability? And is that based on direct experience or indirect?
  - cynusx 4y ago
    Simple operations like joining data together or filtering a table for a specific value are way more performant. They are also extremely common operations. Mongodb became obsolete when postgresql added the json column type.
  - throw1234651234 4y ago
    Extensive experience with the lower-end (in terms of revenue) Fortune 1000 companies. Every single cloud and MongoDB pushes horizontal scaling and sharding. This rarely a necessity in practice. Traditional RDS normalization is almost always necessary to keep clean data. As I said, I have used MongoDB extensively for non-normalized, client created forms, and it was fine for that, but I wouldn't do it again given the choice now. In more simple terms - when I work for a staffing agency and delete a profession from the database, I want the DB to yell at me about FK constraints that needs to be considered (e.g. millions of jobs and candidates set to that profession_id)