Licesning and distribution

[GATO]

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.

[jm]

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.

[Max Schireson]

I'd do some testing to look at performance it will depend on a lot of things.

No problem whatsoever with distributing mongo.

Standard I-am-not-a-lawyer-disclaimer.

-- Max

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mongodb-user/-/W2xsx2QdumIJ.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.

[GATO]

It'll already be a java app - probably not too efficient on memory anyway. What sort of crash issues might there be? I was thinking of only using it to commit saves to memory and load them. saves in this case are world data - generated world information along with player data. BSON is easy to come up with an effective, comprehensible storage plan.

[Sam Millman]

Tbh the only problem would be mobile (since there is no mobile version), if your running on desktop you can expect your users to house the ram needed (most top games require 2GB ram at least) to run a small Mongo instance and even though Mongo is aggresive with disk allocation its not over the top.

You can also use BSON directly without Mongo is you wanted to stop Mongo Memory usage and Disk Allocation.

That being said jm has a point with 32bit versions, your game could be housed on a 32bit computer which would be a bummer.

On 28 April 2012 12:42, GATO <incorr...@gmail.com> wrote:

It'll already be a java app - probably not too efficient on memory anyway. What sort of crash issues might there be? I was thinking of only using it to commit saves to memory and load them. saves in this case are world data - generated world information along with player data. BSON is easy to come up with an effective, comprehensible storage plan.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/hab8yulLmDMJ.

[GATO]

Yeah, well, the **client** would not necessarily have to reside on the same computer where Mongo was - let's say that if the game was being run standalone it would definitely be being run on a PC (Linux or Windows) and the player could have everything running there on the same box, but in the case of mobile or webgl based versions the simulator - what ultimately serves and handles the world data - would have to be housed somewhere else. But in such cases - mobile and webgl anyway - the client would be like a dumb terminal type thing anyway even without mongo. Getting the desired level of performance would demand it!

What is so limiting about 32-bit mongo that I might need to know about for my usage?

[jm]

There are some storage size limits with 32bit systems. Approximately
2GB, but this includes the overhead, so the actual data you can safely
store is, I don't know, it depends. --smallfiles might help with that.
Also, journaling is by default disabled on 32bit.. if you want to
enable it (probably you want to minimize any issues with unclean
shutdowns/crashes), it will increase the overhead which I think means
even less storage. Sure this might not be an issue if you only store
small amounts.

http://www.mongodb.org/display/DOCS/FAQ#FAQ-Whatarethe32bitlimitations%3F

If you don't need any advanced querying and stuff, using some BSON
libraries sounds good. If your app only needs to occasionally load and
save a specific savefile to memory/disk, I would definitely go for the
filesystem.. the format could be BSON or, whatever works best. I have
no experience on using BSON without mongo, but I believe it'll work
well.

If you want to query/update the "savefiles" on the fly (use it like a
database), dynamically load some world data etc. and if you are OK
with the overhead, and you know you store less than, say, 1GB on 32bit
systems, a mongo instance might be a nice option. Then again, if your
dataset is less than, say, 100-200MB, you might be better off just
keeping it in RAM in some Java structure, no need for mongo server.

[GATO]

It can't stay in RAM. while the raw data will not be excessively large, because of the complexity of the world (modifiable, has simulation events independent of player interaction) a 10mb save might expand 10 times in RAM. Plus, the max possible size of worlds - we theoretically limit this to something like 256km by 256km just for sanity and reasonability's sake and multiworld transitions require each session to have its own data storage that must be able to be fluidly loaded and unloaded and saved. In short, the standard I've created which limits the terrain's contribution to memory usage and computation requires a certain slice be in memory at a time and that it will be constant in size. This way as more world is generated it does not increase memory load, nor do we have to rely on on-the-fly frame by frame calculation for potentially millions of values.

But the 2GB size suggests an individual database for each session - which contains up to seven worlds plus player data. The first five worlds will be truly expansive in data usage, but the last two will be fairly limited. And this itself is limited by the fact that only the first two worlds can really reasonably ever get anywhere near the 256x256 limit.