This document discusses using MongoDB for reporting requirements that could not be met by traditional SQL databases due to constraints around cost and developer skills. Some key points made: - MongoDB was chosen because it is document-oriented, does not require transactions, and does not need dedicated DBAs, which the organization could not afford. - Reporting requirements evolved daily, so reporting had to keep up quickly without relying on expensive reporting specialists. Developers handled reporting by using MongoDB's map-reduce functionality, though it was painful. - Real-time reporting was implemented by creating specific documents to track data and updating them in the background using an existing queue routing framework. This allowed reporting to no longer be disjoint from the application.

2. @akhilkodali

3. dev @ Lexity Labs
Advertising made simple

4. Sharing practical experiences on reporting

5. Balanced View

6. Why MongoDB
Agile friendly
Document oriented
Transactions not needed
No specialist DBAs(couldn't afford one)
Devs not very good with traditional sql anyway

7. What do I think about MongoDB
Mysql beats MongoDB hands down in terms of
features
Its the best NoSql out there in terms of
usability + features
Its essentially a key value store with features
in drivers instead of the DB itself
This allows for easy app scaling

8. Strength of MongoDB is the mapper
Sadly RoR(ActiveRecord) guys seem to a well
about it

9. Constraints?
OpenSource available but not robust enough
Couldn't rely(afford) on reporting specialists
Devs had to handle the reporting

10. Couldn't rely(afford) reporting
specialists
The requirements evolved every day
Reporting had to keep up with it

11. Devs had to handle reporting
Map Reduce...painful...I have it...love the sql
Like the comfort of application layer
Mongo – Key, Value store
Driver did the rest at app layer
RealTime reporting
Reporting no longer a disjoint

12. RealTime Reporting
Map Reduce is not an option

13. RealTime reporting
Specific Documents for tracking
Update the documents in background
Already had queue routing and processing
framework

14. User Session
SessionId
Start Time
End Time

15. User Aggregate
Per Day
UserId
Date
Total Session Duration
Average Session
Total Session
Per Week...
Per Month...

16. How
Data Updates are atomic
One query (schema less)
REST based reporting
Jquery plugins / HTML5 for display
Reports felt more responsive and lighter
Smaller front end code base allowed for faster
iterations

17. Scenario
1000s of writes per minute
Lasts for a few hours a day
RealTime monitoring of the processing

18. Questions?