I'm starting to form this idea of what constitutes an ideal use case for mongo in my head, and i'm trying to prove the model.
If I were to imagine some kind of "realtime" multiplayer game, like quake or something.
1. You have to have the state be shared between all the parties in a reasonable time.
2. The clients only need the data that is directly relating to the round they are in, so you have the concept of cold and hot data.
3. The data is all kind of ephemeral too, so that you don't specifically care about who was on what bouncy pad when, but you do want to know what the kill score/ratio is afterwards.
4. You have a couple of entities that have some kind of lightweight relationship to each other, which makes it just more complex than a key-value store like redis is really suitable for.
5. These entities are sort of a shared state, and thus get updated more often than new unrelated documents get added, and couchdb's ref-counting and append-only nature makes it really unsuited for constant updates of an existing record.
This seems totally reasonable to me. I was playing around with using Firebase (https://www.firebase.com/) as the datastore for a turn-based multiplayer game on the web and its data policies seemed very well suited.
Essentially, each game was its own document and relevant stats were updated/duplicated on the player documents as well.
There don't seem to be useful relationships here that I'd want to query. Maybe successive game states? But not across different games, right?
Well, I was imagining a situation where you had multiple different pieces in a game, relating to each player and distinct to that game. Maybe like an RTS game or something?
So you might want to query how many pieces a certain player has available, or do a check on who this piece belongs to.
Keep in mind I'm still not saying an actual game, but any problem that had similar data storage and access patterns as a game along these lines would have.
I don't know enough about firebase to confirm whether it is suited to this, but if I had any kind of backend at all, and I had requirements for really quick reponses, i wouldn't be comfortable adding the extra hop to a hosted service onto each call.
http://daemon.co.za/2014/04/when-is-mongodb-the-right-tool
I'm starting to form this idea of what constitutes an ideal use case for mongo in my head, and i'm trying to prove the model.
If I were to imagine some kind of "realtime" multiplayer game, like quake or something.
1. You have to have the state be shared between all the parties in a reasonable time.
2. The clients only need the data that is directly relating to the round they are in, so you have the concept of cold and hot data.
3. The data is all kind of ephemeral too, so that you don't specifically care about who was on what bouncy pad when, but you do want to know what the kill score/ratio is afterwards.
4. You have a couple of entities that have some kind of lightweight relationship to each other, which makes it just more complex than a key-value store like redis is really suitable for.
5. These entities are sort of a shared state, and thus get updated more often than new unrelated documents get added, and couchdb's ref-counting and append-only nature makes it really unsuited for constant updates of an existing record.
any feedback would be appreciated.