4 ms·
I'd definitely look at Mongo first. Couch is ridiculously simple, too much so. It doesn't do locking because it versions every single record, so if you do upd
by nicpottier 17y ago
I'd definitely look at Mongo first. Couch is ridiculously simple, too much so. It doesn't do locking because it versions every single record, so if you do updates very frequently you are going to have to clean your DB really often. Their queries are less flexible than Mongo's as well.
Couch is interesting in a way, but I feel like the set of problems that fit it well is far smaller than Mongo's. (and that that set is far smaller than SQL still, but that's another matter)
Mongo is also way way faster, though the API isn't as 'cute' by far. I feel like the great web UI for couch, along with their heavy javascript/json usage is the main reason it gets so much traction.
- andrewvc 17y agoThanks for the helpful info, I do still have one reservation about mongo however. There is one thing that couch does to better than mongo, and thats single server durability. You can pretty much kill -9 couch and it won't care (that's pretty much how it stops itself). Now, I understand mongodb's stance on why you should be running multiple servers for your high performance app, but for a lot of apps that don't need HA that's just overkill and a pain to configure (and extra $$$ for more hardware). In fact, I'd go so far as to say thats the case for most apps. If I recall they're working on it at the moment though.
- lurkerperpetual 17y agoThey have a syncdelay parameter which you can tweak to flush to disk as often as you want http://www.mongodb.org/display/DOCS/Durability+and+Repair http://www.mongodb.org/display/DOCS/Durability+and+Repair
- andrewvc 17y agothat's all I needed to hear, I'll likely go with mongodb for my next project now.