Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31
  1. #21
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    Quote Originally Posted by pezz View Post
    I've heard lots of good stuff about SQL Lite, which is directly meant for games. Maybe that is an option? Haven't played with it myself yet, but again, have heard loads of good things.
    SQLite is intended to be a very light weight,in memory, single user database. There are ways to get more than one connection but this is for reads only. The big problem with SQLite is that only one write can take place against the database at time. For this reason and many others, SQLite isn't a good option for an MMO. It's more useful as an XML alternative in a single player game or something to that effect.

    I know the concept of a document database slughters quite a few sacred cows. However, the same thing happened when ORMs replaced stored procedures. This is just one of those uncomfortable changes that we have to work through if we're die hard relational db fans. Database tech is trending away from the relational model as much as possible because they are simply too difficult to maintain over the long run.
    Last edited by jjguzzardo; 02-07-2011 at 08:32 PM.

  2. #22
    Join Date
    Jan 2007
    Posts
    52
    Nelson & JJ,

    Back in November I got a new job working on a product which uses an ORDBMS and also a series of REST servers to store historical data and share application-wide data in a cloud, respectively. I hadn't even HEARD of any of those concepts before I got this job... I had previously worked on an old and ugly C/C++ parallel processing engine and API, so all these fancy-pants new technologies kinda freaked me out at first.
    You guys have helped me understand some of the new concepts that I've been working with for the past few months more than any of my co-workers could! Haha!

    I love 3DBuzz! I never fail to learn things which help me in my career... great stuff!
    /* No Comment */

  3. #23
    Join Date
    Jun 2010
    Posts
    17
    From what I have read thus far it seems that our data needs has the following attributes, making RavenDb appropriate:

    - It will be read heavy
    - It will not make use of relations

    Thinking of our data needs as an extended live entity cache makes a relational DB the wrong tool.

    On the other hand for something like logs and metrics where you want to explore relationships a relational DB would be better. But that can be achieved through offline tools eliminating this need from the game server.

  4. #24
    Join Date
    Feb 2011
    Posts
    7
    Remember, there is a free MSSQL called SQLExpress (but is limited for commercial use) and a completely free embeddable MSSQL called SQL Compact. Which shares most of the Engine core but is missing features like stored procs, UDF, Full Text Search and spatial datatypes.

    Adam

  5. #25
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    Quote Originally Posted by adamhill View Post
    Remember, there is a free MSSQL called SQLExpress (but is limited for commercial use) and a completely free embeddable MSSQL called SQL Compact. Which shares most of the Engine core but is missing features like stored procs, UDF, Full Text Search and spatial datatypes.

    Adam
    The one issue I see with SQLExpress is that you are limited to 1 CPU, 1 GB of RAM, and your database size can only be 4GB. Granted, for this class that's probably more than enough, however, if you're thinking about doing something commercial, this could be a big limitation. If you really like relational DBs then I would suggest MySql. This way if you decide you want to build something for fun you're ok but if you decide later you want to try something commercial, you don't have to make major changes. Also, just because you go with a relational database doesn't mean you can't work with it in a document sort of way. For example, you could very easily create a user table and store the users' data as a JSON string in one of the fields in the user record. The thing you lose with this is the ability to query into the user's blob data. With a document database you can. I know to many business app devs this approach may seem horrible, it feels wrong to me, however, there are many MMO/Server based games i've worked on that use this exact approach very successfully.

    Personally, I want to give RavenDB or MongoDB a shot because i've never seen a database like this used on a game and I want to see how it works.
    Last edited by jjguzzardo; 02-09-2011 at 12:48 AM.

  6. #26
    Join Date
    Feb 2005
    Posts
    15
    If you use MSSQL it lets you store an XML document in a field. Think not as a single record. You can have multiple repeated elements in XML format and then store in one place as “XML” on a field of a table. MSSQL allows you to utilize xml queries in (T-SQL) Transact SQL to retrieve any information inside the XML data of specified record or records in table. It is also allow building indexes for the XML schema.
    I have implemented this in one of my projects. But Raven uses LINQ for querying data which is a must and removes all the complexity of TSQL xml queries.

  7. #27
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    Quote Originally Posted by nmilioti View Post
    If you use MSSQL it lets you store an XML document in a field. Think not as a single record. You can have multiple repeated elements in XML format and then store in one place as “XML” on a field of a table. MSSQL allows you to utilize xml queries in (T-SQL) Transact SQL to retrieve any information inside the XML data of specified record or records in table. It is also allow building indexes for the XML schema.
    I have implemented this in one of my projects. But Raven uses LINQ for querying data which is a must and removes all the complexity of TSQL xml queries.
    Very true. The thing is in a RESTful environment if your using JSON as your persistence layer on the wire then you would have to convert to XML on the server for data storage. With something like a document database you can take JSON in it's native format, in most cases, and save it to the db. However, there is no reason you can't persist objects on the wire as XML in which case what you're suggesting would be very viable, depending on how fast SQLServer XML queries are. Once reason you might want to stick with JSON is that JSON is more compact than XML so the data you move back and forth accross the wire is much smaller which can be a performance gain. However, I've seen it done both ways and either one can work nicely. Very good thoughts

  8. #28
    Join Date
    Jun 2010
    Posts
    17
    I suspect that thinking of our data persistence needs as "= Database = Relational Database = SQL" is missing an opportunity.

    Relational databases are really good at, well, relationships and combining and filtering on those. Find all the users that have two or more swords on level 3 and no friends and show me how much money they have.
    From what I gather, our needs on the other hand will be more directly storage related. Update user X to have more money so that if the server restarts we have accurate information.
    The more complex relations in the game would probably be transient with no real need to persistently store it accurately up to the second. Party 123 consists of users X, Y, X. Monster 222 and is attacking user X. This info does not need to survive a server restart in a 100% to the second accurate way.

    So the tool we need would be one that allows us to generally find and update a single record based on a simple index quickly.
    This is what document DBs are apparently good at.

    Personally I plan to investigate CouchDb in parallel. At least its free and its based on Erlang, a language I love.

  9. #29
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    Quote Originally Posted by DeepFreezZA View Post
    I suspect that thinking of our data persistence needs as "= Database = Relational Database = SQL" is missing an opportunity.

    Relational databases are really good at, well, relationships and combining and filtering on those. Find all the users that have two or more swords on level 3 and no friends and show me how much money they have.
    From what I gather, our needs on the other hand will be more directly storage related. Update user X to have more money so that if the server restarts we have accurate information.
    The more complex relations in the game would probably be transient with no real need to persistently store it accurately up to the second. Party 123 consists of users X, Y, X. Monster 222 and is attacking user X. This info does not need to survive a server restart in a 100% to the second accurate way.

    So the tool we need would be one that allows us to generally find and update a single record based on a simple index quickly.
    This is what document DBs are apparently good at.

    Personally I plan to investigate CouchDb in parallel. At least its free and its based on Erlang, a language I love.
    Please correct me if I’m wrong, however, you seem to be implying that while the game is running there will be database queries going on to find and save game related data, which is why relationships, etc would be important. The fact is that this usually does not happen in real time. All the data operations that happen in real time (while the user is actively playing) happen against server memory. For performance reasons, data is only written to the database on a periodic basis, not every time an event happens. This also why arguments I hear about db write speeds are usually irrelevant. The dirty little secret here is that the database, usually, has a very limited role when the game is actually running.

    Here is a more specific breakdown of how data/server memory is used for games I’ve worked on that service millions of users. There are two types of data that we work with, “proto data” and “instanced data”. Proto data is all the global data about items, quests, etc. An example of proto data for an item might be the name of the item, the cost of the item, how much damage it does, etc. An example of instanced data is data related to the item that is specific to the user who owns it. So something like an items durability would be part of the instanced data because durability depends on actions a user takes after they acquire the item and isn’t global. When the game starts, all proto data is loaded into memory. Since I’m on a Linux system this would be memcache, I don’t know what the windows equivalent is but I’m sure windows has a good enterprise caching solution. When a user logs into the system, that users data is then loaded into memory. So now we have a user loaded in memory and all proto data loaded in memory, so if I pick up an item, I look up the item in memory and add the item to my user in memory. This flags my user as dirty and my users ID is added to a queue. On a periodic basis (usually 30 to 60 min), a process checks the queue and saves user’s to the database and then pops their id off the queue. So you can see here that the game is totally abstracted from the database via caching.

    Now, you could do it the business application way where you do every database operation in real-time. While this might work for 100 users, it will never work for hundreds of thousands or millions of users. Sometimes performance and scale force you to make adjustments to architecture that aren’t as sexy as you’d like them to be. I know it might be more fun to model everything in a db and then have all your abstractions pulling and pushing data in real-time. The problem is that it just doesn’t work and at the end of the day stuff working is more important than how fun it is to solve a problem a certain way.
    Last edited by jjguzzardo; 02-10-2011 at 01:50 PM.

  10. #30
    Join Date
    Jan 2011
    Posts
    72
    Is an Object DataBase relational in the background but just easier to access and update all data ?

Page 3 of 4 FirstFirst 1234 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •