MongoDB indexing

Question

We have a MongoDB collection containing nearly 40 million records. The current size of the collection is 5GB. The data stored in this collection contains following fields:

_id: "MongoDB id"
userid: "user id" (int)
mobile: "users mobile number" (int)
transaction: "transaction id" (int)
sms: "message sent to user mobile" (text)
created_dt: "unix timestamp of the transaction"

Apart from the index on _id (created by default), we have defined separate indexes on the mobile and transaction fields.

However, the following query takes anywhere between 60 to 120 seconds to complete:

{
    mobile:<users mobile number>
}

I access MongoDB using RockMongo. MongoDB is hosted on a server with 16GB RAM. Nearly 8GB RAM on this server is free.

What is it that I am doing wrong here?

Update:

Output of explain:

{
    "cursor" : "BasicCursor",
    "nscanned" : 37145516,
    "nscannedObjects" : 37145516,
    "n" : 37145516,
    "millis" : 296040,
    "nYields" : 1343,
    "nChunkSkips" : 0,
    "isMultiKey" : false,
    "indexOnly" : false,
    "indexBounds" : {
    }
}

Output of mongostat at the time of the query

insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
    13      2      0      0       0       1       0   168g   336g  6.86g      1        1          0       0|0     1|0    21k     1k    19   11:30:04 
    16      0      0      0       0       1       0   168g   336g  6.88g      0      0.1          0       0|0     1|0    21k     1k    19   11:30:05 
    14      0      0      0       0       1       0   168g   336g  6.86g      0        0          0       0|0     1|0    29k     1k    19   11:30:06 
    10      0      0      0       0       1       0   168g   336g  6.86g      0        0          0       0|0     1|0    19k     1k    19   11:30:07 
    16      0      0      0       0       1       0   168g   336g  6.88g      0      0.1          0       0|0     1|0    21k     1k    19   11:30:08 
     9      0      0      0       0       1       0   168g   336g  6.89g      0        0          0       0|0     1|0    13k     1k    19   11:30:09 
    19      0      0      0       0       1       0   168g   336g  6.89g      0        0          0       0|0     1|0    27k     1k    19   11:30:10 
    12      0      0      0       0       1       0   168g   336g  6.89g      1      1.2          0       0|0     1|0    24k     1k    19   11:30:11 
    17      0      0      0       0       1       0   168g   336g  6.89g      1      1.7          0       0|0     1|0    31k     1k    19   11:30:12 
    15      0      0      0       0       1       0   168g   336g  6.89g      0        0          0       0|0     1|0    19k     1k    19   11:30:13 

Update 2:

Until recently, we used to store another collection with about 1.3 billion documents in the same MongoDB server. This collection has now been removed (dropped). This may explain the mapped / vsize column in above output from mongostat.

The server also stores 6 other collections which have frequent inserts. The total storage size currently is about 35GB.

Update 3:

Indexes defined on the collection. Created using RockMongo.

[
{
    "v" : 1,
    "key" : {
        "_id" : 1
    },
    "ns" : "mymongodb.transaction_sms_details",
    "name" : "_id_"
},
{
    "v" : 1,
    "key" : {
        "_transaction_mobile_" : 1
    },
    "ns" : "mymongodb.transaction_sms_details",
    "background" : 1,
    "name" : "mobile"
},
{
    "v" : 1,
    "key" : {
        "_transaction_transaction_" : 1
    },
    "ns" : "mymongodb.transaction_sms_details",
    "background" : 1,
    "name" : "transaction"
}
]

Answer 1

The keys generated by RockMongo is apparently incorrect.

    "_transaction_mobile_" : 1
    "_transaction_transtion_" : 1

I don't know what's wrong with RockMongo, but I think this can fix the issue:

db.xxx.dropIndexes();
db.xxx.ensureIndex({mobile: 1});
db.xxx.ensureIndex({transaction: 1});

Notice: This may take VERY LONG time. Don't do this on a running production machine.