Sql Database : utlisation du type UNIQUEIDENTIFIER

Version imprimable

07/01/2020, 11h58
Kropernic

Sql Database : utlisation du type UNIQUEIDENTIFIER

Hello tout le monde.

Je viens chercher l'avis de la communauté car le travail sur Azure, c'est nouveau pour moi...

Voici le contexte... Je reprends un projet et dans ce projet, le type UNIQUEIDENTIFIER a été utilisé partout. Chaque table a sa PK avec ce type.

Au départ, j'ai crié à l'hérésie en pensant aux indexes puis j'ai vu que la fonction NEWSEQUENTIALID est utilisée partout aussi donc à priori, ça passe vu les guid créés sont donc séquentiels.

Puis aujourd'hui, je tombe sur la page qui document la fonction NEWSEQUENTIALID.

Page dans laquelle je peux lire ceci :

Citation:

Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique. When a GUID column is used as a row identifier, using NEWSEQUENTIALID can be faster than using the NEWID function. This is because the NEWID function causes random activity and uses fewer cached data pages. Using NEWSEQUENTIALID also helps to completely fill the data and index pages.

A la fin de ce paragraphe, le point que je soulevais pour les indexes est indiqué donc c'est ok.

Par contre, la partie que j'ai mise en gras m'inquiète fortement.
Comment cela est-il géré sur azure ? Qu'est-ce qui détermine si un serveur sql azure est redémarré ? Faut-il souscrire à une option, un plan particulier pour qu'il ne redémarre jamais sous peine d'avoir un jour un NEWSEQUENTIALID qui soit en plein milieu de l'index ? Le projet en question, c'est de l'iot donc niveau masse de donnée, ça envoie du paté... (enfin ça va envoyer, ce n'est encore que le début pour le moment)

Voilà, si quelqu'un de coutumier avec Azure pouvait éclairer ma lanterne, ce serait cool.

Merci d'avance.
07/01/2020, 17h03
DotNetMatt

Citation:

Envoyé par Kropernic

Au départ, j'ai crié à l'hérésie en pensant aux indexes puis j'ai vu que la fonction NEWSEQUENTIALID est utilisée partout aussi donc à priori, ça passe vu les guid créés sont donc séquentiels.

Les UNIQUEIDENTIFIER sont surtout problematiques lorsqu'ils sont utilises avec un UNIQUE CLUSTERED INDEX (ce qui est le cas par defaut lorsqu'une Clef Primaire est creee dans SQL Server).

Citation:

Envoyé par Kropernic

Par contre, la partie que j'ai mise en gras m'inquiète fortement.
Comment cela est-il géré sur azure ? Qu'est-ce qui détermine si un serveur sql azure est redémarré ? Faut-il souscrire à une option, un plan particulier pour qu'il ne redémarre jamais sous peine d'avoir un jour un NEWSEQUENTIALID qui soit en plein milieu de l'index ? Le projet en question, c'est de l'iot donc niveau masse de donnée, ça envoie du paté... (enfin ça va envoyer, ce n'est encore que le début pour le moment)

Avec SQL Server on-premises ca peut arriver lorsqu'Always On est actif, et que la base de donnees failover. Sur Azure, je ne sais pas comment c'est gere.

Si tu as souscrit au support Azure je te conseille de creer un ticket et de voir leur reponse. Sinon, tu peux poster ta question tout en bas de l'article dans les commentaires, mais ca peut prendre quelques jours pour avoir une reponse…
09/01/2020, 14h36
Kropernic

Citation:

Envoyé par DotNetMatt

Les UNIQUEIDENTIFIER sont surtout problematiques lorsqu'ils sont utilises avec un UNIQUE CLUSTERED INDEX (ce qui est le cas par defaut lorsqu'une Clef Primaire est creee dans SQL Server).

Ce qui est, bien sûr, le cas partout :aie:.
Ce qui m'a été avancé comme argument quand j'ai posé la question du pourquoi le guid, c'était essentiellement car c'était comme ça quand ils ont reçu la base de code (car c'était la 2e société de consultance qui passait dessus) mais aussi pcq c'était plus difficile à bidouiller quand il est passé en querystring... Argument totalement bidon selon moi.

Citation:

Envoyé par DotNetMatt

Avec SQL Server on-premises ca peut arriver lorsqu'Always On est actif, et que la base de donnees failover. Sur Azure, je ne sais pas comment c'est gere.

Si tu as souscrit au support Azure je te conseille de creer un ticket et de voir leur reponse. Sinon, tu peux poster ta question tout en bas de l'article dans les commentaires, mais ca peut prendre quelques jours pour avoir une reponse…

Je vais devoir regarder ce qu'on a droit comme support à ce niveau-là car c'est facturé via la boîte de consultance qui elle-même est facturée en CSP.

De toute façon, tant que ça fonctionne et que ça n'est pas catastrophique au niveau de l'environnement de prod pour les perfs, ça va rester comme ça tant qu'on fait pas une version 2. Et on n'est pas encore vraiment à la version 1 :aie:
09/01/2020, 18h18
DotNetMatt

Citation:

Envoyé par Kropernic

Ce qui est, bien sûr, le cas partout :aie:.

:aie:

Cela dit, il n'y a rien de mal a utiliser le type UNIQUEIDENTIFIER pour une clef primaire, il faut juste veiller a avoir le bon type d'index, et a garder un oeil sur la fragmentation (i.e. rebuilder les index souvent). A la clef, c'est pour economiser de l'espace disque et ameliorer les performances des requetes SELECT principalement.

Il y a un tres bon article de Kimberly Tripp (la reine des index) a ce sujet : GUIDs as PRIMARY KEYs and/or the clustering key.

Citation:

Envoyé par Kropernic

ça n'est pas catastrophique au niveau de l'environnement de prod pour les perfs

C'est surtout sur les grosses volumetries que l'impact est sensible. Par contre, quelle que soit la volumetrie, ca peut contribuer a augmenter legerement ta facturation sur Azure vu que tu vas consommer un peu plus de DTU.