3 ms·

so what is the right application for mongodb? only when you don't need ACID? Can you give some example? Genuinely curious

mandevil 9y ago
We used Couchbase (a NoSQL like MongoDB) for email batch sending (think invitations to a party) and it worked very well. We could store each email sent as a separate, denormalized document so the sender could see EXACTLY how their contact data was replaced in each individual instance, the "View as a Web Page" functionality was trivial (instead of recalculating everything from the normalized forms- which can be blown up by contact data changes, just load the document that you sent out), and it's lovely TTL feature meant we could handle the configurable retention policies trivially as well. It wasn't so good at doing reports (how many customers viewed the email yet, responded, etc.). One thing we talked about doing was just storing a sqlite or h2 database as a document for reporting purposes (if we had been more single threaded that could have worked nicely). We ended up using a separate Sql DB for that. There are cases where denormalized data is the "right" way to view stuff, and cases where the data really is easier if its normalized, and that is a good reason to push your DB selection one way or another.
- lilbobbytables 9y ago
  Interesting. Seems like that would just be one part of a larger application, though. And for that, my mind just jumps to something like Postgres with `jsonb` fields to store it all denormalized, then using columns to store relations, like the contact it was sent to. Along with other tables for other parts of the application, of course. This way your aren't complicating your stack by adding more services sooner.
  - mandevil 9y ago
    We were replacing a fully SQL email engine (that was starting to fall over due to load) with this more hybrid approach; we had customers, we knew that the business case closed, but the load was starting to overpower the main database, so we spun off separate databases, and bought ourselves a little more overhead by splitting out the normalized and denormalized data. Could well have been a mistake, but we weren't thrilled with postgres ability to scale horizontally, so went to CB so we could scale a bit more. (As I recall, we were doing 7m emails a day, our goal was to support up to 70m with that structure.)

mandevil 9y ago

We used Couchbase (a NoSQL like MongoDB) for email batch sending (think invitations to a party) and it worked very well. We could store each email sent as a separate, denormalized document so the sender could see EXACTLY how their contact data was replaced in each individual instance, the "View as a Web Page" functionality was trivial (instead of recalculating everything from the normalized forms- which can be blown up by contact data changes, just load the document that you sent out), and it's lovely TTL feature meant we could handle the configurable retention policies trivially as well. It wasn't so good at doing reports (how many customers viewed the email yet, responded, etc.). One thing we talked about doing was just storing a sqlite or h2 database as a document for reporting purposes (if we had been more single threaded that could have worked nicely). We ended up using a separate Sql DB for that. There are cases where denormalized data is the "right" way to view stuff, and cases where the data really is easier if its normalized, and that is a good reason to push your DB selection one way or another.

lilbobbytables 9y ago
Interesting. Seems like that would just be one part of a larger application, though. And for that, my mind just jumps to something like Postgres with `jsonb` fields to store it all denormalized, then using columns to store relations, like the contact it was sent to. Along with other tables for other parts of the application, of course. This way your aren't complicating your stack by adding more services sooner.
- mandevil 9y ago
  We were replacing a fully SQL email engine (that was starting to fall over due to load) with this more hybrid approach; we had customers, we knew that the business case closed, but the load was starting to overpower the main database, so we spun off separate databases, and bought ourselves a little more overhead by splitting out the normalized and denormalized data. Could well have been a mistake, but we weren't thrilled with postgres ability to scale horizontally, so went to CB so we could scale a bit more. (As I recall, we were doing 7m emails a day, our goal was to support up to 70m with that structure.)