AJAX Mud Forums

I recently encountered the notion of not storing any game-data in memory and instead using a completely disk-based system. I mean wouldn't this ensure, in the event of some catastrophe, that all player data is secure?

Yes and no. What about the *integrity* of the data. How do you detected if a DB is uncorrupted after a crash? What would happen if the server or game crashed while in the middle of a write operation? You could store multiple copies, caches that are then merged with the regular database at a later date but this sort of defeats the purpose.

It's easier to just do regular backups and only access the disk when needed. Disk-based access is slow. Even with fast hardware disk-access will be slower compared to volatile memory.

That and many systems today use portions of the HD as a simulated form of RAM, so in the event of a crash, you could potentially recover some of the lost data.

(05-25-2010 08:39 AM)York Wrote: [ -> ]I recently encountered the notion of not storing any game-data in memory and instead using a completely disk-based system. I mean wouldn't this ensure, in the event of some catastrophe, that all player data is secure?

Yes and no. What about the *integrity* of the data. How do you detected if a DB is uncorrupted after a crash? What would happen if the server or game crashed while in the middle of a write operation? You could store multiple copies, caches that are then merged with the regular database at a later date but this sort of defeats the purpose.

It's easier to just do regular backups and only access the disk when needed. Disk-based access is slow. Even with fast hardware disk-access will be slower compared to volatile memory.

That and many systems today use portions of the HD as a simulated form of RAM, so in the event of a crash, you could potentially recover some of the lost data.

I find a solely disk-based storage a bad choice for the simple reason of performance, as you mentioned. I think most implementations are a hybrid where changes are serialized to a database as well as in memory. This way you have the best of both worlds.

If you use an ACID-compliant database (PostgreSQL, MS SQL Server, Oracle if you are ridiculously wealthy, etc) it will handle all this for you.

Integrity: This is the main purpose of ACID. If the database returns that your data has been stored, you can trust that it is. Of course you might blow out a hard drive or something, in which case you had better have run backups regularly (and there are ways to make sure you don't lose ANY transactions).

Speed: No disk-based storage can match the speed of RAM, but any RDBMS worth its salt will cache most of the frequently-accessed data in RAM anyway.

This is not to say you couldn't work something on your own, but really this is what they are *for*, and have had (a) thousands of man-hours of work put into them already and (b) millions of man-hours of testing and actual use. I may be biased since I am paid to work with the things