This time I would like to share with you several insider tips that can be used to better understand mongoDB and its internals.
No, mongoDB does not support it
(very similar to SQL Server before adjusting the memory
memory and resident sizes may appear
to be very large for the mongod process. This is by design: virtual
memory space should be just larger than the size of the data files open
and mapped. Resident
size will vary depending on the amount of memory not used by other
the machine. Yes, if you allocate more memory to the machine, mongoDB
will happily consume it,
mongoDB defines its storage size. You can compact
Mongo tends to preallocate a significant size
If your data store is too large you may use the
following commands to reduce it:
When ext3 is used and mongoDB allocates new
data files, these files have to be filled with zeroes that are written back to the
underlying disk (yes, extra unneeded writes to disk).
When ext4 or xfs are used, mongoDB
uses the falloc syscall that marks the file as allocated and zeroed, without actually writing
anything back to the underlying storage. The result is a better insert
performance on ext4 than ext3.
Quorum is for voting, data replication is async
Unlike Cassandra, mongoDB uses Quorum only for
primary server selection. Write is done only to primary server and answer is returned to the client immediately. The secondary servers
(or some will say the slaves) copy the data in async way.
Synchronous replication is possible but not recommended: Query response to user can be delayed to
ensure that data was replicated to slaves. However it may result with 2 orders of
magnitude performance decrease:
mongoDB stores data as BSON and communicates in
BSON or JSON? This is not a question anymore, as
mongoDB these days automatically serialize the JSONs into BSONs to save space
Now that you better understand the mongoDB architecture, it is time to make more out of it,
Published at DZone with permission of
, DZone MVB
Opinions expressed by DZone contributors are their own.