A chacun ses expériences douloureuses.
Comme indiqué avant cette technique souffre de l'énorme problème des actions "jouant" avec la valeur identity comme par exemple :
- dbcc checkident https://docs.microsoft.com/fr-fr/sql...ql-server-2017
- set identity insert https://docs.microsoft.com/fr-fr/sql...ql-server-2017
Si c'est l'option retenue alors :
1- il convient d'ajouter une contrainte check en jouant du modulo.
2- de vérifier que le type choisi convient au besoin de numérotation (n'oublions pas qu'une valeur identity rollbackée est quand même consommée et qu'on peut purger tout ou partie d'une table sans changer la numérotation) dans le temps :
a- si int : le max est 2 147 483 647 si on prend 100 serveurs le max sera de 21 474 836 pour chacun d'eux, individuellement.
b- si bigint, la capacité devrait aller, mais on ajoute 8 octets à la table pour éviter de faire usage d'une colonne de 16 octets.
Dans le cas a- en adoptant l'index cluster sur la PK et la colonne GUID en tant que clé candidate avec un index non cluster, l'activité propre au serveur devrait bien se passer et l'activité de réplication, qui compare l'intégralité des colonnes pour chaque ligne existante des 2 côtés, le surcoût semble correct.
Dans le cas b- l'écart se resserre. A voir. Pas persuadé que le bilan global soit favorable à cette technique.
J'avoue que je réagit plus par peur de reproduire l'expérience douloureuse que suite à un POC en faisant varier le nombre d'abonnés (par exemple de 2 à 92 par paliers de 10) et la volumétrie, le tout en charge.
Ce serait un bon exercice ça !
L'utilisation de HammerDB (et du TCPH) pour fixer la charge et déterminer la volumétrie pourrait être utile.
Perso je n'ai ni le temps ni les moyens techniques de le faire.
Mais je suis preneur du résultat.
Surtout s'il ne va pas dans mon sens.
Partager