La mejor solución para arreglar el diseño de la base de datos con GUID como clave principal

Estoy después de una confirmación de esta idea para arreglar una base de datos de bajo rendimiento o una mejor sugerencia si alguien tiene una. Siempre abierto a mejores sugerencias.

Tengo una base de datos muy grande (más de 20 millones de registros que crecen aproximadamente 1/2 millón por día) que usan GUID como PK.

Un descuido de mi parte, pero el PK está agrupado en el servidor SQL y está causando problemas de rendimiento.

El motivo de un guid: esta base de datos está parcialmente sincronizada con otras 150 bases de datos, por lo que la PK debe ser única. La sincronización no es administrada por SQL Server, sino que hay un proceso personalizado creado que mantiene los datos sincronizados para los requisitos del sistema, todo basado en ese GUID.

Cada una de las 150 bases de datos remotas no almacena los datos completos como se almacenan en la base de datos central de SQL. solo almacenan un subconjunto de los datos que realmente requieren, y los datos que requieren no son exclusivos para ellos (10 de las 150 bases de datos pueden tener algunos de los mismos registros de las bases de datos de otros sitios, por ejemplo, comparten). Además, los datos se generan en los sitios remotos, no en el punto central, de ahí la necesidad de los GUID.

La base de datos central se usa no solo para mantener todo sincronizado, sino que las consultas de más de 3000 usuarios se ejecutarán en esa gran base de datos fragmentada. Este ya es un gran problema en las pruebas iniciales.

Afortunadamente, todavía no estamos en vivo, por lo que puedo hacer cambios y desconectar las cosas si es necesario, que es al menos algo.

El rendimiento de las bases de datos remotas no es un problema: los subconjuntos de datos son bastante pequeños y la base de datos generalmente nunca supera el tamaño de 1 GB en total. Los registros se retroalimentan al sistema principal con bastante regularidad y se eliminan de los BD más pequeños cuando ya no son necesarios.

El rendimiento de la base de datos central que es el guardián de todos los registros es lamentable, debido a un GUID agrupado como clave principal para esa cantidad de registros. La fragmentación del índice está fuera de los gráficos.

Entonces, mi intención de solucionar el problema de rendimiento es Crear una nueva columna: IDENTIDAD BIGINT sin firmar (1,1) y luego cambiar el PK agrupado de la columna BIGINT de la tabla.

Crearía un índice único no agrupado en el campo GUID, que era la clave principal.

Las 150 bases de datos remotas más pequeñas no necesitan saber acerca de la nueva PK en la base de datos del Servidor SQL Central: se utilizará exclusivamente para organizar los datos en la base de datos y detener el mal rendimiento y la fragmentación.

¿Funcionaría y mejoraría el rendimiento de la base de datos central de SQL y evitaría un futuro infierno de fragmentación del índice (hasta cierto punto)? ¿O me he perdido algo muy importante aquí que va a saltar y morderme y causar aún más dolor?

Ciertamente, NO necesita agruparse en el GUID. Si tiene algo que le permitiría identificar de manera única los registros que no sean ese GUID, le sugiero que busque construir un índice único en ese otro campo y agrupar ese índice. De lo contrario, puede agruparse en otros campos, incluso utilizando índices no únicos. Sin embargo, el enfoque sería agrupar, sin embargo, facilita la división de sus datos y las consultas, por lo que, si tiene un campo de "región", o algo así, podría ser un candidato para su esquema de agrupación.

El problema con el cambio a a BIGINTsería adiciones a los datos de otras bases de datos e integración de su base de datos en la tienda central. Si esto no es una consideración, y nunca será una consideración, entonces sí BIGINTresolvería el problema del reequilibrio del índice muy bien.

Detrás de escena, si no especifica un índice agrupado, SQL Server hace lo mismo: crea un campo de ID de fila y asigna todos los demás índices a ese. Entonces, al hacerlo usted mismo, lo está resolviendo tal como lo resolvería SQL.

Esa es una tarea difícil.

Permítanme sugerir un enfoque de intermediario.

Estaba teniendo problemas con System.Guid.NewGuid () generando guías aleatorias. (Estaba permitiendo que el cliente creara su propia guía, en lugar de confiar en la base de datos para crear una secuencial).

Una vez que me mudé a un UuidCreateSequential en el lado del cliente, mi rendimiento mejoró MUCHO, especialmente en INSERT.

Aquí está el código de cliente DotNet vudú. Estoy seguro de que empeñé desde algún lado:

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




*/

IDEA ALTERNATIVA:

Si su base de datos principal y las bases de datos remotas están "vinculadas" (como en, sp_linkserver) ... entonces podría usar la base de datos principal como el "generador de uuid".

No quieres obtener el "uno por uno" de uuid, eso es demasiado charlatanería.

Pero podrías tomar un juego de uuid.

A continuación hay un código:

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

* /

Según su descripción, vaya con BIGINT. Sin embargo, el índice para GUID puede ser no único, ya que se supone que los GUID son globalmente únicos de todos modos.

Si GUID se almacena correctamente como identificador único, no debería haber problemas de rendimiento ... y si puede usar GUID secuencial aún mejor ...

También @mattytommo tiene un buen punto de aproximadamente 11.5 años con el uso de INT ...