Scattered storage model?

Networking & Multiplayer
#1

As I currently see it the only storage I can access safely from a GLO is the ObjectStore, because the execution of GLOs is farmed out on the cluster (i.e. no reliable “local” server) and to open a socket and read/write data from/to a remote server will take too long and the GLO execution might be aborted before it is able to complete.

So all the data needs to be stored in the ObjectStore in order to be accessible from an executing GLO. Unfortunately a GLO loads in whole all the time to in order to be instantiated again. To get a more efficent data model which is able to act like an indexed file where I can access records only instead of loading the whole file every time, we would need to implement “file”-GLOs which hold references to “records” stored in “record” GLOs. This is not a very efficient way to do that, but without any normal way to use the underlying database (lets say via SQL or such) I see no way around this - all data needs to be stored in GLOs to be accessible from GLOs as it is currently implemented. Or am I missing a point here?

Ragosch

#2

Hi

Yup, everything is a GLO. I’m not sure why you are after index file style access, replacing those was the point of DB’s, GLOs are named objects, that can contain references to other GLOs. I’m curious as to what data it is that you want to load as indexed files?, we may be able to think of a nicer solution.

Cheers

Endolf

#3

It is not really that I want to access an indexed file - it is just that I dont want to read the whole “file” if I just want a few “records” out of it. There is a database underneath SGS - a SQL database - and therefore I wonder why we dont get SQL access to it to be able to store other data there, instead of splitting them into hundreds of thousands or millions of GLOs. A SQL query can deliver a rather sophisticated result set but with just naked GLOs we cant do such queries even the database to do so is there - that’s my problem, because we need to store, organize and manage a massive amount of economical data for our game where access to database services would be fine - now we need to hold redundant copies of part of the data on the client machines, what causes additional synchronisation which would not be needed if we could access the underlying database system via SQL directly from a GLO.

This could be done asynchron in a way - a “query” GLO constructs a query and creates a new “result interpreter” GLO implementing an interface in order to be “called and executed” by the “result set ready” event. Then the “query” GLO requests the query from the task providing the GLOReference to the “result interpreter” GLO. Later when the result set is ready, the task loads and executes the “result interpreter” GLO passing the result set to it (much in a way an event loads and executes a GLO in the current implementation). That would be an elegant way to handle SQL queries while sticking to the “tasks are short-lived” rule.

I mean that is a real problem. Every sophisticated game will need some kind of database services which needs to be used from inside the game logic on the server-cluster and there is no safe way to establish a connection to a database from a GLO due to “a task is short-lived” rule. Like it is implemented now we would be force to use just a form of indexed file access or less without any possibility to use high-level database queries even the database is there. Hope it is more understandable now what I am after.

Any suggestion on that?

Ragosch

#4

Lazy loading?

#5

The problem here is not a loading method, but the need for a sophisticated database system if you have a game a bit more complex than this tank demo game. Our game has a real economy ingame (even it is a MMORPG) and users need to analyse economic situations, alter price lists, handle trade-routes, wagon loads and so on and so on. This is done best using a database system, but unfortunately with SGS I do not have a database system available which I can acess directly from a GLO (in the easiest case from the “player” GLO). All those fine things like SQL queries would not be available using just naked GLOs as the only storage available. All we have with this ObjectStore is a kind of transactional-safe “hashtable” - but no database system, even one is there underneath, and that is sad … we would just need a method to access and alter it using SQL. Without any abiltiy to use a database system from the game logic, SGS is just a nice idea but pretty worthless for sophisticated games which are not just hack and slash style.

Ragosch

#6

Hi

I agree, when there is a simple mapping and you want just a named object here and there, then it works well, but when you want to query the datastore and return a few results based on other related info, then yeah, I guess we have an issue.

A really simple example might be returning the top 10 priced objects in the market. In SQL, you just write a stored proc or a simple query, and let the DB do it’s job, they have spent years and years developing fast quries like that, add an Index to that table, and it’s nice and quick. In SGS we would have to load up every object in the market, sort them in memory by price, and then return the top 10.

