In the previous recipe, we saw how to view some important statistics of a collection from an administrative perspective. In this recipe, we'll get an even clearer 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 should be ok. Refer to the Single node installation of MongoDB recipe in Chapter 1, Installing and Starting the MongoDB Server, for how to start the server. The data on which we would be operating needs to be imported into the database. The steps to import the data are given in the Creating test data recipe 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, Viewing collection stats, if you need to see how to view stats at the collection level.
We will be using the test database for the purpose of this recipe. It already has the postalCodes collection in it. Let's take a look at the steps in detail:
- Connect to the server using the Mongo shell by typing in the following command from the operating system terminal (it is assumed that the server is listening to port
27017):$ mongo - On the shell, execute the following command and observe the output:
> db.stats() - Now, execute the following command, but this time with the scale parameter (observe the 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, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 }
Let us start by looking at the collections field. If you look carefully at the number and also execute the show collections command on the Mongo shell, you will find one extra collection in the stats as compared to those achieved by executing the command. The difference is denotes one collection, which is hidden, and its name is system.namespaces. You may execute 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 that 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 will change if the database contains more collections with documents in it.
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. Let's analyze the 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, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 }
The following table shows the meaning of the important fields:
Another thing to note is the value of 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, which is pretty confusing and one cannot really be sure why this is not scaled according to the provided scale.
- Instant MongoDB, Packt Publishing (https://www.packtpub.com/big-data-and-business-intelligence/instant-mongodb-instant)