I'm creating a chat based game with Node.js and I would like to know which
database is best for the job?

+1 for redis Redis

CouchDB also have interesting features (pub/sub and others), but it seems
there are rumors about its performance not so good.

MongoDB is my choice. And if you want to scale into the cloud check out
firebase.

Also checkout dominictarr's scuttlebutt or crdt for a master-less approach

Hi people!

My questions are basic, but I prefer to ask them, to have more context and
to have a better understanding of your requirement:

- Why you need a database? What are the use cases?

I could imagine a game, based on chat messages, that don't need a database;
it can distributed the message to the clients, and it can have an in-memory
state of the game (one server instance per game, sticky assigned at begin
of the game, maybe using a hash mapping from game id to server id to manage
the game; I presume the servers can be identified... etc... etc...).

Do you need a database to keep the CURRENT game state? To save the game
history AT END? To keep the score of the players?

Angel "Java" Lopez
@ajlopez

+1 to Angel Java Lopez's question.

In high traffic real-time games, data persistence no need to be in
"real-time".

The important thing I think is how to efficiently and accurately delivery
message to clients in low lag and low bandwidth consumption

Regards,

ty

2012/10/8 Angel Java Lopez <ajlopez2...@gmail.com>

Consider a combo like crdt + indexedDB + discovery-network for a
distributed game

In case it matters, if you're looking for a client-side relational database
engine, SequelSphere  <http://www.sequelsphere.com/>may be something to
look at.  It is an HTML5/JavaScript relational database that has full
support of SQL and provides the ability to store data in localStorage or
other manners.

Hope this helps,

john...

CouchDB is fine, if you don't like its performance, use CouchBase.

Redis is fine too, and MongoDB is fine. IMHO Couch is easiest, and its not
hard to migrate from Couch to Mongo/Redis if you are still prototyping and
prepping for scale.

Just don't use SQL to store a chat log.

Content = noSQL
Numbers = SQL

.02

I wouldn't rely on the database as the backbone of the (any) real-time
feed; I would instead focus on using it for purposes of archival and "bulk
information loading". I would reiterate the questions Mr. Lopez asked, and
then question the need for immediate "mirrored" status present on disk or
in distributed memory. Real-time feeds should be services in themselves,
not glommed onto a database which has other things to worry about.

In other words, if you are expecting constant push updates from the
database itself, you are probably doing something "wrong". Not "Wrong", but
"wrong". It crowds what a database is supposed to do. A good example of why
it "crowds" is to ask yourself why other databases that might be replicants
or slaves would need that information in a fully up-to-date manner,
especially if they are offering segmented experiences.

The answer is that they probably wouldn't - only a particular "servlet" -
or if you would prefer to think about it this way, a set of clients -
would. Unless of course you are planning on engaging everyone at once -
upwards of a million people, lets say - in which case you probably have
other problems, and thats definitively "doing it Wrong". This also brings
into question what the action of the game is, but its outside of the
discussion for now. The fact remains that, there are other ways to push and
"store" that kind of information. You might have to get a little creative,
but hey, thats app development.

As a simpler example of how it could be done, I would suspect at some point
there would be a client host (assuming one person 'starts a game'), or some
form of server side host/service that is aligned to each "room" or several
rooms. It's entirely possible to use that servlet/client as the arbiter of
current state. I would use the database response as a starting point and
then fill forward from whatever the servlet/client host had.

On Tue, Oct 9, 2012 at 9:17 PM, Alexey Petrushin <alexey.petrus...@gmail.com