2016-08-22 1 views
0

Je cherche dans sharding en utilisant mongodb, et la plupart si c'est plutôt simple. J'ai de l'expérience avec le sharding dans d'autres bases de données, donc je ne pose pas de questions sur le concept lui-même. Il y a une chose que je suis confus, et il ne semble y avoir rien dans la documentation à ce sujet, alors voilà.Unicité de _id à l'intérieur d'une partition

Est-ce que _id doit être unique dans la partition, quelle que soit la clé de partition?

Un test à petite échelle (fragment simple) semble confirmer que c'est le cas. Il semble toutefois que ce soit une approche moins que stellaire de la sharding, ce qui me rend confus. Pour moi, il serait plus logique d'exiger que shard-key + _id soit unique (c'est-à-dire d'utiliser une clé composée), ou vous aurez un comportement incohérent en fonction de l'endroit où vos clés de fragmentation finissent par être routées. Mon modèle de données utilise des clés déterministes et la clé shard en fait partie intrinsèque. Donc, je suppose que cela revient à, ai-je fait quelque chose de mal dans mon test à petite échelle? Ai-je besoin de stocker la clé de partition deux fois, une fois comme un champ de clé de partition et une fois dans le cadre de _id? Ou y at-il un cas particulier où je peux en quelque sorte déclarer une clé composée en utilisant shard-key et _id?

Mise à jour

Pour être complet, c'est le cas trivial je teste, en insérant les deux documents suivants:

{"_id": 1, "shardkey": 1} 
{"_id": 1, "shardkey": 2} 

premier va évidemment par la deuxième échoue. Si j'avais eu deux fragments, et que les clés de fragmentation auraient été acheminées vers des fragments différents, je suppose que les deux auraient réussi.

Je peux évidemment simplement combiner la clé de partition et l'id pour créer le champ _id pour mongodb, puisque c'est vraiment la clé que j'utilise, mais cela semble être une façon étrange d'aborder le problème à partir d'une base de données architecturale point de vue.

Répondre

1

_id doit être unique, toujours, que la collection soit fragmentée ou non. La clé de partition n'a pas besoin d'être unique. Il est utilisé pour diviser la collection en morceaux qui peuvent être divisés sur les fragments constituant la base de données. La clé shard doit fournir suffisamment de granularité pour diviser les documents de la collection en morceaux. C'est évidemment une bonne idée de lier la clé de partition à la manière dont vous interrogez les données, et d'utiliser une clé de partition qui se rapporte aux champs sur lesquels vous interrogez. De cette façon, les requêtes que vous exécuterez seront facilement dirigées vers les partitions pertinentes pour satisfaire la requête. Si la clé de partition n'est pas suffisamment sélective, la requête doit aller sur plusieurs partitions pour trouver les documents corrects. Vous pouvez créer un index composé sur _id + shard-key et le rendre unique si vous le souhaitez. Je réalise que cela ne répond pas complètement à la question. J'ai du mal à comprendre ce que tu demandes. Peut-être que si vous pouviez poster un exemple des documents que vous stockez et des requêtes que vous lancez, cela vous aidera.

+0

Apparemment, _id n'a pas besoin d'être unique, seulement dans la partition. La façon dont mongodb semble gérer cela est de forcer _id à être globalement unique ou sinon il y a des problèmes à venir. Il n'applique pas cette contrainte d'unicité, et un moyen facile de le faire (et ce que font les autres bases de données) est de définir la clé comme clé-clé + id, mais il semble que mongodb ne le fasse pas (et c'est mon question, est-ce vraiment le cas? Ils laissent à l'application de faire appliquer?). Je ne parle pas d'index, un index unique sur shard-key + _id est superflue si _id doit être globalement unique. – falstro