Using MySQL and Mongodb together

Question

I have worked with MySQL more than MongoDB, but from what I've learned from MongoDB it's just what I needed, but it also has it's limitations that MySQL can do (for instance auto increment)

Would it be smart to use MongoDB for everything, and use MySQL for only certain things?

For instance use MongoDB to store users and everything else, but use MySQL to make for example a ticket system.

Answer 1

It sounds perfectly reasonable to use two database technologies in one project. Just make sure you use the right tool for the job.

It's common to use MySQL as the primary storage and MongoDB as caching/intermediate storage for speed.

You can for example have read-intensive data in MongoDB. The data for generating reports is perfect for a relational system like MySQL.

Answer 2

Here is a well-typed discussion of mongodb usage, by someone who took mongoDb courses

Considerations for choosing or not choosing MongoDB

The blogger mainly says that using mongodb with other DB systems is perfectly fine , yet using it system wide , can be most challenging and almost impossible at some certain scenarios.

Here are some subtitles :

Reasons to choose Mongo

• Document oriented and schemaless
• Horizontal Scalability and High Availability
• Fast writes in the fire-and-forget mode
• Comprehensive Querying and Aggregation Framework
• Comparatively intuitive architecture

Reasons not to choose Mongo

• No SQL = No Joins
• No ACID transactions
• Your indexes would not fit into memory

Answer 3

There is a pretty good discussion of Use Cases for MongoDB on the main MongoDB site. In general, if your business case includes the need for transactions and heavy T-SQL functionality, then you'd be better served by using a RDBMS such as MySQL.

Good Use Cases for MongoDB are as follows:

1. Your data is in a document format, i.e. irregular structure in single documents (that is data doesn't need to be joined)
2. You are considering using a flat file system (again due to the structure of your data), but you would like 'more' in terms of ability to index/query that data.
3. Your project is in a state where you genuinely don't know what the schema or structure of your data will ultimately be.
4. You have specialized data types, such as geo-spatial data, and you want to be able to query against it.
5. You may have a need to quickly and cheaply scale your data storage location.