Hi, I am fresh to database design, recently trying building my mobile multiplayer game, it will be something like pokemonGo.

I have experience on MySQL, and I know some NoSQL engines like redis.
I saw some existing game projects which store their data on both SQL database and noSQL database.

Could anyone give some advice that what kind of data should store in SQL and what kind of data is better to be in noSQL.
It would be nice if giving some real scenario examples.

My understanding is data like user profile, purchase transactions should be in SQL.
Field map information, enemy status can be NoSQL.  

The main problem with NoSQL overall, is that it requires you to know all your access patterns ahead of time. And because secondary indices are usually cumbersome or expensive, if you have more than the plain "given a key, find me a bag of data" then NoSQL starts showing its weakness.

Another thing that NoSQL got first, but SQL is now getting too, is in-RAM databases. Depending on performance needs and cost / operations specifics, you may want to look at databases specific for RAM. On the other hand, if you have data with a "long tail" (old data that's seldom accessed,) then all-RAM is almost certainly the wrong choice. Also: Putting more RAM into a SQL database host, to make it cache better, often reduces the cost difference between in-RAM and on-disk.

If you're familiar with MySQL, there's nothing wrong in just using that. It works great, and can scale far.

If you need specific features of Redis (atomic push/pop, sets, pub/sub) then you might want to include that, too, with the caveat that you have to put a time-to-live on all data, because when Redis runs out of RAM, that's it -- no more data!

Another interesting option is FoundationDB, which recently went open source when the company was bought by Apple. It's a key/value store that supports federation/distribution -- you can add nodes to get more capacity, without changing the semantics of the database. Redis, and most other NoSQL databases, by contrast, don't allow transactional work across multiple hosts.

Thank you for sharing the tips.
Now I learned redis can do push/pop,pub/sub other than key-value search; and MySQL also has in-RAM features.

For scaling capacity, probably I'm going to use some cloud DB like aws RDS or dynamoDB. not sure how expensive it can go

I would recommend against dynamoDB, as it has less guarantees than SQL but doesn't actually scale much better.

Amazon RDS is alright; it can use the MySQL or Postgres API, so if you're used to MySQL, you can even use MySQL for development, and then use RDS when deploying.