3 ms·

I'm interested in learning more about MongoDB so that I can use it for web apps. But some comments I've heard about it(especially here https://plus.google.com/1

by samrat 15y ago

I'm interested in learning more about MongoDB so that I can use it for web apps. But some comments I've heard about it(especially here https://plus.google.com/111091089527727420853/posts/WQYLkopE813 https://plus.google.com/111091089527727420853/posts/WQYLkopE...) seemed to discourage its use. Can someone explain to me why it is "criticized by academics"? And what its pros/cons are?

cheald 15y ago
The biggest criticism, for a long time, was that it wasn't guaranteed consistent; a crash could leave your DB in an inconsistent state, and you were supposed to address this by writing data to multiple nodes before deciding it was okay. This is rather mitigated now with the journaling options (which are on by default). There are lots of other criticisms, but it's a fine data store, if you're dealing with data that fits it well. The best way to think of it is as a hash store - you can store N-deep hashes in it, index pieces of those hashes so you can find whole records ("documents") quickly, and that sort of thing. You can't perform table joins (or don't have to, depending on who you're talking to), but you mitigate that by designing your data such that you get what you need for a given resource in a single query. Personally, I'm all on board with it for web apps. I think it fits your typical web app's data requirements far more closely than a traditional RDBMS does, and I'm using it very successfully in multiple production systems. The biggest remaining fault, in the context of web apps (IMO) is the lack of transactions - if you have an application that requires transactions to ensure proper operation, don't use Mongo. Do recognize, though, that many transactional use cases are replaced with Mongo's atomic operation set.
- randomdata 15y ago
  > The biggest remaining fault, in the context of web apps (IMO) is the lack of transactions While not ACID, "tension" documents are a good way to add a level of transactional support. For example, if you want to update multiple documents, instead of modifying the original documents directly, you create a new document with instructions on how to update the original documents. Then, you roll through the tension documents and apply their changes. Any failures can be dealt with on subsequent passes, only removing the document from the scan once it has been successfully applied. It is an eventually consistent pattern, but that is a tradeoff you have already accepted by choosing MongoDB in the first place, so it ends up working well for a lot of transaction use cases.
  - mathias_10gen 15y ago
    Its actually possible to be fully consistent if you include the "tension" documents when fetching the main docs. For example, in the canonical transaction example of Alice giving Bob $5 you could insert a document in the transactions collection that says Alice gave Bob $5. When you go to fetch Alice's pending balance you fetch her current document, then you fetch all pending transactions than she is involved in. Same for Bob and all other users. Then each night, you pull that days transactions and apply them to each user and update an "as of" field to make sure no transaction can ever be applied twice. Now you could argue that this isn't fully consistent because it is possible for Alice to simultaneously give $5 to both Bob and Charlie even if she only has $7 in her account. However she will then have a pending balance of $-3 so it immediately reflects her current situation. This is similar to the real world example of overdrawing you checking account. If you wanted to, you could void one or both of those transactions if you never want to allow a user to go negative.
    - St-Clock 15y ago
      The system you describe, recording events and replaying events to get the actual state of the system, usually assumes that you can only write one event at a time (writes need to be super cheap). If you can write multiple events in parallel, you won't have isolation and you may read tension documents that will be voided (in your example). You could use optimistic concurrency control to ensure that only one tension document is written at a time while ensuring that your constraints are respected: current_id = atomic increment global state_id create tension document (but with active bit set to false) check constraints atomic: if global state_id = current_id set active bit to true if active bit is false: delete tension document and report error This would provide isolation (you don't see tension documents that are not yet validated) and consistency (your balance is respected). The atomic operation in RDBMS is usually implemented in one very simple and fast SQL UPDATE query. I believe mongo must provide something similar too. Although my bank would allow me to overdraw from my checking account, I have a higher margin/tolerance than my brother, so they must perform some constraints check ;-)
  - cheald 15y ago
    That's a really clever idea. I'll have to give that a shot - I wonder how hard it'd be to wrap up that pattern for use in the popular ODMs?
bigethan 15y ago
Anecdotally: Mongo is great for developing small projects. It's fun to work with since it's got no defined structure, and will just save whatever you give it wherever you say to. That flexibility comes back to haunt it in larger projects. A typo in a query can trigger a reindex of a huge collection, make moot GBs of index data, or invalidate other queries that work on the same collection. It also demands that the devs do lots of documentation on the data structures as you can't ask mongo to tell you it's schema, it's just a collection of documents. And if you work with a loosely typed language, be sure to type your inserts as mongo is not a loosely typed datastore (coughPHPcough). But for internal tools, and smaller projects, the speed of development is great.
- bricestacey 15y ago
  Some ODMs like Mongoid have a strict mode that requires a field to be mapped in order to save it to the db. This saves you from typos wrecking havoc. You should probably unit test your queries anyway.
  - gregwebs 15y ago
    yep, either use an ODM (or some system that guarantees correctness) or make sure your raw queries are well tested.
  - FuzzyDunlop 15y ago
    Yeah. Mongoose on Node requires you to code and instantiate a document schema before you can do anything with the database. Gotta sacrifice some flexibility for a bit of safety.
- rbranson 15y ago
  ... and if that wasn't bad enough, then the global locks and mmap'd I/O haunts you later when you have any sort of concurrency or for data>RAM, or the first time you have to take the site down to perform a compaction. Can you tell I've been burned?
