Sharding avec mongodb. Méthode optimale pour écrire ma requête

Question

Laissez-moi essayer d'expliquer mon problème d'abord, puis la solution que j'applique. J'ai une collection d '"événements", qui peuvent être partagés avec des utilisateurs spécifiques. J'ai aussi une collection d '"utilisateurs". Tout utilisateur peut partager un événement avec un nombre quelconque d'autres utilisateurs. Lorsqu'un événement est partagé avec un utilisateur, il est vu sur la page d'accueil de mon site Web par cet utilisateur (disons qu'il est trié par date de création pour le rendre simple). Je veux utiliser le sharding pour équilibrer à la fois mes écritures et mes lectures, et être capable d'évoluer horizontalement si nécessaire. Avant de penser au sharding, j'avais une collection d'événements, qui contenait un éventail d'userIds. Ces userIds sont ceux qui peuvent voir l'événement. Ma requête était alors chaque événement où l'utilisateur connecté était contenu dans ce tableau, trié par date de création, en me limitant à la taille de ma page. Pour implémenter sharding dans ce scénario, le choix évident serait d'avoir en quelque sorte le userId comme clé shard, comme chaque événement retourné par ma requête a l'userId dans ce tableau incorporé. Cependant, mon userId est contenu dans un tableau, donc cela ne fonctionnerait pas. Je puis bien d'avoir une nouvelle collection, avec les champs suivants:

• userId: ObjectId (hashed touche tesson, pour éviter la monotonie)
• eventId: objectId
• creationDate: Date

De cette façon, je peux exécuter ma requête par userId, et la faire aller seulement à la partition correspondante. Mon problème bien sûr avec cette solution, est que j'ai maintenant eventIds au lieu d'événements, ce qui est un document assez gros donc je ne voudrais pas l'avoir redondant comme un document intégré dans cette collection (rappelez-vous que beaucoup d'utilisateurs peuvent être partagés un événement).

Pour résoudre ce problème, je pense que la solution correcte serait que l'événement soit la clé de partition de la collection d'événements (encore une fois, haché pour éviter la monotonie). Je peux ensuite interroger la collection d'événements par ces identifiants.

Cela soulève deux questions:

1. Est-ce la bonne façon de penser à ce problème particulier. Est-ce une bonne solution? Comme j'ai maintenant plusieurs eventIds, disons juste cinq, et chacun d'eux peut être situé dans un fragment différent, ce qui peut être plus performant: avoir une seule requête recherchant les cinq identifiants, ou avoir cinq requêtes différentes Vous cherchez un seul identifiant chacun?

Answer 1

1. Oui, c'est correct et la solution est correcte. Les utilisateurs sont partagés avec userId et les événements sont partagés avec eventId.
2. Un dernier. cinq requêtes différentes recherchant un identifiant unique, car la requête va alors à un fragment. Si vous avez une seule requête, ce qui ressemble à cinq identifiants en même temps ($ in: []), il se disperse probablement en plusieurs fragments.