title: Which is better in MongoDB: multiple indexes or multiple collections
body: <p>I'm working on an application that authenticates users using 3rd party services (Facebook, Google, etc.). I give each user an internal id (uuid v4) which is associated with their 3rd party ids. Right now, my (mongoose) user document model looks something like this:</p>
  
  <pre><code>var user = new mongoose.Schema({
      uuid: {type: String, required: true, unique: true, index: true, alias: 'userId'},
      fbid: {type: String, required: false, index: true, alias: 'facebookId'},
      gid: {type: String, required: false, index: true, alias: 'googleId'}
  });
  </code></pre>
  
  <p>Because I can query on any IDs, I need indexes on all of them. I'm thinking that this can become an issue with a large amount of users (or if I add more 3rd party logins (Twitter, LinkedIn, etc.). Now, my question is whether this is the correct way to do this, or if there is a better solution.</p>
  
  <p>One idea I had is having multiple collections, one per ID type. Something like this:</p>
  
  <pre><code>var user = new mongoose.Schema({
      uuid: {type: String, required: true, unique: true, index: true, alias: 'userId'},
  });
  
  var facebookUser = new mongoose.Schema({
      fbid: {type: String, required: false, index: true, alias: 'facebookId'},
      userId: {type: Schema.Types.ObjectId, ref: 'user'}
  });
  </code></pre>
  
  <p>This has the advantage of not cluttering the user model and easier sharding, however it means more queries to retrieve a user and even more to create a new user (1. check in facebookUser collection if a user exists, if not, create a new user, save it, then create a new facebookUser with a link towards that new user and then save that).</p>
  
  <p>Which way is "better" (scales well, handles load, etc.)?</p>