8 ms·

MongoDB 2.0 Released

215 points by meghan 15y ago

nirvana 15y ago
I'm curious as to why MongoDB is so popular. I chose Riak, and my purpose here isn't to bash Mongo, but to understand what was the key feature that made you choose it? Is it pure speed on a single machine? Is it the query interface? Something else? Datacenter awareness? Geographic support? The key features that made me choose riak: - built in distribution/clustering with homogenous nodes - bitcask had the level of reliability/design that I was looking for. - better impedance match for what I was doing than CouchDB (which was what I looked at before choosing riak, but couch does view generation when data is added and I need to be able to do it more dynamically.) What sold you on Mongo? What would you most like to improve? (Please don't let this be a debate, I'm more interested in understanding the NoSQL market, what other developers priorities are, etc.)
- va_coder 15y ago
  I was up and running with MongoDB in minutes. I tried Riak a while ago and the "getting started" experience was very poor IMO. Also, I really like the MongoDB docs. Can you point me to a great getting started page for Riak (setting it up, loading in data, doing advanced queries, Python/Ruby libraries etc)?
  - nosequel 15y ago
    http://wiki.basho.com/The-Riak-Fast-Track.html http://wiki.basho.com/The-Riak-Fast-Track.html It is being updated now for Riak 1.0.
  - arctangent 15y ago
    I haven't tried Riak but I will confirm that MongoDB was really easy to get started with. It's performant enough that I don't really need to look at anything else right now.
- enjo 15y ago
  For me: - Well supported and very active community. It's a project that is clearly going to be moving forward for a long time. - For my needs (structured data) it's super fast. - The auto-sharding support is nifty. - Geo-spatial queries out of the box
- old-gregg 15y ago
  Things we're using it for here at http://mailgun.net http://mailgun.net : * Fast asynchronous writes for non-critical data (logs). * Replica sets allow for zero-downtime hot failover to a backup server when the primary is taken down or dies. * Simple queries are crazy fast, assuming your index fits in RAM. * find_and_modify() feature is awesome for some tasks. But we're supplementing Mongo with PostgreSQL because of the following Mongo weaknesses: * Concurrency is so-so: the entire database is locked during writes. * Weak aggregation capabilities. * Greatly reduced performance when the index doesn't fit in RAM. * Wasteful when it comes to allocating space (on disk and in RAM)
  - philjackson 15y ago
    With one hand you giveth; "Fast asynchronous writes" and the other taketh away; "Concurrency is so-so: the entire database is locked during writes.".
    - rbranson 15y ago
      It's like unsuspecting developers are walking down Developer Lane and see a candy bar sitting there that says "FAST, ASYNCHRONOUS WRITES." So they pick it up, bite into it, and then the candy bar grows a giant mutant global lock head that eats their face.
    - old-gregg 15y ago
      Actually I don't believe the two are related. And they're working on the concurrency improvements all the time: https://jira.mongodb.org/browse/SERVER-1240 https://jira.mongodb.org/browse/SERVER-1240
      - philjackson 15y ago
        Can you explain how they're not related? I'm not poking you to start a fight, I'm genuinely curious.
        samstokes 15y ago
- angelbob 15y ago
  MongoDB is a surprisingly short hop from SQL databases in a lot of ways. It makes retraining your already-SQL-competent developers much easier than with many other datastores.
  - larrywright 15y ago
    This is my main reason for using it as well. For me, MongoDB is less about any of the NoSQL features, but more about the fact that I can be more productive with it. Pair it with a good library like MongoMapper, and persisting your data is trivial.
