Terminology and Concepts
If you're not familiar with MongoDB, here's a quick translation cheat sheet to get you familiar with the terminology.
|Joining||Linking & Embedding|
|Partition||Sharding (Range Partition)|
Making the Choice
Of course, your choice of database is always a decision based on pros and cons.
- Document oriented
- High performance
- High availability — Replication
- High scalability – Sharding
- Dynamic — No rigid schema.
- Flexible – field addition/deletion have less or no impact on the application
- Heterogeneous Data
- No Joins
- Data Representation in JSON or BSON
- Geospatial support
- Easy Integration with BigData Hadoop
- Document-based query language that’s nearly as powerful as SQL
- Cloud distributions such as AWS, Microsoft, RedHat,dotCloud and SoftLayer etc:-. In fact, MongoDB is built for the cloud. Its native scale-out architecture, enabled by ‘sharding,’ aligns well with the horizontal scaling and agility afforded by cloud computing.
- A downside of NoSQL is that most solutions are not as strongly ACID-compliant (Atomic, Consistency, Isolation, Durability) as the more well-established RDBMS systems.
- Complex transaction
- No function or stored procedure exists where you can bind the logic
- E-commerce product catalog.
- Blogs and content management.
- Real-time analytics and high-speed logging, caching, and high scalability.
- Configuration management.
- Maintaining location-based data — Geospatial data.
- Mobile and social networking sites.
- Evolving data requirements.
- Loosely coupled objectives — the design may change by over time.
Not so Good For:
- Highly transactional systems or where the data model is designed up front.
- Tightly coupled systems
And there you have it! Now, you've got a quick and easy overview of how MongoDB works, some use cases where it can shine, and how it relates to SQL technology.