Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Can someone help me compare these queries and explain why the PostgreSQL query executes in just under 2000ms and the MongoDB aggregate query takes almost 9000ms and sometimes as high as 130K ms?

PostgreSQL 9.3.2 on x86_64-apple-darwin, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00), 64-bit

PostgreSQL query

SELECT locomotive_id,
   SUM(date_trunc('second', datetime) - date_trunc('second', prevDatetime)) AS utilization_time

FROM bpkdmp 
WHERE datetime >= '2013-7-26 00:00:00.0000' 
AND   datetime <= '2013-7-26 23:59:59.9999'
GROUP BY locomotive_id
order by locomotive_id

MongoDB Query

db.bpkdmp.aggregate([
   {
      $match : {
          datetime : { $gte : new Date(2013,6,26, 0, 0, 0, 0), $lt : new Date(2013,6,26, 23, 59, 59, 9999) }
   }
   },
   {
      $project: {
         locomotive_id : "$locomotive_id",
         loco_time : { $subtract : ["$datetime", "$prevdatetime"] }, 
      }
   },
   {
      $group : {
         _id : "$locomotive_id",
         utilization_time : { $sum : "$loco_time" }
      }
   },
   {
      $sort : {_id : 1}
   }
])

Both the PostgreSQL table and the MongoDB collection are indexed on datetime : 1 and locomotive_id : 1

These queries are being testing on an iMac with a 2TB hybrid drive and 16GB of memory. I have received comparable results on a Windows 7 machine with 8GB of memory and a 256GB SSD.

Thanks!

** Update : I am posting the EXPLAIN (BUFFERS, ANALYZE) results after my question was posted

"Sort  (cost=146036.84..146036.88 rows=19 width=24) (actual time=2182.443..2182.457 rows=152 loops=1)"
"  Sort Key: locomotive_id"
"  Sort Method: quicksort  Memory: 36kB"
"  Buffers: shared hit=13095"
"  ->  HashAggregate  (cost=146036.24..146036.43 rows=19 width=24) (actual time=2182.144..2182.360 rows=152 loops=1)"
"        Buffers: shared hit=13095"
"        ->  Bitmap Heap Scan on bpkdmp  (cost=12393.84..138736.97 rows=583942 width=24) (actual time=130.409..241.087 rows=559529 loops=1)"
"              Recheck Cond: ((datetime >= '2013-07-26 00:00:00'::timestamp without time zone) AND (datetime <= '2013-07-26 23:59:59.9999'::timestamp without time zone))"
"              Buffers: shared hit=13095"
"              ->  Bitmap Index Scan on bpkdmp_datetime_ix  (cost=0.00..12247.85 rows=583942 width=0) (actual time=127.707..127.707 rows=559529 loops=1)"
"                    Index Cond: ((datetime >= '2013-07-26 00:00:00'::timestamp without time zone) AND (datetime <= '2013-07-26 23:59:59.9999'::timestamp without time zone))"
"                    Buffers: shared hit=1531"
"Total runtime: 2182.620 ms"

** Update : Mongo explain:

Explain from MongoDB

{
"serverPipeline" : [
    {
        "query" : {
            "datetime" : {
                "$gte" : ISODate("2013-07-26T04:00:00Z"),
                "$lt" : ISODate("2013-07-27T04:00:08.999Z")
            }
        },
        "projection" : {
            "datetime" : 1,
            "locomotive_id" : 1,
            "prevdatetime" : 1,
            "_id" : 1
        },
        "cursor" : {
            "cursor" : "BtreeCursor datetime_1",
            "isMultiKey" : false,
            "n" : 559572,
            "nscannedObjects" : 559572,
            "nscanned" : 559572,
            "nscannedObjectsAllPlans" : 559572,
            "nscannedAllPlans" : 559572,
            "scanAndOrder" : false,
            "indexOnly" : false,
            "nYields" : 1,
            "nChunkSkips" : 0,
            "millis" : 988,
            "indexBounds" : {
                "datetime" : [
                    [
                        ISODate("2013-07-26T04:00:00Z"),
                        ISODate("2013-07-27T04:00:08.999Z")
                    ]
                ]
            },
            "allPlans" : [
                {
                    "cursor" : "BtreeCursor datetime_1",
                    "n" : 559572,
                    "nscannedObjects" : 559572,
                    "nscanned" : 559572,
                    "indexBounds" : {
                        "datetime" : [
                            [
                                ISODate("2013-07-26T04:00:00Z"),
                                ISODate("2013-07-27T04:00:08.999Z")
                            ]
                        ]
                    }
                }
            ],
            "oldPlan" : {
                "cursor" : "BtreeCursor datetime_1",
                "indexBounds" : {
                    "datetime" : [
                        [
                            ISODate("2013-07-26T04:00:00Z"),
                            ISODate("2013-07-27T04:00:08.999Z")
                        ]
                    ]
                }
            },
            "server" : "Michaels-iMac.local:27017"
        }
    },
    {
        "$project" : {
            "locomotive_id" : "$locomotive_id",
            "loco_time" : {
                "$subtract" : [
                    "$datetime",
                    "$prevdatetime"
                ]
            }
        }
    },
    {
        "$group" : {
            "_id" : "$locomotive_id",
            "utilization_time" : {
                "$sum" : "$loco_time"
            }
        }
    },
    {
        "$sort" : {
            "sortKey" : {
                "_id" : 1
            }
        }
    }
],
"ok" : 1
}
share|improve this question

migrated from stackoverflow.com Jan 24 at 7:14

This question came from our site for professional and enthusiast programmers.

1  
For the PostgreSQL query show EXPLAIN (BUFFERS, ANALYZE) output please. Also, PostgreSQL version. (I've voted to move this to dba.SE) –  Craig Ringer Jan 24 at 2:10
    
... and info on the MongoDB plan? docs.mongodb.org/manual/reference/method/cursor.explain –  Craig Ringer Jan 24 at 7:55
2  
Although it is hard to escape the NoSQL hype, traditional RDBMS are better and far more mature in aggregates any day. NoSQL databases are optimised for primary key indexing and retrieval by key and not for those kind of queries. –  Alexandros Jan 24 at 15:26
    
I may have left out a slight detail. There are over 200 fields in each document. This was a direct import from a PostgreSQL database. A lot of the field values are null. I recalled MongoDB not being particularly fond of null values. I did another import with < 20 fields of relevant data and the query performance is magnitudes better. I'm getting < 3000ms on a machine with 8GB of memory and a slower HD. I am going to begin a new test on a much more powerful machine shortly. –  Mike A Jan 24 at 20:27
    
Mongodb index {datetime: 1, prevdatetime: 1} should perform better than current index, since mongodb filters on datetime and prevdatetime. It would decrease the number of documents that need to be scanned. –  rubish Jun 8 at 3:18

1 Answer 1

All PostgreSQL is doing here is a bitmap heap scan on bpkdmp_datetime_ix to find blocks that might contain matching rows, then a heap scan of those blocks to find matching rows in bpkdmp. It then groups the rows into hash buckets using hashes of the grouping key, sums each bucket, and sorts the results. It's a simple, basic query plan - it might perform better if you throw lots of work_mem at it, but it might not, too.

There's no parallelism anywhere in that query, either; it'll all happen on one core.

I can only assume that MongoDB is using a less efficient method, or is not benefiting from an appropriate index. You'd need to show the explain for the MongoDB query for a useful comment there to be possible; see cursor.explain.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.