- cheald 15y ago
  I actually started in Riak before Mongo, and what made the decision for me was...not having to install Erlang. I realize that's not really a compelling argument, but when I was evaluating alternate DBs, the one that gets up and running the fastest is likely to get a little more attention from me. Once I got spun up on Mongo, I didn't find a compelling reason to switch away from it. "Download and unpack the package, run the binary, and you can instantly start playing with the examples from the console" is a hell of a good way to get people interested in your software.
  - aphyr 15y ago
    wget http://downloads.basho.com/riak/riak-0.14/riak_0.14.2-1_amd64.deb dpkg -i riak_0.14.2-1_amd64.deb Our production configuration and setup/deploy recipes for riak are 241 lines in total, ~150 of which are the stock config files.
    - cheald 15y ago
      This would have been something like 18 months ago, and was on an older Fedora box. It wasn't quite so trivial as that two-liner.
  - rbranson 15y ago
    Ease of first time developer installation should never be the deciding factor in these decisions. I realize it is pretty rampant, but it's not something we should be proud of.
    - SystemOut 15y ago
      Yeah but how long should I spend on software that I know nothing about the quality of if it's not easy to get up and running? Do you spend a day? two days? While it's mostly just from experience I find that virtually no one makes a decision based on how easy it is to get up and running with a piece of software but it is an impression that stick's in people's minds and gets repeated when they talk about it later.
    - cheald 15y ago
- whyme 15y ago
  I struggle choosing. I started both at the same time and keep going back and forth. Riak -> I love the fault tolerance -> easier to scale with a dreamworld of hash-rings I wish I could have. -> no indexes -> no Geo-spatial indexes -> I don't like link walking... it's not intuitive. -> I want to use Riak (Lucerne/Solr like) full text search, but the docs are poor and have to read dozens of useless documents to get nowhere very quickly. It's a separate install that requires pre-commits?(which are never explained well enough to start using it). -> installing on Mac OSX is painful (homebrew works/doesn't work depending on version, 32 bit or 64? how come I don't have include 32bit flags with older repo's, yet newer ones are only 64bit yet don't compile.... errors errors errors...ERLANG which? such a pain in the ass installing Riak unless you do it using specific build tools. -> Only Joyent provides a hosted solution which is too expensive relative to its offering. -> accepts any docs just set the content type.. handles original documents without conversions -> easy to load balance behind NGINX -> can choose between conflicting writes MongoDB -> straight forward install.. up and running in no time -> SQL like queries -> intuitive indexes -> Geo-spatial indexes -> Affordable hosted services with more than one provider. -> no full text searching over documents -> have to fiddle with doc handling GRIDFS etc.. -> can't choose between conflicting writes (last one wins) I wish I could have "RiaMong" -> straight forward install.. up and running in no time -> fault tolerance -> easier to scale with a dreamworld of hash-rings. -> indexes -> Geo-spatial indexes -> Affordable hosted services at with more than one provider. -> full text searching for documents -> handle original documents without conversions -> can choose between conflicting writes Oh well maybe someday :)
  - nirvana 15y ago
    Thank you very much for your answer, especially since you compared the two. That helps me understand even better. Just wanted to let you know Basho is addressing some of your wishes. Riak 1.0, which is coming out at the end of this month, has integrated riak search (so it is no longer a separate install) and also has integrated secondary indexes (on numerical values, so not full text search but integrated nicely.) I believe, it may be possible, to do geo-spatial searches using the new index system, but I've only thought about it, haven't tried it yet. (It's not built in, but I think its something one could build, and I'd like to build myself eventually.) They now have binary builds for installing on Mac OS X (IIRC) and I've been able to install via homebrew and source lately, so they might have fixed that. They've also got a new thing called riak_pipe which is really useful for certain classes of problems (its new so not well documented yet.) Anyway, thanks again for your answer, and just wanted to let you know Basho seems to be addressing the issues you ran into.
- bricestacey 15y ago
  I chose Mongo because I wanted to use mapreduce and I had never heard of any alternatives. I'm not particularly proud of that reasoning but it has worked out well for me (log analysis: I'm uploading files to GridFS, processing them into line documents, and mapreducing them). I am willing to bet the majority of user fall in the same boat.
