addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupsimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1outlookpersonJoin Group on CardStartprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Denver MongoDB User Group Message Board › I Put Together A List Of Some Of The Top Issues With Mongodb

I Put Together A List Of Some Of The Top Issues With Mongodb

Brian C.
user 9099397
Denver, CO
Post #: 1
I am going to spam my blog here I hope that is ok... I've been working with mongodb since 2009 and I recently wrote a blog article about some top design concerns every one from operations to development should be aware of.


A former member
Post #: 10
That's okay. Thanks! I'll be sure to read through it.
A former member
Post #: 9
Thanks, here are a few things I've learned and had to be aware of from my own experience:

* When using multiple databases, yes - there will be separate files created. However, if you HAVE to do this - the '--smallfiles' option really helps to save disk space. This grows files by a 1/4 the size and can help depending on your situation. The max file size will now be 512MB vs. the default 2GB. So the growth penalty is much less. Additionally, enabling '--directoryperdb' makes life easier as you can contain all the files under /data in their own directories.
'--smallfiles' really helped/affected our data file size growth predictions.

* Knowing that compaction may be necessary - but if your application doesn't delete much (e.g. only appending data and doing in-place updates) then you shouldn't need to worry too much about this. Of course, you should till have monitoring in place, etc...

* Knowing that compaction is really a 'defrag' of the data inside the database files AND actual disk space on the filesystem in NOT relinquished. There is quite a bit of confusion on the Mongo forums about this - not very clear at first. If the desire is to reclaim disk space one must use the repairDatabase operation to rebuild the database files for a particular database - knowing full well that it (currently) is a blocking operation.


I'm glad you called out document padding, and how Mongo tries to take a smart stab at predicting the next data size of a particular document. When I first learned of this - I was afraid that this could really negatively impact say a subset of data within a database if some other subset of data is being written heavily too and is skewing the data size growth prediction algorithm that Mongo uses. Good thing it is on a collection level.

Additionally, write concern is another hot topic - at least for me. I would agree that one has to be really careful and understand what developers are intending to do w/ this option. If the company agrees to use stricter consistency than yes - Operations really really needs to know how to maintain the MongoDB servers as to avoid write failure at the application layer - as they already should :)

Powered by mvnForum

Our Sponsors

  • MongoDB

    MongoDB supports the Denver MUG

  • SlamData

    Open source project for MongoDB visual analytics.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy