Why? Because it’s always interesting to watch Ryan talking about Node.js

Pretty interesting graph extracted from Presentation: Scale at Facebook

I knew PHP has pretty huge performance overhead but boy, just look at Ruby and even Python!

But I am not so sure that Python’s performance cost is as equal to PHP because Python has the ability to generate compiled files also which certainly boost performance.

I just learned something hard way today.

I have a collection, lets call it foo_collection. The data format of that collection is something like this:

{
	file: "filename1",
	started: "Sat Feb 20 2010 04:15:02 GMT-0500 (EST)",
	ended: "Sat Feb 20 2010 04:15:04 GMT-0500 (EST)"
}

Initially, the key “file” is used as normal index

db.ensureIndex({file: 1});

Later on, I had to change the index from normal to unique. So, I did:

db.ensureIndex({file: 1}, {unique: true});

This didn’t work because, the collection already contained multiple similar values of file key. And MongoDB console also doesn’t show any error or any message when the above command is run.

It should have been:

db.ensureIndex({file: 1}, {unique: true, dropDups: true});

Again, it  should be noted that the above command will delete all the duplicate entries with the indexed key. So, use with caution.

I know this was kind of childish mistake but wanted to share so, someone reading this post won’t repeat it again.

Update: You can also check if db.ensureIndex() is working or not by calling db.getLastError() and you can also do the same from driver level by setting “safe” option. (Credit: Kristina)

The number of “notes” count and actual notes items are inconsistent in the above screenshot.

This is a typical example where caching really does not work. Facebook likes, Tumblr notes count and article listing in Hacker News are few examples where in memory database is more useful than DB caching.

I have been using MongoDB for few months. It is one of the arrays of open source NoSQL solutions available. The way MongoDB including CouchDB stores data in JSON format as a document (It’s called BSON, Binary JSON in MongoDB). A document is a loosely typed data format as compared to strictly typed in SQL based systems. You can find more detail information about document data format here.  In MongoDB, all those documents are contained in a collection which acts as a bucket for those documents. So, a collection “contact_info” may be formatted as:

{
    "_id": "Prajwal Tuladhar"
    "street": "3478 78 ST",
    "zip": 11378,
    "email": "praj@prajwal-tuladhar.net.np",
    "phone": {
        "home": "64622251452"
    }
}

{
    "_id": "Max Payne"
    "street": "17th Floor 225 Park Avenue",
    "zip": 10001,
    "phone": {
        "mobile": "7182524423",
        "office": "2127783264"
    },
    "fax": "1.913.384.6577"
}

So these two documents are contained in a collection called “contact_info”. _id is a mandatory field in MongoDB while others are user defined. As you can see, documents are self-containded and their structure is slighly different from each other. This is one of the main advantages of using document based systems. One can define rich data structure without sacrificing SQL like features with option to query them in number of ways.

If you look at the above two documents, field “phone” is an example of embedded document. Other examples may be:

db.students
=======

{
    "_id": "Jane",
    "address": {
        "address": "123 Main St",
        "city": "New York",
        "zip": 10011
    },
    "scores": [
        {
            "subject": "Biology",
            "grade": 4.00
        },
        {
            "subject": "Physics",
            "grade": 3.50
        }
    ]
}

While designing schemas for MongoDB, one of the issues I have faced for sometime is: when to use embedded document.

Here are some of the excerpts about embedded documents from MongoDB docs:

Line item detail objects typically are embedded.

Objects which follow an object modelling “contains” relationship should generally be embedded.

I think one key point is missing here. The document should be embedded or used as a reference depending on the context of the domain. If the document can be expressed as domain model then, it should be declared as first class document while optionally expressing their relationship as reference or it can be also done from application level rather than DB level (Just imagine table relationship for MySQL ISAM). So, in the above examples, if the scores can be expressed as domain object (which depends on the context of the application), it should not be used as embedded document.

And from database point of view also, embedded documents are hard to update / manipulate while they are loaded in advance which can be problematic from performance point of view when size is freaking high. There is no concept of lazy loading in the form of cursor object for embedded documents so, one should acknowledge that large embedded documents may lead to bad design and the maximum size of the MongoDB document is 4 MB,