- malbs 15y ago
  We are currently building some core infrastructure with MongoDB. I looked at Riak, but it was capped collections and ad-hoc querying that really nailed it for us. Riak is a great product, I loved it's replication mechanism where any node was writable, but we didn't require that, so we went with mongo. We had a 3 node system across a wan, where local clients would read from a local node, and if they needed to write, would write to the master across the wan. The issue we had was there was a significant amount of data being written to the master that one or two of the nodes weren't interested in 100% of the time, but it was still being replicated across the wan (and at cost) so I investigated how the replication mechanism worked - to see if I could gain greater control over what data was replicated. As it turns out, there isn't, but you can emulate the replication yourself if you're interested. Well this is how we did it: - master node has a capped collection (we call db.messages) - slave nodes have a bit of mongo console javascript that execute tailed cursor querying for messages being inserted - when a message that matches the query inputs is inserted into the messages collection, it gets inserted into a local db.files collection, which clients then read from The added bonus is that occasionally we do need to replication additional data to particular nodes, so we just craft up a tailed cursor query that finds any messages we can, and pulls them across the wire we make a fair bit of use of the adhoc querying in mongodb, so that was a massive selling point for us speed was also a major issue - we have a average write/very high read requirement, and it's really really fast. finally the platform was a consideration. We're mostly a windows shop, but we'll use linux where needed, and we were prepared to have riak running on linux if thats what we thought was bets, but it just didn't really fit for us. the only downside was we use Delphi, and the existing Delphi drivers were.. not good, so we wrote our own, which I'm trying to negotiate with my boss so we can push onto github. good luck!
  - rbranson 15y ago
    "speed was also a major issue - we have a average write/very high read requirement, and it's really really fast." "We're mostly a windows shop" "we use Delphi"
    - benblack 15y ago
      Well said, sir.
- aashay 15y ago
  One of the draws to Mongo for me is that there are already existing cloud-managed service providers (MongoLab, MongoHQ) that hook in to Heroku, which is my choice for deployment. I haven't found any real cloud-managed services for Riak except Joyent's smart machines (which are expensive for my small project budget). The other reason was Mongoose, a great ODM for Node.JS that makes my life a lot easier. Of course if anyone has managed to hook into a Riak provider on Heroku I'd love to be proved wrong. And yes, I could always spin up an EC2 instance and manage a Riak cluster myself, but my time is constrained and I'd rather focus on getting my app out the door than sysadmin tasks.
- al_james 15y ago
  Quite simply: MongoDB is the most SQL-like of all the no-SQL databases out there. E.g. the shortest transition for developers used to using SQL databases (Mysql in particular) who need a bit more flexibility.
kennu 15y ago
I think I speak for everybody here when I say that 1.8 + 0.2 = 1.10.
- cheald 15y ago
  Yes indeedy. The "2.0" versioning is seriously annoying me.
- benburton 15y ago
  I'm very confused about the math you did there.
  - milestinsley 15y ago
    The 0.2 implies two "point releases". Traditionally these increment the value after the decimal point in a version number. so: 8 + 2 = 10, therefore 1.10. It's best to view the version number as a string rather than a decimal number. This is a somewhat old-school way of versioning and common in open source software. Personally, I prefer something more intuitive and don't see anything wrong with MongoDB being at version 2.0!
    - TylerE 15y ago
      The point of a major bump is to say to the ops team/sysadmin "HEY! We actually changed some stuff. You probably want to check with your programmers to see if any of these changes will effect our client code".
    - icebraining 15y ago
      I think if they want to keep it purely arithmetic they should drop the period. It's MongoDB 20.
    - icebraining 15y ago
      I think if they want to keep it purely arithmetic they should drop the period and just use integers.
- TylerE 15y ago
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.
deleo 15y ago
A bump like that should be for backward incompatible changes but it actually looks like a makeover to appeal more to serious biz customers that would have trouble getting on to a 1.0 technology.
Deutscher 15y ago
A few months ago, I saw an online interactive 'trainer' of sorts for MongoDB, much like Codecademy's JS tutorials. Does anyone know what I'm talking about? EDIT: Damn Google, you good: http://www.mongly.com/ http://www.mongly.com/
- mathias_10gen 15y ago
  It was probably either http://try.mongodb.org http://try.mongodb.org or http://mongly.com/ http://mongly.com/
