Qu'est-ce que l'algorithme Hi / Lo?

Qu'est-ce que l'algorithme Hi / Lo?

J'ai trouvé cela dans la documentation NHibernate (c'est une méthode pour générer des clés uniques, section 5.1.4.2), mais je n'ai pas trouvé une bonne explication de son fonctionnement.

Je sais que Nhibernate s'en occupe, et je n'ai pas besoin de connaître l'intérieur, mais je suis juste curieux.

L'idée de base est que vous avez deux nombres pour constituer une clé primaire - un nombre «élevé» et un nombre «faible». Un client peut fondamentalement incrémenter la séquence "haute", sachant qu'il peut alors générer en toute sécurité des clés à partir de toute la plage de la valeur "haute" précédente avec la variété de valeurs "basses".

Par exemple, en supposant que vous avez une séquence "élevée" avec une valeur actuelle de 35 et que le nombre "faible" soit compris entre 0 et 1023. Ensuite, le client peut incrémenter la séquence à 36 (pour que d'autres clients puissent générer des clés pendant qu'il utilise 35) et savoir que les clés 35/0, 35/1, 35/2, 35/3 ... 35/1023 sont tous disponibles.

Il peut être très utile (en particulier avec les ORM) de pouvoir définir les clés primaires côté client, au lieu d'insérer des valeurs sans clés primaires, puis de les récupérer sur le client. En plus de toute autre chose, cela signifie que vous pouvez facilement établir des relations parent / enfant et que les clés sont toutes en place avant de faire des insertions, ce qui rend leur traitement par lots plus simple.

En plus de la réponse de Jon:

Il est utilisé pour pouvoir travailler déconnecté. Un client peut alors demander au serveur un nombre élevé et créer des objets en augmentant le nombre lo lui-même. Il n'a pas besoin de contacter le serveur tant que la plage lo n'est pas utilisée.

Puisque c'est une question très courante, j'ai écrit cet article , sur lequel cette réponse est basée.

Les algorithmes hi / lo divisent le domaine des séquences en groupes «hi». Une valeur «hi» est affectée de manière synchrone. Chaque groupe «hi» reçoit un nombre maximum d'entrées «lo», qui peuvent être attribuées hors ligne sans se soucier des entrées en double simultanées.

1. Le jeton «hi» est attribué par la base de données et deux appels simultanés sont garantis pour voir des valeurs consécutives uniques
2. Une fois qu'un jeton «hi» est récupéré, nous n'avons besoin que de «incrementSize» (le nombre d'entrées «lo»)

3. La plage d'identifiants est donnée par la formule suivante:

   [(hi -1) * incrementSize) + 1, (hi * incrementSize) + 1)

   et la valeur "lo" sera dans la plage:

   [0, incrementSize)

   étant appliqué à partir de la valeur de départ de:

   [(hi -1) * incrementSize) + 1)

4. Lorsque toutes les valeurs «lo» sont utilisées, une nouvelle valeur «hi» est récupérée et le cycle continue

Vous pouvez trouver une explication plus détaillée dans cet article :

Et cette présentation visuelle est également facile à suivre:

Bien que l'optimiseur hi / lo soit idéal pour optimiser la génération d'identifiants, il ne fonctionne pas bien avec d'autres systèmes insérant des lignes dans notre base de données, sans rien savoir de notre stratégie d'identifiants.

Hibernate propose l' optimiseur pool-lo , qui offre les avantages de la stratégie de générateur hi / lo tout en assurant l'interopérabilité avec d'autres clients tiers qui ne connaissent pas cette stratégie d'allocation de séquence.

À la fois efficace et interopérable avec d'autres systèmes, l'optimiseur pooled-lo est un bien meilleur candidat que la stratégie d'identificateur hi / lo héritée.

Lo est un allocateur mis en cache qui divise l'espace de clés en gros morceaux, généralement basés sur une certaine taille de mot machine, plutôt que sur des plages de taille significative (par exemple, l'obtention de 200 clés à la fois) qu'un humain pourrait raisonnablement choisir.

L'utilisation de Hi-Lo a tendance à gaspiller un grand nombre de clés au redémarrage du serveur et à générer de grandes valeurs de clé peu conviviales.

Mieux que l'allocateur Hi-Lo, l'allocateur "Linear Chunk". Cela utilise un principe similaire basé sur une table mais alloue de petits morceaux de taille pratique et génère de belles valeurs conviviales.

create table KEY_ALLOC (
    SEQ varchar(32) not null,
    NEXT bigint not null,
    primary key (SEQ)
);

Pour allouer les 200 clés suivantes, disons (qui sont ensuite conservées en tant que plage dans le serveur et utilisées selon les besoins):

select NEXT from KEY_ALLOC where SEQ=?;
update KEY_ALLOC set NEXT=(old value+200) where SEQ=? and NEXT=(old value);

À condition que vous puissiez valider cette transaction (utilisez des tentatives pour gérer les conflits), vous avez alloué 200 clés et pouvez les distribuer au besoin.

Avec une taille de bloc de seulement 20, ce schéma est 10 fois plus rapide que l'allocation à partir d'une séquence Oracle et est 100% portable dans toutes les bases de données. Les performances d'allocation sont équivalentes à hi-lo.

Contrairement à l'idée d'Ambler, il traite l'espace de clés comme une ligne de nombre linéaire contiguë.

Cela évite l'impulsion pour les clés composites (qui n'ont jamais vraiment été une bonne idée) et évite de gaspiller des mots entiers au redémarrage du serveur. Il génère des valeurs clés «conviviales» à taille humaine.

L'idée de M. Ambler, par comparaison, alloue les 16 ou 32 bits les plus élevés et génère de grandes valeurs de clé peu conviviales en tant qu'incrément des mots forts.

Comparaison des clés allouées:

Linear_Chunk       Hi_Lo
100                65536
101                65537
102                65538
.. server restart
120                131072
121                131073
122                131073
.. server restart
140                196608

Du point de vue de la conception, sa solution est fondamentalement plus complexe sur la ligne numérique (clés composites, grands produits hi_word) que Linear_Chunk sans aucun avantage comparatif.

La conception Hi-Lo est apparue au début de la cartographie et de la persistance OO. De nos jours, les frameworks de persistance tels que Hibernate offrent des allocateurs plus simples et meilleurs par défaut.

J'ai trouvé que l'algorithme Hi / Lo est parfait pour plusieurs bases de données avec des scénarios de réplication basés sur mon expérience. Imagine ça. vous avez un serveur à New York (alias 01) et un autre serveur à Los Angeles (alias 02) alors vous avez une table PERSONNE ... donc à New York quand une personne est créée ... vous utilisez toujours 01 comme valeur HI et la valeur LO est la prochaine sécuentielle. par exemple.

• 010000010 Jason
• 010000011 David
• 010000012 Theo

à Los Angeles, vous utilisez toujours le HI 02. Par exemple:

• 020000045 Rupert
• 020000046 Oswald
• 020000047 Mario

Ainsi, lorsque vous utilisez la réplication de base de données (quelle que soit la marque), toutes les clés primaires et les données se combinent facilement et naturellement sans se soucier des clés primaires en double, des collisions, etc.

C'est la meilleure façon de procéder dans ce scénario.