Meilleure solution pour fixer la conception de la base de données avec GUID comme clé primaire

Je suis après une confirmation de cette idée pour corriger une base de données mal performante ou une meilleure suggestion si quelqu'un en a une. Toujours ouvert à de meilleures suggestions.

J'ai une très grande base de données (plus de 20 millions d'enregistrements augmentant d'environ 1/2 million par jour) qui utilise le GUID comme PK.

Un oubli de ma part mais le PK est clusterisé sur le serveur SQL et cause des problèmes de performances.

La raison d'un GUID - cette base de données est partiellement synchronisée avec 150 autres bases de données, de sorte que le PK devait être unique. La synchronisation n'est pas gérée par SQL Server, il existe plutôt un processus personnalisé construit qui maintient les données synchronisées pour les exigences du système - toutes basées sur ce GUID.

Chacune des 150 bases de données distantes ne stocke pas les données complètes telles qu'elles sont stockées dans la base de données SQL centrale. ils ne stockent qu'un sous-ensemble des données dont ils ont réellement besoin, et les données dont ils ont besoin ne leur sont pas uniques (10 des 150 bases de données peuvent avoir certains des mêmes enregistrements des bases de données d'autres sites par exemple - ils partagent). De plus - les données sont en fait générées sur les sites distants - pas au point central - d'où la nécessité des GUID.

La base de données centrale est utilisée non seulement pour tout synchroniser, mais les requêtes de plus de 3000 utilisateurs seront exécutées sur cette très grande base de données fragmentée. C'est déjà un gros problème lors des tests initiaux.

Heureusement, nous ne sommes pas encore en direct - je peux donc apporter des modifications et mettre les choses hors ligne si nécessaire, ce qui est au moins quelque chose.

Les performances des bases de données distantes ne sont pas un problème - les sous-ensembles de données sont assez petits et la base de données ne dépasse généralement jamais 1 Go au total. Les enregistrements sont renvoyés au système principal assez régulièrement et supprimés des BD plus petits lorsqu'ils ne sont plus nécessaires.

Les performances de la base de données centrale qui est la gardienne de tous les enregistrements sont lamentables - en raison d'un GUID en cluster comme clé primaire pour autant d'enregistrements. La fragmentation de l'indice est hors des graphiques.

Donc - mes réflexions pour résoudre le problème de performances sont de créer une nouvelle colonne - Unsigned BIGINT IDENTITY (1,1), puis de changer le cluster cluster de la colonne BIGINT de la table.

Je créerais un index unique non groupé sur le champ GUID qui était la clé primaire.

Les 150 bases de données distantes plus petites n'ont pas besoin de connaître le nouveau PK sur la base de données Central SQL Server - il sera purement utilisé pour organiser les données dans la base de données et arrêter les mauvaises performances et la fragmentation.

Est-ce que cela fonctionnerait et améliorerait les performances de la base de données SQL centrale et empêcherait un futur enfer de fragmentation d'index (dans une certaine mesure)? ou ai-je raté quelque chose de très important ici qui va me sauter et me mordre et causer encore plus de chagrin?

Vous n'avez certainement pas besoin de cluster sur le GUID. Si vous avez quelque chose qui vous permettrait d'identifier de manière unique des enregistrements autres que ce GUID, je vous suggère de chercher à créer un index unique sur cet autre champ et à rendre cet index en cluster. Sinon, vous êtes libre de regrouper sur d'autres champs, même en utilisant des index non uniques. L'approche qu'il y aurait à regrouper facilite cependant le fractionnement de vos données et l'interrogation - donc, si vous avez un champ "région", ou quelque chose, cela pourrait être un candidat pour votre schéma de clustering.

Le problème avec le passage à a BIGINTserait des ajouts aux données d'autres bases de données et l'intégration de leur base de données dans le magasin central. Si ce n'est pas une considération - et ne le sera jamais - alors, oui, BIGINTcela résoudrait bien le problème de rééquilibrage des indices.

En arrière-plan, si vous ne spécifiez pas d'index clusterisé, SQL Server fait à peu près la même chose: il crée un champ d'ID de ligne et mappe tous les autres index dans celui-ci. Donc, en le faisant vous-même, vous le résolvez comme SQL le résoudrait.

C'est un défi de taille.

Permettez-moi de suggérer une approche intermédiaire.

J'avais des problèmes avec System.Guid.NewGuid () générant des guides aléatoires. (Je permettais au client de créer son propre guide, au lieu de s'appuyer sur la base de données pour créer un séquentiel).

Une fois que je suis passé à un UuidCreateSequential côté client, mes performances sont devenues BEAUCOUP meilleures, en particulier sur INSERT.

Voici le code client vaudou de DotNet. Je suis sûr d'avoir mis en gage quelque part:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;


namespace MyCompany.MyTechnology
{
  public static class Guid
  {


    [DllImport("rpcrt4.dll", SetLastError = true)]
    static extern int UuidCreateSequential(out System.Guid guid);


