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
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
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.
On Apr 28, 4:29 pm, GATO <incorrigib...@gmail.com> wrote:
> 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?