I think Jeff is on vacation atm, so I dunno when he’ll be able to get back to us, but one alternative might be to run the complex stuff like the market externally to SGS, have the client connect to a market server when needed. I hope Jeff has a better solution though.

Endolf

#7

I think that serialization is generally not a best idea for long term persistent storage. It becomes a LOT of pain after year or two, when half of code inside your objects is written to handle all the possible combinations of old data.

In one project I have worked for where we have used serialization for most data, we had string query field in addition to blob with serialized data in every row (in addition to timestamp, modified_by and version fields). It is overly complicated design done just to have same structure of table for every object out there, but something similar could be used here - in addition to object id and serialized blob, there can be any number of extra columns duplicating some of the data from object. You could then decide what aspects of given object you want to use for sql queries, with all the rest, less important data being hidden inside blob.

In market example, stuff like location, price, object type, quantity, owner, expiration date could be exposed, with detailed description, object itself, vendor percentages etc being hidden inside serialized data only. If at some point more data is required, it would be one time offline extension of database by a column and going through all serialized objects, rewriting them to database.

Anyway, I think that at some point, for most serious projects you will end up with using just normal sql storage, with explicit store/load code (maybe using some mapping tools) and dropping serialization completly, except maybe some intra-server communication if needed. SGS does not support it at the moment, but I don’t think it should be too hard.

Another possibility would be to use some kind of fully object-oriented database and creating some kind of EJBQL… I mean SGSQL… but I’m afraid this would be outside of scope of this project.

#8

abit side track: does anyone knows how large(capacity) is the storage of the ObjectStore? ???

#9

Currently the derby java DB is underneath - there are practically no limits beside those given by the OS. But Jeff mentioned HADB for their “big” solution. They wont choose a limited db, I guess, but you cant count on a specific db with SGS.

Ragosch

#10

I basically have pointed out how it could be integrated without breaking the current system. There need to be an interface for an “result set ready” event. This interface needs to be implemented by a GLO which is intented to work on the result set as soon as it is available. This GLO would be loaded and executed via this interface much in the way GLOs are loaded and executed by SGS events now. There needs to be a method in the task object which takes a SQL query and the GLOReference to that GLO which implements this “result set ready” interface. The task can now query the underlying database and prepare the callback when the result set will be available. When the result set is available the SGS should load and execute the GLO listening to this event. An asynchron elegant way to integrate this into the current model without exposing the underlying database too much.

Ragosch

#11

@abies:

The current model of SGS is pretty good as far as you need to work with data synchronized to its handling methods (i.e. objects). The use of GLOs is perfect for breaking down program execution into slices which can then be farmed out on the server-cluster using a central persistent and transactional-safe storage. So far so good. But all those mass data with sophisticated query needs cannot be integrated into this model nice and easily - the nature of data retrieval here is asynchron and not synchron. It could be broken down into 2 steps, a GLO starting the query and another one which is started when the correspondenting result set is ready to work on. But SGS would need to offer some kind of SQL support through the task object (the SGS context for GLOs).

Ragosch

#12

The problem here is that market data are basically effected and produced by actions inside the game. And there is no real good way to access any other storage than the ObjectStore from GLOs. You could use a special client as a server to be able to access a database elsewhere, but this would be a horrible hack, and I really hate hacks. There is no way currently to access another storage than the ObjectStore from GLOs, and that is the place where market data manipulation happens. So there is no real good way to use an extern market server like you suggested.

Ragosch

#13

Hi

I was meaning that the game client runs 2 connections, 1 to SGS when in game, and 1 when needed to the market server. Use SGS for what it seems to be good at, ie, the movement control and game object management, and an interface to a DB for what they are good for, fast queries over larger data sets.

SQL can’t be called on SGS object store as the whole GLO is stored via serialisation (if memory serves), so there is no way to query any of it’s members.

Endolf

#14

