3 ms·

I didn't really have practical experience in mongodb. However, after checking latest mongodb documentation, it seems they have magically solved those issues in

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.

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.