Received: by 10.66.89.135 with SMTP id bo7mr5102625pab.39.1349837834225; Tue, 09 Oct 2012 19:57:14 -0700 (PDT) X-BeenThere: nodejs@googlegroups.com Received: by 10.68.237.161 with SMTP id vd1ls390384pbc.3.gmail; Tue, 09 Oct 2012 19:57:01 -0700 (PDT) Received: by 10.66.73.1 with SMTP id h1mr2157843pav.0.1349837821274; Tue, 09 Oct 2012 19:57:01 -0700 (PDT) Received: by 10.66.73.1 with SMTP id h1mr2157842pav.0.1349837821262; Tue, 09 Oct 2012 19:57:01 -0700 (PDT) Return-Path: Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by gmr-mx.google.com with ESMTPS id o10si24644pax.0.2012.10.09.19.57.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 19:57:01 -0700 (PDT) Received-SPF: pass (google.com: domain of lordma...@gmail.com designates 209.85.160.50 as permitted sender) client-ip=209.85.160.50; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of lordma...@gmail.com designates 209.85.160.50 as permitted sender) smtp.mail=lordma...@gmail.com; dkim=pass header...@gmail.com Received: by mail-pb0-f50.google.com with SMTP id md4so193672pbc.23 for ; Tue, 09 Oct 2012 19:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uo4aLbTJJH7p5U7d06AFgXyDK5xlPJA5eU0lhLpx6Ww=; b=JugvIv/7jvG0xvIz1WayzjvVXe6Ou8q6JWRxF6+U/dTD/JoCCeqlpBxo7RvaRjXPKZ MFxGg7tYJEd90vT5WgfI1IYCAJvEAT87RS7WClQmWWW4+9xMPbcAhz73bAAEEvTc4QgJ YTi56YLHGlTJkUbwEzSgQtOfOG1uBuq0A823bCRlw0wp1ZUkQGwJgIt4QBtBM9iGND75 ZvIEz6pbwjf5LBjk8AipUDfX5d84CPa6WH8AZUt0RoM0FXiv/gdIImCScsyIFcG1DlNj vh4EYSdE8flSuI3euxufElcYemP8cQGUnzAP08KAm+sjAjTRqNcQPm2QdyyEqPE+UdSm ACNQ== MIME-Version: 1.0 Received: by 10.68.217.67 with SMTP id ow3mr69635145pbc.26.1349837821079; Tue, 09 Oct 2012 19:57:01 -0700 (PDT) Received: by 10.68.58.65 with HTTP; Tue, 9 Oct 2012 19:57:00 -0700 (PDT) In-Reply-To: <9bceb77a-9ade-4e46-a41e-de1bca9a193d@googlegroups.com> References: <738311ce-09ce-4987-8472-578c9c23897e@googlegroups.com> <9bceb77a-9ade-4e46-a41e-de1bca9a193d@googlegroups.com> Date: Tue, 9 Oct 2012 22:57:00 -0400 Message-ID: Subject: Re: [nodejs] Re: Which database to use for a realtime chat game? From: Stewart Mckinney To: nodejs@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff246e1d471dc04cbab9b19 --e89a8ff246e1d471dc04cbab9b19 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > 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? > > > On Wednesday, October 10, 2012 3:45:33 AM UTC+4, Stewart McKinney wrote: > >> 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 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... >>> >>> >>> -- >>> 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 >>> >> >> -- > 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 nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > --e89a8ff246e1d471dc04cbab9b19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 a= sked, and then question the need for immediate "mirrored" status = present on disk or in distributed memory. Real-time feeds should be service= s in themselves, not glommed onto a database which has other things to worr= y about.

In other words, if you are expecting constant push updates f= rom the database itself, you are probably doing something "wrong"= . Not "Wrong", but "wrong". It crowds what a database i= s supposed to do. A good example of why it "crowds" is to ask you= rself why other databases that might be replicants or slaves would need tha= t 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 t= his way, a set of clients - would. Unless of course you are planning on eng= aging everyone at once - upwards of a million people, lets say - in which c= ase 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 a= re other ways to push and "store" that kind of information. You m= ight have to get a little creative, but hey, thats app development.

As a simpler example of how it could be done, I would s= uspect 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 alig= ned to each "room" or several rooms. It's entirely possible t= o 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 t= he servlet/client host had.=A0

On Tue, Oct 9, 2012 at = 9:17 PM, Alexey Petrushin <alexey.petrus...@gmail.com> wrote:
> Redis is fine too, an= d MongoDB is fine.
How to use MongoDB, seems there's no way t= o take an instant (sort of instant) feed of events?


On Wednesday, October 10, 2012 3:45:33 AM UTC+4, Stewart McKinney w= rote:
CouchD= B is fine, if you don't like its performance, use CouchBase.

Redis is fine too, and MongoDB is fine. IMHO Couch is easies= t, and its not hard to migrate from Couch to Mongo/Redis if you are still p= rototyping and prepping for scale.

Just don't use SQL to store a chat log.
<= br>
Content =3D noSQL
Numbers =3D 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=A0may = be something to look at. =A0It is an HTML5/JavaScript relational database t= hat has full support of SQL and provides the ability to store data in local= Storage or other manners.

Hope this helps,

john...


--
Job Board: http://job= s.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=3Den?hl=3Den

--
Job Board: http://job= s.nodejs.org/
Posting guidelines: https://github.com/joyent/node/w= iki/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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
= nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=3Den?hl=3Den

--e89a8ff246e1d471dc04cbab9b19--