foobarbazetc 15y ago
I have no idea how anyone who's ever read the mongodb source code can entrust it with their data.
- eloop 15y ago
  Examples?

215 points by meghan 15y ago

I'm curious as to why MongoDB is so popular. I chose Riak, and my purpose here isn't to bash Mongo, but to understand what was the key feature that made you choose it? Is it pure speed on a single machine? Is it the query interface? Something else? Datacenter awareness? Geographic support? The key features that made me choose riak: - built in distribution/clustering with homogenous nodes - bitcask had the level of reliability/design that I was looking for. - better impedance match for what I was doing than CouchDB (which was what I looked at before choosing riak, but couch does view generation when data is added and I need to be able to do it more dynamically.) What sold you on Mongo? What would you most like to improve? (Please don't let this be a debate, I'm more interested in understanding the NoSQL market, what other developers priorities are, etc.)

va_coder 15y ago
I was up and running with MongoDB in minutes. I tried Riak a while ago and the "getting started" experience was very poor IMO. Also, I really like the MongoDB docs. Can you point me to a great getting started page for Riak (setting it up, loading in data, doing advanced queries, Python/Ruby libraries etc)?
- nosequel 15y ago
  http://wiki.basho.com/The-Riak-Fast-Track.html http://wiki.basho.com/The-Riak-Fast-Track.html It is being updated now for Riak 1.0.
- arctangent 15y ago
  I haven't tried Riak but I will confirm that MongoDB was really easy to get started with. It's performant enough that I don't really need to look at anything else right now.
enjo 15y ago
For me: - Well supported and very active community. It's a project that is clearly going to be moving forward for a long time. - For my needs (structured data) it's super fast. - The auto-sharding support is nifty. - Geo-spatial queries out of the box
old-gregg 15y ago
Things we're using it for here at http://mailgun.net http://mailgun.net : * Fast asynchronous writes for non-critical data (logs). * Replica sets allow for zero-downtime hot failover to a backup server when the primary is taken down or dies. * Simple queries are crazy fast, assuming your index fits in RAM. * find_and_modify() feature is awesome for some tasks. But we're supplementing Mongo with PostgreSQL because of the following Mongo weaknesses: * Concurrency is so-so: the entire database is locked during writes. * Weak aggregation capabilities. * Greatly reduced performance when the index doesn't fit in RAM. * Wasteful when it comes to allocating space (on disk and in RAM)
- philjackson 15y ago
  With one hand you giveth; "Fast asynchronous writes" and the other taketh away; "Concurrency is so-so: the entire database is locked during writes.".
  - rbranson 15y ago
    It's like unsuspecting developers are walking down Developer Lane and see a candy bar sitting there that says "FAST, ASYNCHRONOUS WRITES." So they pick it up, bite into it, and then the candy bar grows a giant mutant global lock head that eats their face.
  - old-gregg 15y ago
    Actually I don't believe the two are related. And they're working on the concurrency improvements all the time: https://jira.mongodb.org/browse/SERVER-1240 https://jira.mongodb.org/browse/SERVER-1240
    - philjackson 15y ago
      Can you explain how they're not related? I'm not poking you to start a fight, I'm genuinely curious.
      - samstokes 15y ago
angelbob 15y ago
MongoDB is a surprisingly short hop from SQL databases in a lot of ways. It makes retraining your already-SQL-competent developers much easier than with many other datastores.
- larrywright 15y ago
  This is my main reason for using it as well. For me, MongoDB is less about any of the NoSQL features, but more about the fact that I can be more productive with it. Pair it with a good library like MongoMapper, and persisting your data is trivial.
cheald 15y ago
I actually started in Riak before Mongo, and what made the decision for me was...not having to install Erlang. I realize that's not really a compelling argument, but when I was evaluating alternate DBs, the one that gets up and running the fastest is likely to get a little more attention from me. Once I got spun up on Mongo, I didn't find a compelling reason to switch away from it. "Download and unpack the package, run the binary, and you can instantly start playing with the examples from the console" is a hell of a good way to get people interested in your software.
- aphyr 15y ago
  wget http://downloads.basho.com/riak/riak-0.14/riak_0.14.2-1_amd64.deb dpkg -i riak_0.14.2-1_amd64.deb Our production configuration and setup/deploy recipes for riak are 241 lines in total, ~150 of which are the stock config files.
  - cheald 15y ago
    This would have been something like 18 months ago, and was on an older Fedora box. It wasn't quite so trivial as that two-liner.
