Re: [nodejs] Which database to use for a realtime chat game?

[Nikhil Marathe]

I'd recommend Redis and using it's pubsub feature

Nikhil

On Sat, Oct 6, 2012 at 6:44 PM, Nickname <ad...@glados.cc> wrote:
> I'm creating a chat based game with Node.js and I would like to know which
> database is best for the job?
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Alexey Petrushin]

+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.

[Julian Gruber]

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

[Angel Java Lopez]

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

On Sat, Oct 6, 2012 at 10:44 PM, Nickname <ad...@glados.cc> wrote:

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

--

[Yi Tan]

+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 <ajlop...@gmail.com>

[Jake Verbaten]

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

[Stewart Mckinney]

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

On Tue, Oct 9, 2012 at 5:00 PM, John Fowler <john.f...@gmail.com> wrote:

In case it matters, if you're looking for a client-side relational database engine, SequelSphere 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...

[Alexey Petrushin]

> Redis is fine too, and MongoDB is fine.

How to use MongoDB, seems there's no way to take an instant (sort of instant) feed of events?

[Stewart Mckinney]

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. 

[Daniel Rinehart]

I think other solutions are better but you can do pub/sub style
systems with MongoDB:

http://blog.mongodb.org/post/29495793738/pub-sub-with-mongodb

-- Daniel R. <dan...@neophi.com> [http://danielr.neophi.com/]

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