Re: Compound Index or two Collections

[Aaron Heckmann]

The proposed schema is sharding on _id but also applying a unique index without using the shard key as a prefix. This will not work as expected because in a sharded environment, unique indexes are not enforced across shards: http://www.mongodb.org/display/DOCS/Sharding+Limits#ShardingLimits-UniqueIndexesDOCS%3AIndexes%23UniqueIndexes

As long as the shard key is a prefix of your unique index you'll be ok.

On Wednesday, September 5, 2012 8:08:46 AM UTC-7, max wrote:

Hi, I am creating a backend for a mobile app where we need to store device IDs for push notifications. Every device has only one push token, and that must be associated with only one user. We have IOS and Android push tokens. We may one day have others (Windows Phone?) but thats a very long way away. Although they both serve similar purposes, they might have different metadata associated with them (I don't know of anything specific, but maybe one will have an expiration date and another will have some other field). I'm using Mongoose. My first intuition was to implement like this:

    var DeviceId = new mongoose.Schema({                                                                                                                       
        token: String,
        userId: { type: ObjectId, index: true },
        type: { type: String, enum: ['ios', 'android'] }
    }, {
        shardKey: {
            _id: 1
        }
    });

    DeviceId.index({ token: 1, type: 1 }, { unique: true });

However, i'm wondering if that's overkill to have a compound index to ensure uniqueness. Maybe I should just have two collections, one for IOS and one for Android? Because maybe the 'schema' is different?

Any thoughts?

Thanks

[max]

What about if I remove the Shard Key. I don't think I'll have to shard this collection if its all on one node for a very very long time. Does it seem superfluous to use a compound index where the second thing can only be one of a very few (2 for now) values?

[Aaron Heckmann]

more collections increases application complexity vs one collection with compound unique index increases index size. I personally prefer less app complexity but it depends on your situation.