- rbranson 15y ago
  Ease of first time developer installation should never be the deciding factor in these decisions. I realize it is pretty rampant, but it's not something we should be proud of.
  - SystemOut 15y ago
    Yeah but how long should I spend on software that I know nothing about the quality of if it's not easy to get up and running? Do you spend a day? two days? While it's mostly just from experience I find that virtually no one makes a decision based on how easy it is to get up and running with a piece of software but it is an impression that stick's in people's minds and gets repeated when they talk about it later.
  - cheald 15y ago
whyme 15y ago
I struggle choosing. I started both at the same time and keep going back and forth. Riak -> I love the fault tolerance -> easier to scale with a dreamworld of hash-rings I wish I could have. -> no indexes -> no Geo-spatial indexes -> I don't like link walking... it's not intuitive. -> I want to use Riak (Lucerne/Solr like) full text search, but the docs are poor and have to read dozens of useless documents to get nowhere very quickly. It's a separate install that requires pre-commits?(which are never explained well enough to start using it). -> installing on Mac OSX is painful (homebrew works/doesn't work depending on version, 32 bit or 64? how come I don't have include 32bit flags with older repo's, yet newer ones are only 64bit yet don't compile.... errors errors errors...ERLANG which? such a pain in the ass installing Riak unless you do it using specific build tools. -> Only Joyent provides a hosted solution which is too expensive relative to its offering. -> accepts any docs just set the content type.. handles original documents without conversions -> easy to load balance behind NGINX -> can choose between conflicting writes MongoDB -> straight forward install.. up and running in no time -> SQL like queries -> intuitive indexes -> Geo-spatial indexes -> Affordable hosted services with more than one provider. -> no full text searching over documents -> have to fiddle with doc handling GRIDFS etc.. -> can't choose between conflicting writes (last one wins) I wish I could have "RiaMong" -> straight forward install.. up and running in no time -> fault tolerance -> easier to scale with a dreamworld of hash-rings. -> indexes -> Geo-spatial indexes -> Affordable hosted services at with more than one provider. -> full text searching for documents -> handle original documents without conversions -> can choose between conflicting writes Oh well maybe someday :)
- nirvana 15y ago
  Thank you very much for your answer, especially since you compared the two. That helps me understand even better. Just wanted to let you know Basho is addressing some of your wishes. Riak 1.0, which is coming out at the end of this month, has integrated riak search (so it is no longer a separate install) and also has integrated secondary indexes (on numerical values, so not full text search but integrated nicely.) I believe, it may be possible, to do geo-spatial searches using the new index system, but I've only thought about it, haven't tried it yet. (It's not built in, but I think its something one could build, and I'd like to build myself eventually.) They now have binary builds for installing on Mac OS X (IIRC) and I've been able to install via homebrew and source lately, so they might have fixed that. They've also got a new thing called riak_pipe which is really useful for certain classes of problems (its new so not well documented yet.) Anyway, thanks again for your answer, and just wanted to let you know Basho seems to be addressing the issues you ran into.
