Thread: game db
Hello! I'm currently coding a game, using C++ and OpenGL. I need to store the game state data into a database, and heard alot of positive things about PostgreSQL. As this is a game, speed is critical. I'm going to do alot of writing to the database, but seldom much reading from it, so I'm mostly interested in write-speeds. Does anyone have an idea if Postgresql could suit my needs, or should I look into other databases (mysql for instance) ? Best regards, Kenneth Gangstø
If you need a full-blown SQL database, PostgreSQL is an excellent option. We are running very intensive queries on it and it performs very good. If you are writing a game that does not need multiple processes accessing the database at the same time you may find it better to use an embedded database. For this purpose you can use GigaBASE (http://www.ispras.ru/~knizhnik/gigabase.html), which is a great database that uses a subset of the SQL syntax for its queries and that is very fast and easy to use. On Friday 22 February 2002 18:12, you wrote: > Hello! > > I'm currently coding a game, using C++ and OpenGL. I need to store > the game state data into a database, and heard alot of positive > things about PostgreSQL. As this is a game, speed is critical. I'm > going to do alot of writing to the database, but seldom much reading > from it, so I'm mostly interested in write-speeds. > > Does anyone have an idea if Postgresql could suit my needs, or should > I look into other databases (mysql for instance) ? > > Best regards, > Kenneth Gangstø -- Juan Jose Comellas (juanjo@comellas.org)
Hi Kenneth, It really depends on what you need the database to do. If the database which your game will be running on will be having a bunch of people simultaneously using it, then PostgreSQL kicks the crap out of MySQL. But, for single user use (i.e. one database on every client system), MySQL is pretty much WAY faster than PostgreSQL. We have different coding and optimisation priorities, so there's a fairly marked difference here. Also, you need to determine how "important" the game data is, as if you need to go with MySQL, they have different "table types" which offer different advantages. If its data that can afford to be lost without much worry, and you're using a predominately single-client database system, then MySQL with it's default table type (can't remember its name) could be your best choice. If you're in a single-client database model and the data is important, MySQL has the InnoDB table type, which is apparently very rugged and is hard to lose data from, as well as offering the capability of Transactions, ACID compliance, etc. (You might need to look those terms up if you're not familiar with them). Something which has come to light recently is that people which write the InnoDB table stuff have put out a benchmark page, and it claims to be more than 10x faster than even the leading proprietory database vendors, in *every* circumstance. I looked at the page and am very concerned that they've decided to skip being honest, and do very blatent bullshit in their benchmark claims. I can't fathom how any database on the planet could be 10x faster than everything else. Oracle would have bought them on the spot if that was the case, AND they would have been able to name their own price. :( Anyway, SapDB has a good reputation too (another now-Open-Source database), www.sapdb.com from memory, but I haven't had a chance to use it. Hope that help Kenneth. :-) Regards and best wishes, Justin Clift Kenneth Gangstoe wrote: > > Hello! > > I'm currently coding a game, using C++ and OpenGL. I need to store > the game state data into a database, and heard alot of positive > things about PostgreSQL. As this is a game, speed is critical. I'm > going to do alot of writing to the database, but seldom much reading > from it, so I'm mostly interested in write-speeds. > > Does anyone have an idea if Postgresql could suit my needs, or should > I look into other databases (mysql for instance) ? > > Best regards, > Kenneth Gangstø > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Quoting Kenneth Gangstoe (sphair-postgresql@dark.x.dtu.dk): > Hello! > > I'm currently coding a game, using C++ and OpenGL. I need to store > the game state data into a database, and heard alot of positive > things about PostgreSQL. As this is a game, speed is critical. I'm > going to do alot of writing to the database, but seldom much reading > from it, so I'm mostly interested in write-speeds. > > Does anyone have an idea if Postgresql could suit my needs, or should > I look into other databases (mysql for instance) ? > > Best regards, > Kenneth Gangstø Thanks for all the answers! Since I didnt go much into detail, I'll try to explain more what Im going to use it for. I'm coding a multiplayer game (not massive, but around 100 connected clients). They will all connect to a server, which will store its gameworld state (players, player-positions, items, quests, etc) in a database. Most if this data will be in the servers memory, and only stored to the database on updates. So reading data from the database will only happen at init-time, at a new client connection and similar cases. Several servers might be used to balance the load, so I might have from 1-3 servers connected to the database at once. The clients won't have any direct connection to the database. Its important to avoid data-corruption of the database, but I won't need the fullblown fsync option I believe. If the gamestate goes back 5 mins on crashes, that won't be a huge problem, as long as the data is consistent. I haven't looked into SQL databases much, but I don't think I need much "fancy" features - I guess a basic SQL interface is plenty - doing simple selects and updates. Whate exactly are the prime differences between an embedded database and the full RDBMSs ? The reason I looked into PostgreSQL was that I found a book in the bookstore called PostgreSQL Developer's Handbook. Anyone have experience with this book? Best regards, Kenneth Gangstø www.clanlib.org
The key thing you need to consider is what type of game state data will be
stored. Is a SQL RDBMS what you need? Usually that would be needed if you
have complex ways in which you need to access your data.
If you're looking for more of a storage/retrieval system, you might look at
an embedded database like berkeleydb (sleepycat.com). For that purpose,
Berkeley DB will be faster and simpler, and take less disk space.
Assuming you need a SQL database, PostgreSQL is a great one.
If you give some quick examples of the kinds of queries you might be
performing, that would help a lot.
Regards,
Jeff
> I'm currently coding a game, using C++ and OpenGL. I need to store
> the game state data into a database, and heard alot of positive
> things about PostgreSQL. As this is a game, speed is critical. I'm
> going to do alot of writing to the database, but seldom much reading
> from it, so I'm mostly interested in write-speeds.
>
> Does anyone have an idea if Postgresql could suit my needs, or should
> I look into other databases (mysql for instance) ?
> Several servers might be used to balance the load, so I might have from 1-3
> servers connected to the database at once. The clients won't have any
> direct connection to the database.
This architecture lends itself to an RDBMS like postgresql. You can connect
from several different computers to the same postgresql database, which is
what it sounds like you're interested in. MySQL is also capable.
>
> Its important to avoid data-corruption of the database, but I won't
> need the fullblown fsync option I believe. If the gamestate goes back
> 5 mins on crashes, that won't be a huge problem, as long as the data
> is consistent.
Postgres allows either option, as do many other databases.
> I haven't looked into SQL databases much, but I don't think I need much
> "fancy" features - I guess a basic SQL interface is plenty - doing simple
> selects and updates.
The main reason I like postgres is because of how it handles complex
situations gracefully. It doesn't sound like you really need a lot of complex
capability.
> Whate exactly are the prime differences between an embedded database and
> the full RDBMSs ?
An RDBMS is a seperate daemon running that accepts requests from an
application (i.e. your game) and returns a result to your application.
An embedded database can be considered a library of functions that are used
to securely maintain your data in a way that keeps it accessible. The
functions operate inside your application. A simple embedded database would
be to just write your data to a text file when you called a store() function
and read it back when you call a retrieve() function (that is obviously a
*very* simple form). Berkeley DB is a very good embedded database, with
transactions and good locking and everything else that would help you
maintain consistant data. Embedded databases have a much faster startup time,
since it doesn't require starting up a new process (like postgres does).
Here is my impression of what you need: a way to essentially save your
current RAM state (at least the relevant parts of the RAM) in case you want
to restart from that point. I would say that Postgres is probably overkill
for that. It sounds like an embedded database like Berkeley DB
(sleepycat.com) is what you're looking for, since it would be fast and
simple. To address the need for multiple servers accessing the data, you may
look into something like NFS. If you can come up with some reasons that
something like an RDBMS might be helpful, you should look into it, but it
seems more like you just want to store/retrieve current information in a
simple way.
Regards,
Jeff