4 ms·
I will argue _against_ MongoDB all day, but there is most certainly a time and place for it. If you have a real firehose of data, don't care too much about the
by chucky_z 10y ago
I will argue _against_ MongoDB all day, but there is most certainly a time and place for it. If you have a real firehose of data, don't care too much about the accurateness, and really need good speed... MongoDB is not an awful choice.
- eyelidlessness 10y agoHow well does it stand up against other "NoSQL" solutions that compete in the same space? My impression has been that it tends compete poorly with a number of other solutions for data integrity, and my intuition is that its appeal is correlated to the proliferation of JavaScript and the convenience of interoperating with it.
- chucky_z 10y agoFrom my experience, the problem is not how does any NoSQL solution stand up vs. any other NoSQL solution. The question to ask is "What caveats affect me the least?" and then go with that NoSQL solution. In the case of MongoDB, the biggest issue (at least in the past) is that the caveats simply aren't known well, or at all! Compare this to something like Elasticsearch, which is well-known (and well-documented) to have data loss in certain situations.
- omginternets 10y ago>MongoDB is not an awful choice Frankly I think it's still an awful choice given it's broken replication model.
- bonesmoses 10y agoCould you explain a bit more about this? From what I can see, it's just journal consumption. That's basically how Postgres does it, too.
- omginternets 10y agoAphyr explains it better than I every could: https://aphyr.com/posts/284-jepsen-mongodb https://aphyr.com/posts/284-jepsen-mongodb :)
- bonesmoses 10y agoVery informative. Thanks!