Лучшее решение для исправления дизайна базы данных с GUID в качестве первичного ключа

Я после некоторого подтверждения этой идеи, чтобы исправить плохо работающую базу данных или лучшее предложение, если кто-то есть. Всегда открыт для лучших предложений.

У меня очень большая база данных (более 20 миллионов записей растет примерно на 1/2 миллиона в день), которые используют GUID в качестве PK.

С моей стороны это недосмотр, но ПК кластеризован на сервере SQL и вызывает проблемы с производительностью.

Причина для guid - эта база данных частично синхронизирована со 150 другими базами данных, поэтому PK должен быть уникальным. SQL Server не управляет синхронизацией, скорее, существует специальный процесс, который синхронизирует данные в соответствии с требованиями системы - все на основе этого GUID.

Каждая из 150 удаленных баз данных не хранит полные данные, хранящиеся в центральной базе данных SQL. они хранят только подмножество данных, которые им действительно необходимы, и данные, которые им требуются, не являются уникальными для них (например, 10 из 150 баз данных могут иметь одни и те же записи из баз данных других сайтов - они совместно используют). Кроме того, данные на самом деле генерируются на удаленных сайтах, а не в центральной точке, поэтому необходимы GUID.

Центральная база данных используется не только для синхронизации всего, но и к этой очень большой фрагментированной базе данных будут выполняться запросы от 3000+ пользователей. Уже это большая проблема при первоначальном тестировании.

К счастью, мы еще не живы - так что я могу вносить изменения и отключать их, если требуется, что является чем-то еще.

Производительность удаленных баз данных не является проблемой - подмножества данных довольно малы, а размер базы данных обычно не превышает 1 ГБ. Записи возвращаются в основную систему довольно регулярно и удаляются из меньших дисков BD, когда они больше не нужны.

Производительность центральной БД, которая хранит все записи, ужасна - из-за кластерного GUID в качестве первичного ключа для такого количества записей. Фрагментация индекса находится вне графика.

Итак, мои мысли по поводу исправления проблемы с производительностью - создать новый столбец BIGINT IDENTITY без знака (1,1), а затем изменить кластеризованный PK столбца BIGINT таблицы.

Я бы создал уникальный некластеризованный индекс в поле GUID, который был первичным ключом.

Меньшим удаленным базам данных 150 не нужно знать о новом ПК в базе данных Central SQL Server - он будет использоваться исключительно для организации данных в базе данных и предотвращения плохой производительности и фрагментации.

Будет ли это работать и улучшить производительность центральной базы данных SQL и предотвратить адскую фрагментацию в будущем (в определенной степени, конечно)? или я пропустил что-то очень важное здесь, которое подпрыгнет и укусит меня и вызовет еще больше горя?

Вам, конечно, не нужно кластеризоваться на GUID. Если у вас есть что-то, что позволит вам уникально идентифицировать записи, отличные от этого GUID, я бы посоветовал вам взглянуть на создание уникального индекса для этого другого поля и кластеризацию этого индекса. Если нет, вы можете кластеризовать другие поля, даже используя неуникальные индексы. Подход, заключающийся в кластеризации, однако, лучше всего облегчает разделение ваших данных и запросов - так что, если у вас есть поле «регион» или что-то еще, это может быть кандидатом для вашей схемы кластеризации.

Проблема с переходом на a BIGINTбудет заключаться в добавлении данных из других баз данных и интеграции их базы данных в центральное хранилище. Если это не рассмотрение - и никогда не будет рассмотрение - тогда, да, BIGINTэто решило бы проблему перебалансировки индекса.

За кулисами, если вы не укажете кластеризованный индекс, SQL Server делает то же самое: он создает поле идентификатора строки и отображает в нем все остальные индексы. Таким образом, делая это самостоятельно, вы решаете это так же, как это решает SQL.

Это высокий заказ.

Позвольте мне предложить подход среднего человека.

У меня были проблемы с System.Guid.NewGuid (), генерирующей случайные направляющие. (Я позволял клиенту создавать свой собственный guid, вместо того чтобы полагаться на базу данных для создания sequentialid).

Как только я перешел на UuidCreateSequential на стороне клиента, моя производительность стала НАМНОГО лучше, особенно на INSERT.

Вот код клиента DotNet вуду. Я уверен, что я заложил откуда-то

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




*/

АЛЬТЕРНАТИВНАЯ ИДЕЯ:

Если ваша основная база данных и удаленная база данных «связаны» (как, например, sp_linkserver) ...... тогда вы можете использовать основную базу данных в качестве «генератора uuid».

Вы не хотите, чтобы Uuid "один за другим", это слишком много болтливости.

Но вы можете взять набор UUID.

Ниже приведен код:

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

* /

Исходя из вашего описания, идти с BIGINT. Однако индекс для GUID может быть неуникальным, поскольку предполагается, что GUID в любом случае должен быть глобально уникальным.

Если GUID хранится правильно как uniqueidentifier, не должно быть проблем с производительностью ... и если вы можете использовать Sequential GUID еще лучше ...

Кроме того, @mattytommo имеет хороший момент около 11,5 лет с использованием INT ...