{"id":34,"date":"2011-02-28T12:44:00","date_gmt":"2011-02-28T12:44:00","guid":{"rendered":"http:\/\/localhost:10265\/?p=33"},"modified":"2011-08-16T00:10:52","modified_gmt":"2011-08-16T00:10:52","slug":"an-introduction-to-mongodb","status":"publish","type":"post","link":"https:\/\/mehdi.biz\/blog\/2011\/02\/28\/an-introduction-to-mongodb\/","title":{"rendered":"An introduction to MongoDB"},"content":{"rendered":"

\"MongoDB10 years ago we have had no social network service in such a scale we used to see these days. Facebook<\/a>, for instance, has got more than 600 million active users who modify their personal profiles, exchange messages, play games and the like every single day. Consider the total committed transactions per second caused by these interactions. Clearly, things have changed and, hence, we need to deal with those changes as well. We actually need something that accommodates itself to such huge volume of data requirements.<\/p>\n

Do relational databases handle such use cases in a graceful manner?<\/h4>\n

The answer is yes, they do. However, the problem is actually scaling!<\/p>\n

When a web application becomes popular and the usage goes up, the requests start queuing up, because of those locks that have been placed on different portions of the database. This means that user B has to wait for user\u2019s A request to be processed. Under very heavy load, this becomes a bottleneck.<\/p>\n

Such problems are usually addressed by “vertical scaling”, say, adding more memory to the hardware, replacing the current CPU with a faster one and so force. This might accommodate the current growth for a while but you\u2019ll be faced with those conditions all over again.<\/p>\n

Soon enough, you\u2019ll notice that your hardware doesn\u2019t support more than a given total amount of CPUs\/RAMs whilst you have incorporated the best hard disc options available out there. So, naturally, you\u2019ll set up the next server in a database cluster. This, however, introduces a new problem: dealing with data replication and consistency.<\/p>\n

Now you need to make sure that data is consistent during the application operations, both under normal and failover conditions.<\/p>\n

At the same time, you probably modify the database design and de-normalize some tables, tune some indexes and etc. This, however, could introduce new problems and new unwanted changes in the application layer.<\/p>\n

Don\u2019t get me wrong!<\/h4>\n

I do not say that such huge-scaled web scenarios cannot be handled by traditional database models (and in particular, the relational model) that have been around for decades.<\/p>\n

However, the point is to understand that the relational model is simply a model. That is, it\u2019s useful to handle certain problem domains. This certainly doesn\u2019t close the case on other ways of representing data.<\/p>\n

I\u2019ve seen a couple of articles\/video<\/a>s lately about “NoSQL vs. SQL” that seemed to have caught a lot of attention. Some people tend to say schema-free dbs are a mess<\/a> or why NoSQL dbs are so great over relational ones<\/a>! This, however, doesn\u2019t actually stand true. “SQL and NoSQL” dbs are not against each other.<\/p>\n

What is MongoDB?<\/h4>\n

MongoDB (from “humongo<\/b>us”) is a scalable, high-performance, open source, document-oriented, schema-free database storage engine written in C++.<\/p>\n

It uses a lightweight binary format, called BSON (Binary JSON) to read\/write documents (an ordered set of keys with associative values) that is roughly equivalent to a row in an RDBMS. These documents can be grouped into a schema-free set called a collection. Theses collection can be further divided conventionally into namespaces that is nothing more than different collections separated by a period.<\/p>\n

MongoDB uses memory-mapped files<\/a> to store\/retrieve data. Once a file has been memory-mapped, the content could be accessed by dereferencing a pointer. This way, it pushes most of its memory management job to the OS which results in a much cleaner (and safer) code in MongoDB (it has several benefits; however, it\u2019s out of the scope of this article). The philosophy<\/a> behind it states that whenever possible, the engine has to offload processing and logic to the client side.<\/p>\n

Each database consists of different files named .0, .1, and so forth. The first one is pre-allocated into 64MB (prefilled with zero bytes); the second one doubles this size, say, 128MB and etc up to the maximum file size of 2GB. Once this happens, each successive file will be also 2GB. This prevents file system fragmentation and provides a non-blocking mechanism to handle requests when the need for extract space arises.<\/p>\n

MongoDB uses a lightweight TCP\/IP wire protocol to expose it\u2019s functionality to client-side programs (including drivers<\/a>). It uses TCP port 27017 (by default) to listen to the connections and exposes some of its administrative features on port 28017.<\/p>\n

Getting Started<\/h4>\n

MongoDB can be installed on Solaris, OS X<\/a>, Linux<\/a> and Windows (32bit\/64bit). This paper, however, will focus on installing MongoDB on Microsoft Windows. You can consult this page<\/a> for additional information on how to get MongoDB up and running on other operating systems.<\/p>\n

Installing MongoDB on Microsoft Windows<\/h4>\n

Follow this URL<\/a> and download the latest “Production Release” that\u2019s suitable for your version of Windows (32bit\/64bit). At the time of this writing, the latest production release of MongoDB is 1.6.5 which can be downloaded using one the following links:<\/p>\n