Is caching as important with MongoDB as with MySQL?

I am writing a C# HTTP request server for my web game and I am using MongoDB for the database. Is it m开发者_C百科ore efficient to still cache whatever I can in the C# application? Or is it faster to just do a request to MongoDB for every thing. I am expecting around a dozen selection queries per minute for each active player, and maybe one or two save/update queries per minute.

"dozen selection queries per minute for each active player" doesn't tell us anything. For that to have any bearing we'd need to know the number of active players, the amount of time each query is taking, the table structure, queries in use (including amount of data returned), statistics on server load, and others such as whether you are using Mongo's ability to shard the database, etc.

Regardless, before setting up any type of caching I'd highly suggest you start with profiling the system. You need to know where your bottlenecks are, if any even exist. This isn't something you just guess at, you need hard and real statistics.

With that information in hand you can make a determination as to whether you need

• to make minor fixes to your code
• implement some type of caching strategy
• shard the database server across multiple servers
• rearchitect large swathes of code
• scale up (buy bigger servers)
• or even fix internal network issues.

Point is, don't start caching stuff in the hopes of getting a performance increase later. Caching is just as likely to increase performance as it is to kill it depending on a huge number of factors.

One other thing to add here. If you are using a web farm to host your request server then the complexity and hardware costs involved in caching data locally to each independent web server grows drastically.

Hardware costs go up due to increased memory requirements on your web server(s) when trying to keep the data cached in memory on those machines.

Complexity increases when trying to keep the cached copies in sync so that they don't become stale. I would imagine that a game would require information that 100% current. Sites like facebook and others can afford to be a little out of sync. When a game server goes out of sync it could have negative impacts on player usability.

Assuming you are currently deploying only to a single web server and a single DB server, adding caching capabilities now might cause a huge amount of pain for you in the event you move to multiple web servers and/or multiple db servers.

Finally, if for some reason you are deploying only to a single machine that hosts both the database and web server then caching is completely ludicrous.

I would say irrespective of the database, caching seldom changing data on the server is better than making a bunch of database calls. Anything that can come from the web server directly across the wire vs making a database call and then sending across the wire is a good thing. If these dozen selection queries you're making return the same data, it's better to cache it.

Here's something to consider: When your game is small your database will probably be on the same machine, and the database itself will do its own caching. Later on if your game is popular you will end up with multiple web servers, and it would be better to use distributed caching like memcached if you're going for overall memory efficiency.