Unfortunately Mongo is not a very good choice for "embedded" DB. It
can be quite resource and storage size intensive, and I would not like
any random app/game to have their own instance of mongo running on my
machine. It's really better for dedicated DB servers. Also issues like
the limits on 32bit machines, starting and stopping mongodb alongside
your app, removing locks/doing repairs after crash etc. Would advice
against that. SQLite might be better option.
I vaguely remember that there has been some talk about alternative
storage engines for MongoDB. I would give my vote to an alternative,
non-memory-mapped storage that wouldn't mind the 32bit issue, and had
less memory and disk overhead. The performance wouldn't matter so much
as I imagine that could be used mostly as dev environment, or as
storage backend in single-user apps, those kinds of things.
On Apr 27, 5:10 pm, GATO <incorrigib...@gmail.com> wrote:
> Here's a quick question for you mongodb'ers.
> Say I wish to use Mongo as a database for a game - so instead of commiting
> saves and map information to disk, we commit them to mongodb - how feasible
> is this?
> 1. Would the performance be worse than the filesystem in general?
> 2. Would there be severe issues with distributing a version of mongodb -
> note, NOT just the drivers, we do not provide an online play service - but
> also the db itself to each game user and installing it?
> What is attractive is the BSON format, which is easy to understand. It
> would promote easier debugging of saved information, and easier
> modification the game by users.