Using both Mongodb and Mysql in one project

I have been working to learn Mongodb effectively for one week in order to use for my project. In my project, I will store a huge geolocation data and I think Mongodb is the most appropriate to store this information. In addition, speed very important for me and Mongodb responds faster than Mysql.

However, I will use some joins for some parts of the project, and I'm not sure whether I store user's information in Mongodb or not. I heard some issues can occur in mongodb during writing process. should I use only mongodb with collections 开发者_如何学JAVA(instead of join) or both of them?

In most situations I would recommend choosing one db for a project, if the project is not huge. On really big projects (or enterprises in general), I think long term organizations will use a combination of

• RDBMS for highly transactional OLTP
• NoSQL
• a datawarehousing/BI project

But for things of more reasonable scope, just pick the one that does the core of the use case, and use it for everything.

IMO storing user data in mongodb is fine -- you can do atomic operations on single BSON documents so operations like "allocate me this username atomically" are doable. With redo logs (--journal) (v1.8+), replication, slavedelayed replication, it is possible to have a pretty high degree of data safety -- as high as other db products on paper. The main argument against safety would be the product is new and old software is always safer.

If you need to do very complex ACID transactions -- such as accounting -- use an RDBMS.

Also if you need to do a lot of reporting, mysql may be better at the moment, especially if the data set fits on one server. The SQL GROUP BY statement is quite powerful.

You won't be JOINing between MongoDB and MySQL.

I'm not sure I agree with all of your statements. Relative speed is something that's best benchmarked with your use case.

What you really need to understand is what the relative strengths and weaknesses of the two databases are:

• MySQL supports the relational model, sets, and ACID; MongoDB does not.
• MongoDB is better suited for document-based problems that can afford to forego ACID and transactions.

Those should be the basis for your choice.

MongoDB has some nice features in to support geo-location work. It is not however necessarily faster out of the box than MySQL. There have been numerous benchmarks run that indicate that MySQL in many instances outperforms MongoDB (e.g. http://mysqlha.blogspot.com/2010/09/mysql-versus-mongodb-yet-another-silly.html).

Having said that, I've yet to have a problem with MongoDB losing information during writing. I would suggest that if you want to use MongoDB, you use if for the users as well, which will avoid having to do cross database 'associations', and then only migrate the users to MySQL away if it becomes necessary.