I&#39;m trying to determine the best way to deal with a composite primary key in a mongo db. The main key for interacting with the data in this system is made up of 2 uuids. The combination of uuids is guaranteed to be unique, but neither of the individual uuids is.

I see a couple of ways of managing this:

 1. Use an object for the primary key that is made up of 2 values (as suggested [here][1])

 2. Use a standard auto-generated mongo object id as the primary key, store my key in two separate fields, and then create a composite index on those two fields

 3. Make the primary key a hash of the 2 uuids

 4. Some other awesome solution that I currently am unaware of

What are the performance implications of these approaches? 

For option 1, I&#39;m worried about the insert performance due to having non sequential keys. I know this can kill traditional RDBMS systems and I&#39;ve seen indications that this could be true in MongoDB as well.

For option 2, it seems a little odd to have a primary key that would never be used by the system. Also, it seems that query performance might not be as good as in option 1. In a traditional RDBMS a clustered index gives the best query results. How relevant is this in MongoDB?

For option 3, this would create one single id field, but again it wouldn&#39;t be sequential when inserting. Are there any other pros/cons to this approach?

For option 4, well... what is option 4?

Also, there&#39;s some discussion of possibly using CouchDB instead of MongoDB at some point in the future. Would using CouchDB suggest a different solution?

**MORE INFO:** some background about the problem can be found [here][2]


  [1]: https://stackoverflow.com/a/7225657/13181
  [2]: https://softwareengineering.stackexchange.com/questions/236309/strategy-for-generating-unique-and-secure-identifiers-for-use-in-a-sometimes-of

All Primary Key-Design Solutions on Gang of Coders

Total of 1 Primary Key-Design Solutions

MongoDB and composite primary keys