Different NoSQL solutions solve different problems for different purposes - so first the best thing to do is look at your problem and break it.
- You write a lot for storage, so writing speed is important to you.
- You want to perform aggregation operations on this data and get the results of this easily requested
- Reading speed is not so important because of the sound of things, at least not in the sense that "the web application must really respond to millions of people."
- I don't know if you need dynamic queries or not.
Look at Couch, Mongo, and Raven at a very high level, a generic way
Raven
- Quick record
- Quick queries (ultimately, consistent, pre-computed, map aggregation / reduction)
- Dynamic queries are possible, but not suitable for your use case, as you are likely to request a date, etc.
Mongo
- Dazzlingly fast recording (In my opinion, it’s dangerous, because turning off the power means data loss ;-))
- Slow reading (relatively), aggregation via map / contraction, not preliminary calculation
- Dynamic queries are just_you_do, but you probably have to define indexes in your columns if you want some kind of performance for this data type.
Couch
- Quick record
- Fast-ish reads (pre-computed but updated only when read (IIRC)
- Dynamic queries are not possible, all are predefined using map or map / reduce functions
So, basically - do you need dynamic queries on this data? Is reading speed incredibly important to you? If you need dynamic queries, you will need Raven or Mongo (for this kind of thing, Couch is probably not what you are looking for).
FWIW, Mongo use only the case, in my opinion, IS for logging, so you may have anwer.
Rob ashton
source share