Top Mud Sites Forum - View Single Post

koteko · 12-03-2012, 08:11 AM

I might have found a solution:

It implements a java.util.Map interface for a disk based map, with cache. It's the fourth version of a 10-years old library called JDBM, first born to manage astronomical data (millions of records). It supposedly scales well for maps smaller than 10^8 elements, which is fine for me considering that I would work with less than 30 millions rooms at most. I guess the disk footprint is going to be massive though :P but it shouldn't be a problem. It supports indexes and a few characteristics from relation DBs.

My idea is this. I have a proper relational database, H2, with all the data. It's going to be huge but I can enable compression, encryption, backups and the such. I'll try to make the data compact enough without being unanderstandable.

Than, at startup, I start populating the disk-backed hashmap, but only with the "necessary" entities. As the players log in, more entities are put in the map. In this way, after the inital little lag, if anything, the most used parts of the world would be loaded into the hashmap. The map will "commit" to the disk only when the objects go over a particular threshold, so the RAM is well under control. At that point, the disk and memory usage is transparently managed by MapDB so I don't have to care anymore.

When it's time to save the world, I iterate the map and if something needs to be eliminated/added to the DB, I do. Than I update the existent records, using referential integrity to be sure everything is how it should be (no links to non-existent objects, etc). In this way I always have a compressed and coerent data in case during the execution of the MUD something goes bad.

EDIT: @Achon, I have looked into Berkely DB, yes, and it might be another solution. I guess I'll have to experiment..but I have to say I much prefer to work, into the MUD, with specialized classes (Room, Mob, Player with their appropriate inheritances) for the world stuff, and I don't think I'll be able to do it with BerkelyDB unless I create those classes on the fly OR I store the serialize the objects into the DB which is, in my opinion, like killing the whole idea of a relational DB.

A decision will be made but for now I think I'll go with the disk-based map, because I don't have to change anything in my code, just the instantiation of the map itself. I really hope it is stable and efficient how the author says.

12-03-2012, 08:11 AM	#12
koteko New Member Join Date: Mar 2012 Posts: 20	Re: A huge grid world I might have found a solution: It implements a java.util.Map interface for a disk based map, with cache. It's the fourth version of a 10-years old library called JDBM, first born to manage astronomical data (millions of records). It supposedly scales well for maps smaller than 10^8 elements, which is fine for me considering that I would work with less than 30 millions rooms at most. I guess the disk footprint is going to be massive though :P but it shouldn't be a problem. It supports indexes and a few characteristics from relation DBs. My idea is this. I have a proper relational database, H2, with all the data. It's going to be huge but I can enable compression, encryption, backups and the such. I'll try to make the data compact enough without being unanderstandable. Than, at startup, I start populating the disk-backed hashmap, but only with the "necessary" entities. As the players log in, more entities are put in the map. In this way, after the inital little lag, if anything, the most used parts of the world would be loaded into the hashmap. The map will "commit" to the disk only when the objects go over a particular threshold, so the RAM is well under control. At that point, the disk and memory usage is transparently managed by MapDB so I don't have to care anymore. When it's time to save the world, I iterate the map and if something needs to be eliminated/added to the DB, I do. Than I update the existent records, using referential integrity to be sure everything is how it should be (no links to non-existent objects, etc). In this way I always have a compressed and coerent data in case during the execution of the MUD something goes bad. EDIT: @Achon, I have looked into Berkely DB, yes, and it might be another solution. I guess I'll have to experiment..but I have to say I much prefer to work, into the MUD, with specialized classes (Room, Mob, Player with their appropriate inheritances) for the world stuff, and I don't think I'll be able to do it with BerkelyDB unless I create those classes on the fly OR I store the serialize the objects into the DB which is, in my opinion, like killing the whole idea of a relational DB. A decision will be made but for now I think I'll go with the disk-based map, because I don't have to change anything in my code, just the instantiation of the map itself. I really hope it is stable and efficient how the author says.