antirez 15y ago
If you search for a second you'll find bad things about every DB out there, my idea is that it is better to pick a product that seems designed for your use case and try it first hand. Stress it, socialize with it, and in a few days it will be clear if it is worth investing more time or not. After all for every bad blog post about Mongo, Redis, Cassandra, and so forth, there are many good as well, so you can collectively consider this blog posts as personal experiences worth ten min of your time but possibly not so important to change your mind about trying it first hand.

by samrat 15y ago

cheald 15y ago

The biggest criticism, for a long time, was that it wasn't guaranteed consistent; a crash could leave your DB in an inconsistent state, and you were supposed to address this by writing data to multiple nodes before deciding it was okay. This is rather mitigated now with the journaling options (which are on by default). There are lots of other criticisms, but it's a fine data store, if you're dealing with data that fits it well. The best way to think of it is as a hash store - you can store N-deep hashes in it, index pieces of those hashes so you can find whole records ("documents") quickly, and that sort of thing. You can't perform table joins (or don't have to, depending on who you're talking to), but you mitigate that by designing your data such that you get what you need for a given resource in a single query. Personally, I'm all on board with it for web apps. I think it fits your typical web app's data requirements far more closely than a traditional RDBMS does, and I'm using it very successfully in multiple production systems. The biggest remaining fault, in the context of web apps (IMO) is the lack of transactions - if you have an application that requires transactions to ensure proper operation, don't use Mongo. Do recognize, though, that many transactional use cases are replaced with Mongo's atomic operation set.

randomdata 15y ago
> The biggest remaining fault, in the context of web apps (IMO) is the lack of transactions While not ACID, "tension" documents are a good way to add a level of transactional support. For example, if you want to update multiple documents, instead of modifying the original documents directly, you create a new document with instructions on how to update the original documents. Then, you roll through the tension documents and apply their changes. Any failures can be dealt with on subsequent passes, only removing the document from the scan once it has been successfully applied. It is an eventually consistent pattern, but that is a tradeoff you have already accepted by choosing MongoDB in the first place, so it ends up working well for a lot of transaction use cases.
- mathias_10gen 15y ago
  Its actually possible to be fully consistent if you include the "tension" documents when fetching the main docs. For example, in the canonical transaction example of Alice giving Bob $5 you could insert a document in the transactions collection that says Alice gave Bob $5. When you go to fetch Alice's pending balance you fetch her current document, then you fetch all pending transactions than she is involved in. Same for Bob and all other users. Then each night, you pull that days transactions and apply them to each user and update an "as of" field to make sure no transaction can ever be applied twice. Now you could argue that this isn't fully consistent because it is possible for Alice to simultaneously give $5 to both Bob and Charlie even if she only has $7 in her account. However she will then have a pending balance of $-3 so it immediately reflects her current situation. This is similar to the real world example of overdrawing you checking account. If you wanted to, you could void one or both of those transactions if you never want to allow a user to go negative.
  - St-Clock 15y ago
    The system you describe, recording events and replaying events to get the actual state of the system, usually assumes that you can only write one event at a time (writes need to be super cheap). If you can write multiple events in parallel, you won't have isolation and you may read tension documents that will be voided (in your example). You could use optimistic concurrency control to ensure that only one tension document is written at a time while ensuring that your constraints are respected: current_id = atomic increment global state_id create tension document (but with active bit set to false) check constraints atomic: if global state_id = current_id set active bit to true if active bit is false: delete tension document and report error This would provide isolation (you don't see tension documents that are not yet validated) and consistency (your balance is respected). The atomic operation in RDBMS is usually implemented in one very simple and fast SQL UPDATE query. I believe mongo must provide something similar too. Although my bank would allow me to overdraw from my checking account, I have a higher margin/tolerance than my brother, so they must perform some constraints check ;-)
- cheald 15y ago
  That's a really clever idea. I'll have to give that a shot - I wonder how hard it'd be to wrap up that pattern for use in the popular ODMs?

bigethan 15y ago

Anecdotally: Mongo is great for developing small projects. It's fun to work with since it's got no defined structure, and will just save whatever you give it wherever you say to. That flexibility comes back to haunt it in larger projects. A typo in a query can trigger a reindex of a huge collection, make moot GBs of index data, or invalidate other queries that work on the same collection. It also demands that the devs do lots of documentation on the data structures as you can't ask mongo to tell you it's schema, it's just a collection of documents. And if you work with a loosely typed language, be sure to type your inserts as mongo is not a loosely typed datastore (coughPHPcough). But for internal tools, and smaller projects, the speed of development is great.

bricestacey 15y ago
Some ODMs like Mongoid have a strict mode that requires a field to be mapped in order to save it to the db. This saves you from typos wrecking havoc. You should probably unit test your queries anyway.
- gregwebs 15y ago
  yep, either use an ODM (or some system that guarantees correctness) or make sure your raw queries are well tested.
- FuzzyDunlop 15y ago
  Yeah. Mongoose on Node requires you to code and instantiate a document schema before you can do anything with the database. Gotta sacrifice some flexibility for a bit of safety.
rbranson 15y ago
... and if that wasn't bad enough, then the global locks and mmap'd I/O haunts you later when you have any sort of concurrency or for data>RAM, or the first time you have to take the site down to perform a compaction. Can you tell I've been burned?

antirez 15y ago

If you search for a second you'll find bad things about every DB out there, my idea is that it is better to pick a product that seems designed for your use case and try it first hand. Stress it, socialize with it, and in a few days it will be clear if it is worth investing more time or not. After all for every bad blog post about Mongo, Redis, Cassandra, and so forth, there are many good as well, so you can collectively consider this blog posts as personal experiences worth ten min of your time but possibly not so important to change your mind about trying it first hand.