MongoDB schema design for player stats based on game server's log events?

We have several game servers that produces events based on player actions. We want to save some of these events to build stats; both for the player's enjoyment but also to analyze behaviour.

We have decided on MongoDB for a number of reasons, mainly performance. However, we are struggeling a bit with the schema design. Too many years with RDBMS databases has its tolls.

Anyways, the events that get generated looks something like this: player1 killed player2 with weapon1. While catching these events I am also aware of the server-id, what map is run开发者_开发百科ning etc. I obviously know what time it is and I can model player relationships to produce groups/teams.

But, how would this look in a document model?

Do I just put all the events in a collection and then add the properties I want to use in our searches as fields? Or do a create a hierarchy with documents to gain performance benefits (?). Putting it all in a "row" I guess will make it easy to query but doesn't really feel all that optimized. There will be TONS of rows and even if MongoDB is fast I am not convinced it will handle the load. Also, the performance in a RDBMS database should be pretty equal if I just flatten the structure and put everything searchable in a row. Plus the size overhead of storing same data over and over again (users i.e.).

I'd say it depends on how you want to use the data you collect. Is it a requirement that your stats are (almost) real time? or is some delay for processing acceptable?

I guess you'll want to pull out stats like "how many kills happend on map x with weapon y?" and lot's of other combinations.

If you need that (almost) realtime, I'd suggest tailored documents in a dedicated collection for each statistic requirement. So for the above example you could have a "maps" collection with map documents where each map has a counter for each weapon or something like that. This should give pretty fast and "realtime" reads. The downside here is that your write performance may suffer a bit, because you'd have to update multiple collections for each event.

If you can live with som delay for processing, The your thought of putting all events into one big flat collection is not that bad. Write performance would be really good. But you'd have to periodically run som map/reduce jobs (which will be very slow) and process your events and leave the stats in result collections.