Comment construire sharding hachage sur le terrain dans MongoDB

Question

Je cherche une bonne approche pour faire ce qui suit:

remis un document avec une FI sur le terrain veulent mettre en place sharding que mon application peut générer un hachage statique pour cette valeur de champ (ce qui signifie que le hachage sera toujours le même si la valeur est la même), puis utilisez ce hachage pour cibler la partition appropriée dans une configuration MongoDB partitionnée normale.

Questions:

1. Est-ce une approche sécuritaire/bonne?
2. Quelle est la bonne façon de procéder pour l'implémenter
3. Y a-t-il des pièges concernant la configuration du cluster de partition dont je devrais être conscient.

Merci!

Answer 1

J'ai effectivement implémenté ceci et c'est très faisable et donne de très bonnes performances d'écriture. Je suppose que vous avez les mêmes raisons de l'implémenter que moi (ciblage instantané des fragments sans échauffement/équilibrage, débit d'écriture, pas de dégradation des performances lors des mouvements/découpages de blocs, etc.).

Vos questions:

1. Oui, il est fourni de l'implémenter correctement.
2. Ce que je fais dans notre couche ORM interne est de marquer certains champs dans le document comme un champ haché. Notre ORM générera alors automatiquement une valeur de hachage pour cette valeur de champ juste avant d'écrire ou de lire le document. Les requêtes sortantes sont ensuite décorées avec cette valeur de hachage (dans notre cas, toujours appelée "hash"), que le sharding MongoDB utilise ensuite pour le ciblage de partition. Évidemment, dans ce scénario, le "hachage" est toujours la seule clé de partitionnement.
3. Le plus important de loin est de générer de bons hashs. Un grand nombre de valeurs de champs (le plus souvent un champ _id basé sur ObjectId) sont incrémentales, aussi votre algorithme de hachage doit-il être tel que les hachages générés pour les valeurs incrémentielles résultent en des valeurs de hachage qui frappent différents fragments. D'autres problèmes incluent la sélection de la taille de bloc appropriée.

Quelques inconvénients à considérer:

• équilibrage par défaut MongoDB morceau devient moins utile puisque vous généralement configurer votre groupe initial avec beaucoup de morceaux (ce qui facilite l'ajout tessons à votre cluster, tout en maintenant la propagation de bonne morceau à travers tous les éclats). Cela signifie que l'équilibreur ne commencera à se fractionner que si vous avez suffisamment de données dans vos blocs prématurés pour nécessiter une division.
• Il est probable qu'il devienne officiellement une fonctionnalité MongoDB officiellement prise en charge dans un proche avenir, ce qui peut rendre cet effort un peu inutile. Comme moi, vous n'avez peut-être pas le luxe d'attendre.

Bonne chance.

MISE À JOUR 25/03/2013: À partir de la version 2.4, MongoDB prend en charge les index de hachage en mode natif.

Answer 2

C'est une idée bonne et sûre.

Cependant, le choix de la fonction de hachage est cruciale:

• voulez-vous qu'il soit uniforme (vous lisser la charge de tous vos tesson mais vous perdez un peu en vrac l'accès sémantique)?
• voulez-vous qu'il soit lisible par l'homme? (Vous l'efficacité lâche (par rapport à hachage binaire qui sont très rapides), mais vous gagnez, eh bien, la lisibilité
• peut vous rendre cohérent (méfiez-vous de la fonction de hachage fournie langue)
• pouvez-vous vous appliquer unicidad si vous voulez
?

J'ai réussi choisi: l'uniformité, sous forme binaire, la cohérence et l'unicité d'une fonction murmurHash3:

valeur

-> murmurmHash (valueInBinaryForm) suivi du valueInBinaryForm