    public static System.Guid NewGuid()
    {
      return CreateSequentialUUID();
    }


    public static System.Guid CreateSequentialUUID()
    {
      const int RPC_S_OK = 0;
      System.Guid g;
      int hr = UuidCreateSequential(out g);
      if (hr != RPC_S_OK)
        throw new ApplicationException("UuidCreateSequential failed: " + hr);
      return g;
    }


  }
}














    /*

Original Reference for Code:
http://www.pinvoke.net/default.aspx/rpcrt4/UuidCreateSequential.html


*/

/*



Text From URL above:

UuidCreateSequential (rpcrt4)

Type a page name and press Enter. You'll jump to the page if it exists, or you can create it if it doesn't.
To create a page in a module other than rpcrt4, prefix the name with the module name and a period.
. Summary
Creates a new UUID 
C# Signature:
[DllImport("rpcrt4.dll", SetLastError=true)]
static extern int UuidCreateSequential(out Guid guid);


VB Signature:
Declare Function UuidCreateSequential Lib "rpcrt4.dll" (ByRef id As Guid) As Integer


User-Defined Types:
None.

Notes:
Microsoft changed the UuidCreate function so it no longer uses the machine's MAC address as part of the UUID. Since CoCreateGuid calls UuidCreate to get its GUID, its output also changed. If you still like the GUIDs to be generated in sequential order (helpful for keeping a related group of GUIDs together in the system registry), you can use the UuidCreateSequential function.

CoCreateGuid generates random-looking GUIDs like these:

92E60A8A-2A99-4F53-9A71-AC69BD7E4D75
BB88FD63-DAC2-4B15-8ADF-1D502E64B92F
28F8800C-C804-4F0F-B6F1-24BFC4D4EE80
EBD133A6-6CF3-4ADA-B723-A8177B70D268
B10A35C0-F012-4EC1-9D24-3CC91D2B7122



UuidCreateSequential generates sequential GUIDs like these:

19F287B4-8830-11D9-8BFC-000CF1ADC5B7
19F287B5-8830-11D9-8BFC-000CF1ADC5B7
19F287B6-8830-11D9-8BFC-000CF1ADC5B7
19F287B7-8830-11D9-8BFC-000CF1ADC5B7
19F287B8-8830-11D9-8BFC-000CF1ADC5B7



Here is a summary of the differences in the output of UuidCreateSequential:

The last six bytes reveal your MAC address 
Several GUIDs generated in a row are sequential 
Tips & Tricks:
Please add some!

Sample Code in C#:
static Guid UuidCreateSequential()
{
   const int RPC_S_OK = 0;
   Guid g;
   int hr = UuidCreateSequential(out g);
   if (hr != RPC_S_OK)
     throw new ApplicationException
       ("UuidCreateSequential failed: " + hr);
   return g;
}



Sample Code in VB:
Sub Main()
   Dim myId As Guid
   Dim code As Integer
   code = UuidCreateSequential(myId)
   If code <> 0 Then
     Console.WriteLine("UuidCreateSequential failed: {0}", code)
   Else
     Console.WriteLine(myId)
   End If
End Sub




*/

IDÉE ALTERNATIVE:

Si votre base de données principale et base de données distante sont "liées" (comme dans sp_linkserver) ...... alors vous pouvez utiliser la base de données principale comme "générateur uuid".

Vous ne voulez pas obtenir "un par un" uuid, c'est trop de bavardage.

Mais vous pourriez attraper un ensemble d'uuid.

Ci-dessous est un code:

IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
 OBJECT_ID(N'[dbo].[uspNewSequentialUUIDCreateRange]') AND type in (N'P',
 N'PC'))

 DROP PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange]

 GO



 CREATE PROCEDURE [dbo].[uspNewSequentialUUIDCreateRange] (

 @newUUIDCount int --return

 )

 AS

 SET NOCOUNT ON

 declare @t table ( dummyid int , entryid int identity(1,1) , uuid
 uniqueidentifier default newsequentialid() )

 insert into @t ( dummyid ) select top (@newUUIDCount) 0 from dbo.sysobjects
 so with (nolock)

 select entryid , uuid from @t

 SET NOCOUNT OFF

 GO

/ *

--START TEST

 set nocount ON

 Create Table #HolderTable (entryid int , uuid uniqueidentifier )

 declare @NewUUIDCount int

 select @NewUUIDCount = 20

 INSERT INTO #HolderTable EXEC dbo.uspNewSequentialUUIDCreateRange
 @NewUUIDCount

 select * from #HolderTable

 DROP Table #HolderTable

 --END TEST CODE

* /

En fonction de votre description, optez pour BIGINT. Cependant, l'index du GUID peut être non unique, car les GUID sont censés être globalement uniques de toute façon.

Si le GUID est stocké correctement en tant qu'identificateur unique, il ne devrait pas y avoir de problèmes de performances ... et si vous pouvez utiliser le GUID séquentiel encore mieux ...

@Mattytommo a également un bon point sur 11,5 ans avec l'utilisation de INT ...