In the previous recipe, we saw how to view some important statistics of a collection from an administrative perspective. In this recipe, we get an even higher picture, getting those (or most of those) statistics at the database level.
To find the stats of the database, we need to have a server up and running and a single node is what should be okay. Refer to the recipe Installing single node MongoDB in Chapter 1, Installing and Starting the Server for information on how to start the server. The data on which we would be operating needs to be imported in the database. The steps to import the data are given in the recipe Creating Test Data in Chapter 2, Command-line Operations and Indexes. Once these steps are completed, we are all set to go ahead with this recipe. Refer to the previous recipe if you need to see how to view stats at the collection level.
test
database for the purpose of this recipe. It already has a postalCodes
collection in it.27017
.$ mongo
> db.stats()
> db.stats(1024)
The scale
parameter, which is a parameter to the stats
function, divides the number of bytes with the given scale value. In this case, it is 1024
and hence all the values will be in KB. We analyze the following output:
> db.stats(1024) { "db" : "test", "collections" : 3, "objects" : 39738, "avgObjSize" : 143.32699179626553, "dataSize" : 5562, "storageSize" : 16388, "numExtents" : 8, "indexes" : 2, "indexSize" : 2243, "fileSize" : 196608, "nsSizeMB" : 16, "extentFreeList" : { "num" : 4, "totalSize" : 2696 }, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 }
The following table shows the meaning of the important fields:
Field |
Description |
---|---|
|
This is the name of the database whose stats are being viewed. |
|
This is the total number of collections in the database. |
|
This is the count of documents across all collections in the database. If we find the stats of a collection using |
|
This is simply the size in bytes of all the objects in all the collections in the database divided by the count of the documents across all the collections. This value is not affected by the scale provided, although this is a |
|
This is the total size of the data held across all the collections in the database. This value is affected by the scale provided. |
|
This is the total amount of storage allocated to collections in this database for storing documents. This value is affected by the scale provided. |
|
This is the count of all the number of extents in the database across all the collections. This is basically the number of extents (logical containers) in the collection stats for collections in this database. |
|
This is the sum of number of indexes across all collections in the database |
|
This is the size in bytes for all the indexes of all the collections in the database. This value is affected by the scale provided. |
|
This is a sum of the size of all the database files you should find on the filesystem for this database. The files would be named |
|
This is the size of the file in MB for the |
|
This is the number of free extends in freelist. You can look at extent as an internal data structure of MongoDB. |
|
Size of the extents on the freelist. |
For more information on these, you can refer to books such as Instant MongoDB by Packt Publishing (http://www.packtpub.com/big-data-and-business-inteliigence/instant-mongodb-instant).
Let's start by looking at the collections
field. If you look carefully at the number and execute the show collections command on the mongo shell, you will find one extra collection in the stats as compared to those by executing the command. The difference is for one collection, which is hidden. Its name is system.namespaces
collection. You may do a db.system.namespaces.find()
to view its contents.
Getting back to the output of stats operation on the database, the objects field in the result has an interesting value too. If we find the count of documents in the postalCodes
collection, we see it is 39732
. The count shown here is 39738
, which means there are six more documents. These six documents come from the system.namespaces
and system.indexes
collection. Executing a count query on these two collections will confirm it. Note that the test
database doesn't contain any other collection apart from postalCodes
. The figures would change if the database contains more collections with documents in it.
Another thing to note is the value of the avgObjectSize
and there is something weird in this value. Unlike this very field in the collection's stats, which is affected by the value of the scale provided, in database stats this value is always in bytes. This is pretty confusing and I am not really sure why this is not scaled according to the provided scale.