bricestacey 15y ago
I chose Mongo because I wanted to use mapreduce and I had never heard of any alternatives. I'm not particularly proud of that reasoning but it has worked out well for me (log analysis: I'm uploading files to GridFS, processing them into line documents, and mapreducing them). I am willing to bet the majority of user fall in the same boat.
malbs 15y ago
We are currently building some core infrastructure with MongoDB. I looked at Riak, but it was capped collections and ad-hoc querying that really nailed it for us. Riak is a great product, I loved it's replication mechanism where any node was writable, but we didn't require that, so we went with mongo. We had a 3 node system across a wan, where local clients would read from a local node, and if they needed to write, would write to the master across the wan. The issue we had was there was a significant amount of data being written to the master that one or two of the nodes weren't interested in 100% of the time, but it was still being replicated across the wan (and at cost) so I investigated how the replication mechanism worked - to see if I could gain greater control over what data was replicated. As it turns out, there isn't, but you can emulate the replication yourself if you're interested. Well this is how we did it: - master node has a capped collection (we call db.messages) - slave nodes have a bit of mongo console javascript that execute tailed cursor querying for messages being inserted - when a message that matches the query inputs is inserted into the messages collection, it gets inserted into a local db.files collection, which clients then read from The added bonus is that occasionally we do need to replication additional data to particular nodes, so we just craft up a tailed cursor query that finds any messages we can, and pulls them across the wire we make a fair bit of use of the adhoc querying in mongodb, so that was a massive selling point for us speed was also a major issue - we have a average write/very high read requirement, and it's really really fast. finally the platform was a consideration. We're mostly a windows shop, but we'll use linux where needed, and we were prepared to have riak running on linux if thats what we thought was bets, but it just didn't really fit for us. the only downside was we use Delphi, and the existing Delphi drivers were.. not good, so we wrote our own, which I'm trying to negotiate with my boss so we can push onto github. good luck!
- rbranson 15y ago
  "speed was also a major issue - we have a average write/very high read requirement, and it's really really fast." "We're mostly a windows shop" "we use Delphi"
  - benblack 15y ago
    Well said, sir.
aashay 15y ago
One of the draws to Mongo for me is that there are already existing cloud-managed service providers (MongoLab, MongoHQ) that hook in to Heroku, which is my choice for deployment. I haven't found any real cloud-managed services for Riak except Joyent's smart machines (which are expensive for my small project budget). The other reason was Mongoose, a great ODM for Node.JS that makes my life a lot easier. Of course if anyone has managed to hook into a Riak provider on Heroku I'd love to be proved wrong. And yes, I could always spin up an EC2 instance and manage a Riak cluster myself, but my time is constrained and I'd rather focus on getting my app out the door than sysadmin tasks.
al_james 15y ago
Quite simply: MongoDB is the most SQL-like of all the no-SQL databases out there. E.g. the shortest transition for developers used to using SQL databases (Mysql in particular) who need a bit more flexibility.

kennu 15y ago

I think I speak for everybody here when I say that 1.8 + 0.2 = 1.10.

cheald 15y ago
Yes indeedy. The "2.0" versioning is seriously annoying me.
benburton 15y ago
I'm very confused about the math you did there.
- milestinsley 15y ago
  The 0.2 implies two "point releases". Traditionally these increment the value after the decimal point in a version number. so: 8 + 2 = 10, therefore 1.10. It's best to view the version number as a string rather than a decimal number. This is a somewhat old-school way of versioning and common in open source software. Personally, I prefer something more intuitive and don't see anything wrong with MongoDB being at version 2.0!
  - TylerE 15y ago
    The point of a major bump is to say to the ops team/sysadmin "HEY! We actually changed some stuff. You probably want to check with your programmers to see if any of these changes will effect our client code".
  - icebraining 15y ago
    I think if they want to keep it purely arithmetic they should drop the period. It's MongoDB 20.
  - icebraining 15y ago
    I think if they want to keep it purely arithmetic they should drop the period and just use integers.
TylerE 15y ago

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.

deleo 15y ago

A bump like that should be for backward incompatible changes but it actually looks like a makeover to appeal more to serious biz customers that would have trouble getting on to a 1.0 technology.

Deutscher 15y ago

A few months ago, I saw an online interactive 'trainer' of sorts for MongoDB, much like Codecademy's JS tutorials. Does anyone know what I'm talking about? EDIT: Damn Google, you good: http://www.mongly.com/ http://www.mongly.com/

mathias_10gen 15y ago
It was probably either http://try.mongodb.org http://try.mongodb.org or http://mongly.com/ http://mongly.com/

foobarbazetc 15y ago

I have no idea how anyone who's ever read the mongodb source code can entrust it with their data.

eloop 15y ago
Examples?