4 ms·

Does it take hold purely because it’s easy to install and the company has a hyper-aggressive salesforce?

golergka 6y ago
There's a lot of beginner developers who have somehow not yet ran into problems that a proper relational OLTP would prevent, and love the initial ease of development that Mongo provides for small projects. Some of them go freelance as web developers and complete quite a lot of small projects for small clients without seeing any problems.
jlouis 6y ago
MongoDB is really easy to set up and the library API is really good. This provides the affordance in the start of a project where you don't have to think that much about system load from users. You don't have to think that much about your relational model, so you can postpone all kinds of nasty questions about data integrity and multiplicity early on. This enables a team to move fast and break things. The switch to something like Postgres comes later in the project where you know your requirements better and you need a system where you have more control over your data. You might even have a person responsible for maintaining your data for you on the payroll. Personally, I usually just grab Postgres these days and use `json` columns for the documents and loosely fitting data, then drag out things into a more relational model as we go.
- richajak 6y ago
  I didn't really have practical experience in mongodb. However, after checking latest mongodb documentation, it seems they have magically solved those issues in the last few years how about these assumptions or myths? a. treat it as in-memory document database. expect to lose data if it does not successfully write to disk periodically. b. concurrent reading and writing. it claims that it is resolved for specific scenario in multiple document-level concurrency,while put a lock on single document issue. c. Total data storage should not be bigger than memory, although it was fixed in v3.2 with new database engine. d. multi document queries introduced in 4.2 and 4.4, however it is conflicting with their own recommendations that says Each document should be independent, denormalized data model. I like their syntax, feel so natural. postgres jsonb syntax is unreadable, a bit hacky for me. should i be concerned with mongodb myths?
  - SergeAx 6y ago
    If you mean fetching/updating foreign-key-related documents by "multi documents queries", I wouldn't do it in RDBMS too. There's no special magic inside RDBMS made those queries much better than fetching related docs manually, but there are always some dark corner cases which will bring your database to full stop in most unfortunate times.
    - jeltz 6y ago
      Why do you think some simple joins would risk to "bring your database"? It is code which is used all the time by tons of applications and not "some dark corner cases".
      - SergeAx 6y ago
        Try to figure out how it will work if both tables are sharded between partitions and some junior engineer will implement `LIMIT x SKIP y` REST pattern on that `SELECT FROM a INNER JOIN b` request with non-primary index sorting, for example.
  - Too 6y ago
    a) Depends if you run with replication and how you've configured your writeconcern (w and j values). https://docs.mongodb.com/manual/reference/write-concern/#acknowledgment-behavior https://docs.mongodb.com/manual/reference/write-concern/#ack... This is giving you the choice where in the CAP triangle you want to be. As you can see the default of w:1 and j:null when run in non replicated mode does not write journal to disk before ack. If you want better guarantees read some best-practice articles, most of them recommend w: majority, especially when run in replication. c) no issue d) $lookup works fine and is as old as 3.2, but as with any join, if you try to combine 2 tables with millions of rows each, performance will be bad. That said it's not as good as RDBMS here. No foreign keys or voodoo under the hood optimizations for example. Mongodb sales people will always say that you should model your data differently, without really giving good examples of such. But really - even if multi document queries exist, you should not continue modeling data as BCNF and think of mongo as a drop in replacement for RDBS, the domain should be suited for denormalized documents to begin with.

There's a lot of beginner developers who have somehow not yet ran into problems that a proper relational OLTP would prevent, and love the initial ease of development that Mongo provides for small projects. Some of them go freelance as web developers and complete quite a lot of small projects for small clients without seeing any problems.

jlouis 6y ago

MongoDB is really easy to set up and the library API is really good. This provides the affordance in the start of a project where you don't have to think that much about system load from users. You don't have to think that much about your relational model, so you can postpone all kinds of nasty questions about data integrity and multiplicity early on. This enables a team to move fast and break things. The switch to something like Postgres comes later in the project where you know your requirements better and you need a system where you have more control over your data. You might even have a person responsible for maintaining your data for you on the payroll. Personally, I usually just grab Postgres these days and use `json` columns for the documents and loosely fitting data, then drag out things into a more relational model as we go.

richajak 6y ago
I didn't really have practical experience in mongodb. However, after checking latest mongodb documentation, it seems they have magically solved those issues in the last few years how about these assumptions or myths? a. treat it as in-memory document database. expect to lose data if it does not successfully write to disk periodically. b. concurrent reading and writing. it claims that it is resolved for specific scenario in multiple document-level concurrency,while put a lock on single document issue. c. Total data storage should not be bigger than memory, although it was fixed in v3.2 with new database engine. d. multi document queries introduced in 4.2 and 4.4, however it is conflicting with their own recommendations that says Each document should be independent, denormalized data model. I like their syntax, feel so natural. postgres jsonb syntax is unreadable, a bit hacky for me. should i be concerned with mongodb myths?
- SergeAx 6y ago
  If you mean fetching/updating foreign-key-related documents by "multi documents queries", I wouldn't do it in RDBMS too. There's no special magic inside RDBMS made those queries much better than fetching related docs manually, but there are always some dark corner cases which will bring your database to full stop in most unfortunate times.
  - jeltz 6y ago
    Why do you think some simple joins would risk to "bring your database"? It is code which is used all the time by tons of applications and not "some dark corner cases".
    - SergeAx 6y ago
      Try to figure out how it will work if both tables are sharded between partitions and some junior engineer will implement `LIMIT x SKIP y` REST pattern on that `SELECT FROM a INNER JOIN b` request with non-primary index sorting, for example.
- Too 6y ago
  a) Depends if you run with replication and how you've configured your writeconcern (w and j values). https://docs.mongodb.com/manual/reference/write-concern/#acknowledgment-behavior https://docs.mongodb.com/manual/reference/write-concern/#ack... This is giving you the choice where in the CAP triangle you want to be. As you can see the default of w:1 and j:null when run in non replicated mode does not write journal to disk before ack. If you want better guarantees read some best-practice articles, most of them recommend w: majority, especially when run in replication. c) no issue d) $lookup works fine and is as old as 3.2, but as with any join, if you try to combine 2 tables with millions of rows each, performance will be bad. That said it's not as good as RDBMS here. No foreign keys or voodoo under the hood optimizations for example. Mongodb sales people will always say that you should model your data differently, without really giving good examples of such. But really - even if multi document queries exist, you should not continue modeling data as BCNF and think of mongo as a drop in replacement for RDBS, the domain should be suited for denormalized documents to begin with.