Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the main sticking point for serious mongodb infrastructure is the global lock -- yes, write operations cause the entire mongodb instance (every database, every read operation) to block. This is clearly one of the main issues surrounding high-concurrent mongodb development.

Thankfully with mongodb-2.2 there is now instead a database lock which mitigates the issue.

Personally I feel redis more closely resembles language primitives with simple key-value pairs, hashes, lists (ordered, repeating values allowed), sets (un-ordered, no repeating values), and sorted sets (more interesting).



Redis has no clustering (yet) so is best used when your data is transient and you are able to repopulate.


I have no experience with Redis or MongoDB, but your statement is only true if the storage layer is transient. Some of us use servers that don't go away upon shutdown, backed by a SAN.


Have you tested how long it would take your redis instance to be usable again after it finishes replaying the commitlog (AOF)?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: