Architectural suggestion

[nils@hasenbanck.de 0]

First of all: This is a very technical post, there is not gameplay element I talk about.

Second: This shouldn't read as flame war against a specific project or technology. This is just a suggestion by someone, who works with big databases everyday and who is curious about the resent development.

Dear developers,

You might have a problem (As far as I can see from the outside). It seems that you data backend is giving you much more headaches then it actually helps you. Let me examine the current situation:

You use a MySQL based backend to store the player data across all server instances and let the servers connect to that MySQL backend directly with a special program. That's totally fine and I'm pretty sure it worked very well in the development and in the first days. But right now joining a game takes very long and it seems that the backend it reaching it's limits. It even gets worse, since people are hammering the server by re-connecting to other servers at a fast rate (Which can't really be helped, since you can't educate the 'normal user').

You have seem to have acknowledge this problem and said, that you will run in the future a MySQL backend at every ArmAII server.

As I read that statement, I had to think: Do they know what they are doing?

Do you really want to write a custom solution for replicating the data across those 200+ server? That's not fixing the problem, that's only fixing the symptoms! (Even if it would work correctly after a long time of intense development.)

You are using MySQL in a way it was never intend to be used. MySQL is a database backend, which is designed to act as a backend for websites (much reads, less writes) and developed in recent years into a good all-around, general purpose database. It was never be meant to be distributed and replicated! Yes, I know there are cluster/replication option inside MySQL, but they are not intended to work in a 200+ server environment (Which the developers know, since they want to write a custom replication).

This is how you use you datastore right now:

- Lot's of read and lot's of writes (player positions get's updates quite often).

- Very easy data structure (essentially, it's just a value/key store, since you simply update/read the player data by the key/user id)

- No real need for SQL

- Scalability

- Eventual Consistency

MySQL wasn't designed for such a use case!

Please consider using a different data backend. You want a data backend, that has very cheap writes and has eventual consistency, since you update the player data often, but doesn't care about update conflict, since a player can only be at one server at the moment.

Please evaluate: Do you really need a SQL based system? Wouldn't be a key/value store more sufficient? There are very nice project in the real world, which would solve you problems (Casandra, MongoDB etc).

I'm fully aware that such a change would need very hard work and lot's of considerations, but I'm not sure if you are really developing in the right direction right now and would urge you to re-consider your architectural basement.

If you're pretty sure what you are doing and had many project before this one, which had the same requirements, please feel free to ignore this post.

[Bandit Hunter 29]

This might be something you would want to shoot, by email, to the dev teams public email address, rather than post here. The reason being whether or not its going to help the devs, input from the community isn't going to help much.

I know I can't advocate it at all, because i'm a technical idiot.

[Guest ragequitalready]

.

Edited October 25, 2012 by ragequitalready

[unsobill 0]

Just quick question : are you guessing on their current infrastructure or you have valid view of their logical data flow ? Thanks