2011-01-09 5 views
4

Je reconstruis Lovers on Facebook avec Sinatra & Redis. J'aime Redis parce qu'il n'a pas le long (12 octets) BSON ObjectIds et je stocke des ensembles de user_ids Facebook pour chaque utilisateur. Les ensembles sont des requêtes requests_sent, requests_received, &, et ils contiennent tous des identifiants d'utilisateur Facebook.Facebook user_id comme MongoDB BSON ObjectId?

Je pense passer à MongoDB parce que je veux utiliser son indexation géospatiale. Si c'est le cas, je voudrais utiliser les ID utilisateur FB comme champ _id car je veux que les ensembles soient petits et que les réponses JSON soient petites. Mais, BSON ObjectId est-il préférable (plus efficace pour MongoDB) d'utiliser qu'un entier (fb user_id)?

+0

essayé de demander sur les forums mongo ainsi ?. –

+0

Je suis dans une situation similaire. J'ai un très grand nombre de documents minuscules avec plusieurs index et une charge d'insertion/upsert lourde. J'essaie actuellement de réduire la taille des index pour améliorer les performances, et (avant de faire les expériences), je me demande si je suis sur le bon chemin ... –

Répondre

2

Il n'y a pas de grandes différences d'efficacité pour autant que je sache sauf dans certains cas, comme la commande par date (depuis les années ObjectId ont le datetime en eux, etc.)

Par exemple, vous perdriez la possibilité de simplement commander par le _id vous perdrait également les avantages pour sharding and distribution. Mis à part cela, tandis que je serais encore personnellement utiliser les ObjectId de toute façon ... tant que le int est unquie (bien sûr) ... vous devriez être très bien.

Depuis le _id toujours « revient » dans une requête, je suppose que vous économiseriez un peu de temps et le transfert de données (un peu Bitty.)

Vous pouvez même faire votre _id un tableau si vous vouliez, et il va tout indice bien voir ce answer (pas que je recommande nécessairement que la plupart du temps.)

voir aussi: Optimizing Object IDs

Questions connexes