As I pointed out the alteration of market situation happens inside the game logic (in the GLO pool). Now how do you expect these data to be transferred to an extern database?- That is the problem here, because you cant access anything outside the SGS beside connections to the clients. So you need either do a hack with a fake client which is actually just a way to transfer SQL commands to an extern database or you need to make a design enhancement to the SGS providing some basic SQL access via the SimTask object to the internally used SGS DB. How this services could be integrated into the current implementation of the SGS I have suggested twice in this topic … if there are any questions please ask because I dont know how to explain it any better yet. But this is a really vital problem for all games which are not just “very basic demos”.

Ragosch

#15

I would looking into embedding the sgs client into the market app/server using the sgs as a layer between

player

SGS

market

and in this setup using the SGS as an kind of cach at the same time. security wise it should be easier complexity wise it should be simple since the client only needs one connection then a market is usually represented by a few npc’s anyways. (call it a hacked client if you must I gues.) I’m sure there are other perhaps more elegant solutions but I don’t have time to look at it.

#16

That is not what I trying to achieve. I want to use database features of the underlying SGS database via SQL (by enhancement of the current SimTask-services). This way mass data would not be stored in the ObjectStore via GLOs but in a normal way using the underlying database. GLOs would be just those world objects and some special GLOs use to communicate with the SQL-database over a process similar to that I have suggested (asynchron query/result processing). I dont want database services to objects in the ObjectStore, just a bypass access to the underlying database using SQL in oder to use this database in the normal way including creation of new tables, sophisticated queries and such.

Ragosch

#17

Tell me how I can transfer data from the SGS to an extern database without using a bridge fake client which is just there to do transfer to and from extern database to the SGS - this is a horrible hack and will not perform very well. The other solution of just using the database underneath the SGS which is already there and could provide all those services easily would be much better and is also really easy to implement (but it needs to be provided by the SimTask object and the callback needs to be done with a special “result set ready” interface implemented by the 2nd GLO which will process the data requested later - the later would just work in the same way GLOs are loaded and execute by events in the current implementation of the SGS).

Ragosch

#18

We dont have this kind of fake economy. We use a real economy based on supply and demand, desire, reputation, social status and a complex hierarchy of markets of up to 750,000 characters in game. We have 2 economists in our team in order to create a real working economy in our game, not just a fake like in nearly all other games. Maybe now you can imagine that we really need database services for this, not just a few named GLOs accessed in a hashtable like manner.

Ragosch

#19

how does a player interact with the market then? action wise and performace wise. how real time is real time? yocto seconds? how are these markets connected economi wise? knowlage is power how fast can market knowlage posibli be gattered, are you modeling the the economi in abstract sence do you actually the requirements you set if you do then could you outline it? I say this because Invoice’s should have a human like time span that they are valid. (I mean ppl actually need to be able to read an invoce before that they can decide if they agree or not,.) where do invoces come from? a person? a computer? undoubtly the player needs some way of interfacing with the market. an npc can exsist in many forms. there can be many of these and If they need a common mind set you can tie those togetter.

a database is non redudant per default this means that anything that can be calculated shouldn’t reside in it. however you are gonna need the computed values some where in your game I sugjested storing those computed values as GLOs where as the actual database is.

it won’t perform badly if implented right the main objection will always be that it’s achitechtually ugly and will introduce failover-issues.

#20

Unfortunately it seems that I didnt have explained it good enough, sigh.

The problem is that I cannot access any other storage then the ObjectStore from GLOs in an elegant and safe way. I personally hate the idea of using a special client as gateway to an external database - simply because it is a client which would need to act like a communication server between SGS and an external database - what a hell of a hack, I hate it - that really turns me off and lets me think of implementing the whole thing myself basing it on JXTA and drop SGS totally. It is kind of ridiculous that there will be no elegant access to a sophisticated database if one is already there but not accessible currently. And it will be not just me who demands database access from the game logic … this is a central need for any game more than just a tech demo or cellphone game.

Ragosch