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?
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?
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?
> 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?
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.
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.
On Tue, Oct 9, 2012 at 5:00 PM, John Fowler <john.fowle...@gmail.com> wrote:
> 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.
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 <john.f...@gmail.com<javascript:> > > wrote:
>> 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.
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
> 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 <john.f...@gmail.com> wrote:
>>> 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.
<alexey.petrus...@gmail.com> 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 <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.
