Database to choose for game

views:

123

answers:

+1 Q:

Database to choose for game

I'm working on a game (something like chess) where every move needs to be saved into a database per move.

Since it's very important that both reads and writes are fast, and I don't need complex queries, I'm probably going to go with a NoSQL solution.

Which one though? I'm thinking about MongoDB but will its durability be an issue?

It's not the end of the world if some game movelists are corrupted, but would be problematic if it occurs too often.

Suggestions?

Thanks.

+1 A:

Just about any database technology would work in your scenario. There are no compelling reasons (that you've given, anyway) that would recommend "NoSQL" style data access over any other technology.

Mark 2010-08-31 17:17:41

I agree that most database would work. speed scalability concurrency and the lack of need for traditional relational db features is why I'm looking at nosql. Also would like to off source the database to some kind of cloud host... though that introduces latency :(.

Mark 2010-08-31 17:46:41

You can host mysql on Amazon EC2 instances if you want reliable hosting, and nosql probably has more negatives than positives for your use case (fixed schema, slow updates). Lack of atomic operations is probably a bigger deal than any gain in scalability. Besides, it's easier to transition to nosql later, IMHO, than to start there a d transition to SQL.

samkass 2010-08-31 23:26:24

+1 A:

I'd use SQLite--regarless of what lang your using you'll find a binding for it.

Mikey1980 2010-08-31 17:18:20

If high concurrency is a requirement, SQLite will probably not be the best choice.

Mark 2010-08-31 17:20:05

ver 3 has a new locking and journaling mechanism designed to improve concurrency.. but I see your point, tonne of little transactions may hinder performance

Mikey1980 2010-08-31 17:26:42

The new WAL (introduced in 3.7) journaling mode does indeed increase concurrency, but it still does not compete with the "big boys" when it comes to high-concurrency workloads. It doesn't pretend to, that's not what it was built for.

Mark 2010-08-31 17:31:28

Can you explain why? I'm not feeling this, I don't think I need a transactional database. And the move list is never going to be edited.

Mark 2010-08-31 17:41:15

If your database have more than one table, than NoSQL is no starter. I can immediately think of two: Positions and Moves.

Tegiri Nenashi 2010-08-31 17:22:56

Of course, the positions table is just a derivative cache of the moves table. And multiple tables doesn't preclude NoSQL if the tables aren't going to need to be joined. Still, I agree in the case of chess a traditional db is probably warranted.

samkass 2010-08-31 23:19:03

Last time I looked at a chess game you would need about 1 insert every 5 minutes. You could use LDAP server for that. But of course I do not know your use-case.

Mongo-db excels for document like records where you would want to extend the information over time. It has a nice ad-hoc query facility and is relatively speedy, which means about as fast as mysql database on the same machine.

In first view your data looks to be highly structured so the document flexibility will not add a lot of benefits.

If you have a huge number of records (like in many x10^6) then it will show the difference.

Now if you want to use mongo-db, fine, you probably won't be dissappointed, but I see no compelling case here.

Peter Tillemans 2010-08-31 17:25:59

Thanks Peter. LDAP though... :S The difference between mysql though is that the more writes you have to do the slower it becomes, whereas mongo scales more easily afaik. It's interesting nobody has mentioned durability, I guess it's not that big of an issue?

Mark 2010-08-31 17:34:51

If you would be processing my bank accounts then yes, durability would be an issue. For a game of chess I can live with the thought that if disaster strikes I might have to redo my last move. Mongodb allows the durability issue to be mitigated by scaling out.

Peter Tillemans 2010-08-31 17:45:23

The only advantage I can see to a mongodb or couchdb is that you could conceivably store the entire match in a single record, thus making your data a little simpler. You wouldn't have to do the traditional one to many mapping between moves table and a game table. CouchDB could be interesting because it supports offline transactions and a pure rest interface so all your code could be javascript. But you probably don't want your users to directly interface with the database!

Amala 2010-08-31 23:03:41

ansaurus

tags:

views:

answers:

Database to choose for game

related questions