Beste Lösung zum Korrigieren des Datenbankdesigns mit der GUID als Primärschlüssel

Ich bin nach einiger Bestätigung dieser Idee, eine schlecht funktionierende Datenbank zu reparieren oder einen besseren Vorschlag, falls einer eine hat. Immer offen für bessere Vorschläge.

Ich habe eine sehr große Datenbank (mehr als 20 Millionen Datensätze, die um ungefähr eine halbe Million pro Tag wachsen), die GUID als PK verwenden.

Ein Versehen meinerseits, aber die PK ist auf SQL Server geclustert und verursacht Leistungsprobleme.

Der Grund für eine Guid: Diese Datenbank ist teilweise mit 150 anderen Datenbanken synchronisiert, sodass die PK eindeutig sein musste. Die Synchronisierung wird nicht von SQL Server verwaltet, sondern es wird ein benutzerdefinierter Prozess erstellt, der die Daten für die Anforderungen des Systems synchronisiert - und zwar basierend auf dieser GUID.

In jeder der 150 entfernten Datenbanken werden nicht die vollständigen Daten gespeichert, die in der zentralen SQL-Datenbank gespeichert sind. Sie speichern nur eine Teilmenge der Daten, die sie tatsächlich benötigen, und die Daten, die sie benötigen, sind nicht eindeutig für sie (10 der 150 Datenbanken enthalten möglicherweise einige der gleichen Datensätze aus Datenbanken anderer Sites, die sie beispielsweise gemeinsam nutzen). Außerdem werden die Daten tatsächlich an den entfernten Standorten und nicht an der zentralen Stelle generiert, weshalb die GUIDs erforderlich sind.

Die zentrale Datenbank wird nicht nur verwendet, um alles synchron zu halten, sondern es werden auch Abfragen von mehr als 3000 Benutzern für diese sehr große fragmentierte Datenbank ausgeführt. Bereits beim ersten Testen ist dies ein großes Problem.

Zum Glück sind wir noch nicht live - also kann ich Änderungen vornehmen und bei Bedarf Dinge offline schalten, was zumindest etwas ist.

Die Leistung der entfernten Datenbanken ist kein Problem - die Datenteilmengen sind ziemlich klein und die Datenbank wird in der Regel nie größer als 1 GB. Die Datensätze werden regelmäßig an das Hauptsystem zurückgespeist und von den kleineren BDs entfernt, wenn sie nicht mehr benötigt werden.

Die Leistung der zentralen Datenbank, in der alle Datensätze gespeichert sind, ist bedauerlich - aufgrund einer gruppierten GUID als Primärschlüssel für die vielen Datensätze. Die Indexfragmentierung ist nicht in den Diagrammen.

Meine Überlegungen zur Behebung des Leistungsproblems sind, eine neue Spalte zu erstellen - Unsigned BIGINT IDENTITY (1,1) und dann die Clustered PK der Tabelle BIGINT-Spalte zu ändern.

Ich würde einen eindeutigen nicht gruppierten Index auf dem GUID-Feld verursachen, das der Primärschlüssel war.

Die kleineren entfernten 150-Datenbanken müssen nichts über die neue PK in der Central SQL Server-Datenbank wissen. Sie wird lediglich zum Organisieren der Daten in der Datenbank und zum Unterbinden der schlechten Leistung und Fragmentierung verwendet.

Würde dies funktionieren und die Leistung der zentralen SQL-Datenbank verbessern und die zukünftige Hölle der Indexfragmentierung (bis zu einem gewissen Grad) verhindern? oder habe ich hier etwas sehr wichtiges verpasst, das aufspringen und mich beißen und noch mehr trauern wird?

Sie müssen sich auf keinen Fall auf der GUID zusammenschließen. Wenn Sie über etwas verfügen, mit dem Sie andere Datensätze als diese GUID eindeutig identifizieren können , empfehlen wir Ihnen, einen eindeutigen Index für dieses andere Feld zu erstellen und diesen Index zu einem Cluster zu machen. Andernfalls können Sie auch mithilfe nicht eindeutiger Indizes Cluster für andere Felder erstellen. Der Ansatz, Cluster zu bilden, ist der beste, um Ihre Daten aufzuteilen und abzufragen. Wenn Sie also ein Gebietsfeld oder etwas anderes haben, ist dies möglicherweise ein Kandidat für Ihr Clustering-Schema.

Das Problem beim Wechsel zu a BIGINTwäre, Daten aus anderen Datenbanken zu ergänzen und deren Datenbank in den zentralen Speicher zu integrieren. Wenn dies keine Überlegung ist - und niemals eine Überlegung sein wird -, dann BIGINTwürde das das Problem der Indexanpassung gut lösen.

Wenn Sie hinter den Kulissen keinen Clustered-Index angeben, geht SQL Server ähnlich vor: Es erstellt ein Zeilen-ID-Feld und ordnet alle anderen Indizes diesem zu. Wenn Sie es also selbst tun, lösen Sie es so, wie SQL es lösen würde.

Das ist eine große Aufgabe.

Lassen Sie mich einen Mittelmannansatz vorschlagen.

Ich hatte Probleme mit System.Guid.NewGuid (), das zufällige Guids generiert. (Ich habe dem Client erlaubt, eine eigene Guid zu erstellen, anstatt mich auf die Datenbank zu verlassen, um eine sequenzielle ID zu erstellen.)

Nachdem ich auf der Clientseite zu einem UuidCreateSequential gewechselt war, wurde meine Leistung VIEL besser, insbesondere bei INSERTs.

Hier ist der DotNet-Client-Code voodoo. Ich bin sicher, ich habe von irgendwoher verpfändet:

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




*/

ABWECHSELNDE IDEE:

Wenn Ihre Hauptdatenbank und Ihre Remote-Datenbank "verknüpft" sind (wie in "sp_linkserver"), können Sie die Hauptdatenbank als "UUID-Generator" verwenden.

Du willst nicht "eins nach dem anderen" von uuid bekommen, das ist zu viel Geschwätz.

Aber du könntest dir ein paar UUIDs schnappen.

Unten ist ein 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

* /

Gehen Sie gemäß Ihrer Beschreibung zu BIGINT. Der Index für GUID kann jedoch nicht eindeutig sein, da GUIDs ohnehin global eindeutig sein sollen.

Wenn GUID korrekt als uniqueidentifier gespeichert ist, sollte es keine Performance-Probleme geben ... und wenn Sie Sequential GUID noch besser nutzen können ...

Auch @mattytommo hat einen guten Punkt über 11,5 Jahre mit der Verwendung von INT ...