3 ms·
Interesting. In my most recent projects, I've been using MongoDB together with Redis. MongoDB for long term data (like records and reports) and Redis for near-r
by delano 17y ago
Interesting. In my most recent projects, I've been using MongoDB together with Redis. MongoDB for long term data (like records and reports) and Redis for near-realtime stuff (queuing, request limiters, analytics, and the like). I haven't come across the need for atomic record modification but that isn't to say there aren't useful usecases. I need to think on it a bit more.
- dm_mongodb 17y agothis touches on some related aspects: http://blog.mongodb.org/post/307919034/partial-object-updates-will-be-an-important-nosql http://blog.mongodb.org/post/307919034/partial-object-update...
- old-gregg 17y agoIsn't that defeating the purpose of MondoDB? We're considering switching to it precisely because we're sick of two-tiered approach (MySQL+memcached) and MongoDB promises a built-in near-realtime caching. Why would I want to lose the power of SQL if I'm not getting anything in return? I thought that "built-in memcached" was what I'd be getting. No?
- cloudhead 17y agomongodb doesn't do concurrency very well -- at least not as good as Redis.
- old-gregg 17y agoI looked up your profile but didn't find any contact info. I am dying to know more about MongoDB limitations and this page isn't helping: http://www.mongodb.org/display/DOCS/Concurrency http://www.mongodb.org/display/DOCS/Concurrency
- dm_mongodb 17y agoconcurrency is much better in the newest versions
- delano 17y agoStorage and caching are two different problems so it's reasonable to assume two separate solutions. In this case, MongoDB is a leap ahead of MySQL; Redis is a leap ahead of Memcached. Both solve the core problems very well and include additional freebies (MongoDB's high-performance aggregate functions and Redis' atomic increments and set and list functions).