Usando um GUID como uma chave primária

Eu geralmente uso IDs de incremento automático como Chaves Primárias em bancos de dados. Estou tentando aprender os benefícios do uso de GUIDs. Eu li este artigo: https://betterexplained.com/articles/the-quick-guide-to-guids/

Percebo que esses GUIDs são usados ​​para identificar objetos no nível do aplicativo. Eles também são armazenados como a chave primária no nível do banco de dados. Por exemplo, digamos que eu tenha a seguinte classe:

public class Person
{
public GUID ID;
public string Name;
..

//Person Methods follow
}

Digamos que eu queira criar uma nova pessoa na memória e, em seguida, insira a Pessoa em um banco de dados. Posso apenas fazer isso:

Person p1 = new Person();
p1.ID=GUID.NewGUID();
PersonRepository.Insert(p1);

Digamos que eu tivesse um banco de dados contendo milhões e milhões de linhas com um GUID como Chave Primária. Isso sempre será único? Estou entendendo GUIDs corretamente?

Li este artigo anteriormente: http://enterprisecraftsmanship.com/2014/11/15/cqs-with-database-generated-ids/ . Isso me confunde um pouco, pois parece recomendar um meio termo entre GUIDs e números inteiros como Chaves Primárias.

Editar 11/06/18

Eu acredito que os Guids são mais adequados do que ints para minhas necessidades. Atualmente, estou usando mais o CQRS e os GUIDs se encaixam melhor.

Percebo que alguns desenvolvedores modelam os GUIDs como seqüências de caracteres no modelo de domínio, por exemplo, aqui: https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Services/Ordering/Ordering.Domain/AggregatesModel/BuyerAggregate/ Buyer.cs - neste caso: IdentityGuid é um GUID modelado como uma sequência. Existe algum motivo para fazer isso além do indicado aqui: Use um objeto de valor personalizado ou um Guid como identificador de entidade em um sistema distribuído? . É "normal" modelar o GUID como uma string ou devo modelá-lo como um GUID no modelo e no banco de dados?

Os GUIDs são, por definição, "identificadores globalmente exclusivos". Existe um conceito semelhante, mas um pouco diferente em Java, chamado UUIDs "Universally Unique IDentifiers". Os nomes são intercambiáveis ​​para todos os usos práticos.

Os GUIDs são essenciais para o funcionamento da clusterização de bancos de dados pela Microsoft e, se você precisar incorporar dados de fontes às vezes conectadas, eles realmente ajudarão a evitar colisões de dados.

Alguns fatos do Pro-GUID:

• GUIDs evitam colisões de chaves
• Os GUIDs ajudam a mesclar dados entre redes, máquinas etc.
• O SQL Server oferece suporte a GUIDS semi-seqüenciais para ajudar a minimizar a fragmentação do índice ( ref , algumas advertências)

Alguma feiura com GUIDs

• Eles são grandes, 16 bytes cada
• Eles estão com problemas, então você não pode classificar o código e esperar obter o pedido de inserção como em códigos de incremento automático
• Eles são mais difíceis de trabalhar, principalmente em pequenos conjuntos de dados (como tabelas de consulta)
• A nova implementação de GUID é mais robusta no SQL Server do que na biblioteca C # (você pode ter GUIDS sequenciais no SQL Server, em C # é aleatório)

Os GUIDs aumentarão seus índices; portanto, o custo do espaço em disco da indexação de uma coluna será maior. GUIDs aleatórios fragmentarão seus índices.

Se você sabe que não vai sincronizar dados de redes diferentes, os GUIDs podem ter mais sobrecarga do que valem.

Se você precisar ingerir dados de clientes às vezes conectados, eles podem ser muito mais robustos para evitar colisões de chaves do que depender da definição de intervalos de sequência para esses clientes.

Isso sempre será único?

Sempre? nem sempre; é uma sequência finita de bits.

Digamos que eu tivesse um banco de dados contendo milhões e milhões de linhas com um GUID como Chave Primária.

Milhões e milhões, você provavelmente está seguro. Um milhão de milhões e a probabilidade de uma colisão se torna significativa. Porém, há boas notícias: você já ficou sem espaço em disco no momento em que isso acontece.

Posso apenas fazer isso?

Você pode; não é uma ideia totalmente boa. Seu modelo de domínio normalmente não deve gerar números aleatórios; eles devem ser entradas para o seu modelo.

Além disso, quando você estiver lidando com uma rede não confiável, onde poderá receber mensagens duplicadas, um UUID gerado deterministicamente o protegerá de ter entidades duplicadas. Mas se você atribuir um novo número aleatório a cada um, terá mais trabalho a fazer para identificar a duplicação.

Veja a descrição do uuid baseado em nome no RFC 4122

É "normal" modelar o GUID como uma string ou devo modelá-lo como um GUID no modelo e no banco de dados?

Eu não acho que isso importe muito. Para a maior parte do seu modelo de domínio, é um identificador ; a única consulta que você faz é se é ou não o mesmo que outro identificador. Seu modelo de domínio normalmente não estará olhando para a representação na memória de um identificador.

Se o GUID estiver disponível como um "tipo primitivo" na configuração independente de domínio, eu o usaria; permite que o contexto de suporte escolha otimizações apropriadas que possam estar disponíveis.

O que você deve reconhecer, no entanto, é que a representação do identificador, tanto na memória quanto no armazenamento, é uma decisão que você está tomando em sua implementação e, portanto, deve tomar medidas para garantir que a pegada do código seja acoplada àquela decisão é pequena - veja Parnas 1972 .

O GUID ou o UUID provavelmente será único devido à forma como são gerados e eles fornecem uma maneira segura de garantir exclusividade sem precisar se comunicar com uma autoridade central.

Benefícios dos GUIDs como chave primária:

• Você pode copiar dados entre diferentes fragmentos de um cluster e não precisa se preocupar com colisões de PK.
• Ele permite que você conheça sua chave primária antes de inserir qualquer registro.
• Simplifica a lógica da transação para inserir registros filhos.
• Não pode ser adivinhado facilmente.

No exemplo que você forneceu:

Person p1 = new Person();
p1.ID = GUID.NewGUID();
PersonRepository.Insert(p1);

A especificação do GUID antes do tempo de inserção pode salvar uma viagem de ida e volta ao banco de dados ao inserir sucessivos registros filhos e permitir que você os confirme na mesma transação.

Person p2 = new Person();
p2.ParentID = p1.ID
PersonRepository.Insert(p2);

Distúrbios nos GUIDs como uma chave primária:

• São 16 bytes grandes, o que significa que consumirão mais espaço à medida que índices e chaves estrangeiras são adicionados.
• Eles não se classificam bem, pois são essencialmente números aleatórios.
• O uso do índice é muito, muito, muito ruim.
• Muita folha se movendo.
• Eles são difíceis de lembrar.
• Eles são difíceis de verbalizar.
• Eles podem dificultar a leitura dos URLs.

Se o seu aplicativo não precisar de sharding ou clustering, seria melhor usar tipos de dados menores e mais simples, como int ou bigint.

Muitos bancos de dados têm suas próprias implementações internas que tentam atenuar os problemas de armazenamento causados ​​pelos GUIDs e pelo SQL Server, inclusive com uma função newsequentialid para ajudar na ordenação dos UUIDs, permitindo um melhor uso dos índices e geralmente possuem melhores características de desempenho.

Além disso, da perspectiva de um testador, usuário ou desenvolvedor que trabalha com o aplicativo, o uso de um ID em um GUID melhorará significativamente a comunicação. Imagine ter que ler um GUID por telefone.

No final, a menos que um cluster de grande escala ou URLs ofuscantes seja um requisito, é mais pragmático usar IDs de incremento automático.

Eu diria que não, não use GUIDs como chaves primárias. Atualmente, estou lidando com esse banco de dados e eles são uma das principais causas de problemas de desempenho.

Os 12 bytes extras são adicionados rapidamente; lembre-se, a maioria dos PKs serão FKs em outras tabelas, e apenas três FKs em uma tabela agora têm 48 bytes extras para cada linha. Isso se soma na tabela e nos índices. Ele também é adicionado à E / S do disco. Esses 12 bytes extras precisam ser lidos e gravados.

E se você não estiver usando guias seqüenciais e as PKs estiverem agrupadas (o que acontece por padrão), o SQL precisará, periodicamente, mover páginas inteiras de dados para espremer mais no "local" certo. Para um banco de dados de transações altamente com muitas inserções, atualizações e exclusões, as coisas atolam rapidamente.

Se você precisar de algum tipo de identificador exclusivo para sincronização ou algo assim, adicione uma coluna guid. Apenas não faça o PK.

Person p1 = new Person();
p1.ID=GUID.NewGUID();
PersonRepository.Insert(p1);

Esse é de longe o motivo mais importante para o uso de GUIDs.

O fato de você poder criar um ID exclusivo sem que seu código conheça ou se comunique com a camada de persistência é um grande benefício.

Você pode ter certeza de que o objeto Person que você acabou de gerar em seu servidor, telefone pc, laptop, dispositivo offline ou o que for único em todos os seus servidores em todo o mundo está distribuído.

Você pode colocá-lo em qualquer tipo de banco de dados rdb ou no-sql, arquivo, enviá-lo para qualquer serviço da web ou jogá-lo fora imediatamente como desnecessário

Não, você nunca terá uma colisão.

Sim, as inserções podem ser um pouco mais lentas, pois pode ser necessário mexer no índice.

Sim, é maior que um int.

• editar. teve que disparar antes de terminar.

Sei que muitas pessoas se sentem fortemente com as incidentes automobilísticos e esse é um tópico controverso com os DBAs

Mas eu realmente não posso afirmar com força suficiente como guias superiores são. Você deve usar guias por padrão em qualquer aplicativo.

auto inc ints tem muitas falhas

• Você usa um banco de dados distribuído No-Sql. Você simplesmente não pode conversar com todas as outras instâncias para descobrir qual é o próximo número.

• Você usa um sistema de fila de mensagens. As coisas precisam de IDs antes de atingirem o banco de dados

• Você está criando vários itens e editando-os antes de salvar. Cada um precisa de um ID antes de acessar o banco de dados

• Você deseja excluir e reinserir linhas. Certifique-se de não contar seus IDs de auto inc e acabar!

• Você deseja não expor quantos pedidos você recebeu este ano a todos os usuários

• Você deseja mover dados anônimos da produção para testar e manter os relacionamentos intactos. Mas não exclua todos os dados de teste existentes.

• Você deseja mesclar seu produto de inquilino único em um banco de dados multilocatário, mas todos têm um pedido 56.

• Você cria objetos que são persistentes, mas efêmeros. (pedidos incompletos) novamente, não use todas as suas entradas com coisas que não existem mais.

A lista é interminável e todos são problemas reais que acontecem com as pessoas o tempo todo. diferente de ficar sem espaço em disco por causa de colunas FK um pouco maiores

Finalmente, o grande problema com as ints é que você as esgotou !!! ok, em teoria, você não tem, há um monte. Mas, na prática, você o faz porque as pessoas não os tratam como números aleatórios sem significado. eles fazem coisas como

• ah, não quero que os clientes pensem que somos novos. começar às 10.000

• Eu tive que importar uma carga de dados, então eu apenas subi a semente para 1m para sabermos o que é importado

• precisamos de categorias de dados. todo período começa no próximo milhão, para que possamos usar os primeiros dígitos como um número mágico

• Excluí e reimportei todos os dados novamente com novos IDs. Sim, mesmo os logs de auditoria.

• use esse número, que é uma chave composta, como o ID dessa outra coisa

Percebo que esses GUIDs são usados ​​para identificar objetos no nível do aplicativo. Eles também são armazenados como a chave primária no nível do banco de dados.

É aí que você deve parar, ali mesmo, e repensar.

A chave primária do banco de dados NUNCA deve ter significado comercial. Deve ser sem sentido por definição.

Portanto, adicione o GUID como sua chave comercial e uma chave primária normal (geralmente uma longa int) como chave primária do banco de dados. Você sempre pode colocar um índice exclusivo no GUID para garantir a exclusividade.

Isso está falando da teoria do banco de dados, é claro, mas também é uma boa prática. Eu lidei com bancos de dados em que as chaves primárias tinham significado comercial (um cliente pensou em economizar alguns recursos do banco de dados usando-os como números de funcionários, números de clientes, etc. etc., por exemplo) e isso sempre gera problemas.

Sempre use chaves primárias (PKs) com incremento automático de banco de dados.

Por que usar o incremento automático em vez do GUID / UUID?

• GUID (UUID) s não impedem colisões de chaves, pois não são únicas e não há como torná-las únicas, pois são geradas a partir de várias fontes.
• Os GUIDs não ajudam na mesclagem, pois aumentam bastante o processo de mesclagem que já consome tempo, com colunas PK e FK extremamente longas e não inteiras que levam muito tempo para serem processadas. Lembre-se de que para a maioria das PKs, haverá pelo menos uma outra tabela com pelo menos 2 chaves do mesmo tamanho: é PK própria e uma FK de volta à primeira tabela. Tudo precisa ser resolvido em uma mesclagem.

Mas como lidar com cacos, cachos, etc.?

• Crie PKs de várias colunas compostas de colunas separadas, identificando cada fragmento / cluster / banco de dados / o que quer que gere suas próprias chaves de incremento automático. Por exemplo...

Uma PK de 3 colunas para uma tabela em cluster pode ser ...

 DB | SH | KEY     |
----|----|---------|
 01 | 01 | 1234567 |

Mas e quanto ...?

• Várias viagens ao banco de dados - a maioria dos aplicativos não precisa identificar exclusivamente um registro que está sendo criado até que ele seja inserido no banco de dados desde o encadeamento / sessão / o que estiver funcionando apenas um por vez. Se o aplicativo realmente precisar dessa capacidade, use um PK temporário gerado pelo aplicativo que não seja enviado ao banco de dados . Deixe o banco de dados colocar seu próprio PK de incremento automático na linha quando for inserido. As inserções usarão a PK temporária, enquanto as atualizações e exclusões usarão a PK permanente atribuída pelo banco de dados.

• Desempenho - Os computadores podem processar números inteiros simples muito mais rapidamente do que qualquer outra coisa, devido ao valor muito maior do domínio, se possível, por elemento em um GUID (37) versus um número inteiro (10). Lembre-se também de que cada caractere em um GUID deve primeiro ser convertido em um número a ser manipulado pela CPU.

Os usos indevidos comuns de chaves primárias PKs têm apenas um objetivo ... identificar absolutamente exclusivamente uma linha em uma tabela. Qualquer outra coisa é um mau uso muito comum.

Detectando registros ausentes

• Os registros ausentes não podem ser detectados observando as PKs. Abençoe o controle de qualidade por pelo menos tentar garantir a qualidade dos dados. No entanto, eles e a falta de compreensão do programador sobre como as chaves nos sistemas modernos de banco de dados são atribuídos muitas vezes os levam a acreditar que um número ausente em um PK com incremento automático significa dados ausentes. Ele faz não porque ...
• Para desempenho, os sistemas de banco de dados alocam blocos de números em 'sequências' (lotes, intervalos) para minimizar as viagens ao banco de dados real no armazenamento. O tamanho dessas seqüências de números geralmente está sob o controle do DBA, mas pode não ser ajustado em uma base por tabela.
• O principal argumento é ... números não utilizados dessas seqüências nunca são retornados ao banco de dados, portanto sempre existem lacunas nos números PK.
• Por que haveria números não utilizados que você pergunta? Porque uma variedade de ações de manutenção do banco de dados pode fazer com que as seqüências sejam abandonadas. São coisas como reinicializações, recarregamentos em massa de tabelas, alguns tipos de restauração de backups e outras operações.

Classificação

• A classificação por PK é muito suscetível a erros, pois a maioria das pessoas pensa que lista as linhas na ordem em que foram criadas e que corresponde à hora do relógio. Principalmente, mas não necessariamente.
• Os mecanismos de banco de dados são otimizados para obter o desempenho máximo e isso pode significar atrasar a inserção dos resultados de uma transação complicada de longa duração para inserir pequenas e simples, "fora de curva", por assim dizer.

Como qualquer coisa, há vantagens e desvantagens em fazer isso:

O bom:

1. Suas chaves têm sempre o mesmo comprimento (bancos de dados muito grandes podem ter chaves muito grandes)

2. A exclusividade é praticamente garantida - mesmo quando você as está gerando em um sistema separado e / ou não leu o último ID do banco de dados

O mal:

1. Como mencionado muito acima - índices maiores e armazenamento de dados.

2. Você não pode solicitar por ID, mas por outra coisa. Mais índices, provavelmente menos eficientes.

3. Eles são menos legíveis por humanos. Inteiros geralmente são mais fáceis de analisar, lembrar e digitar para as pessoas. Usar GUIDs como IDs nas cláusulas WHERE em várias tabelas unidas pode fazer sua cabeça derreter.

Como tudo, use-os quando apropriado, não seja dogmático - em muitas situações, números inteiros com auto-incremento são melhores, às vezes os GUIDs são ótimos.

Sim, você pode usar o GUID como chave primária. O lado negativo é o tamanho e a rápida fragmentação do índice.

A menos que você precise de exclusividade nos bancos de dados (por exemplo, um cluster), é preferível um número inteiro.

Aqui está minha opinião sobre esse problema - a solução é uma casa intermediária entre os valores GUID e int, aproveitando o melhor de ambos.

A classe gera um valor de ID pseudo-aleatório (mas aumentando ao longo do tempo), que é semelhante a um GUID Comb .

A principal vantagem é que ele permite que os valores de ID sejam gerados no cliente, em vez de usar valores de incremento automático gerados no servidor (o que requer uma ida e volta) com risco quase zero de valores duplicados.

Os valores gerados usam apenas 8 bytes em vez de 16 para um GUID e não dependem de uma ordem de classificação de banco de dados específica (por exemplo, Sql Server for GUIDs ). Os valores podem ser expandidos para usar todo o longo período não assinado, mas isso causaria problemas em qualquer banco de dados ou outro repositório de dados que possuísse apenas tipos de números inteiros assinados.

public static class LongIdGenerator
{
    // set the start date to an appropriate value for your implementation 
    // DO NOT change this once any application that uses this functionality is live, otherwise existing Id values will lose their implied date
    private static readonly DateTime PeriodStartDate = new DateTime(2017, 1, 1, 0, 0, 0, DateTimeKind.Utc);
    private static readonly DateTime PeriodEndDate = PeriodStartDate.AddYears(100);
    private static readonly long PeriodStartTicks = PeriodStartDate.Ticks;
    private static readonly long PeriodEndTicks = PeriodEndDate.Ticks;
    private static readonly long TotalPeriodTicks = PeriodEndTicks - PeriodStartTicks;

    // ensures that generated Ids are always positve
    private const long SEQUENCE_PART_PERMUTATIONS = 0x7FFFFFFFFFFF; 

    private static readonly Random Random = new Random();

    private static readonly object Lock = new object();
    private static long _lastSequencePart;

    public static long GetNewId()
    {
        var sequencePart = GetSequenceValueForDateTime(DateTime.UtcNow);

        // extra check, just in case we manage to call GetNewId() twice before enough ticks have passed to increment the sequence 
        lock (Lock)
        {
            if (sequencePart <= _lastSequencePart)
                sequencePart = _lastSequencePart + 1;

            _lastSequencePart = sequencePart;
        }

        // shift so that the sequence part fills the most significant 6 bytes of the result value
        sequencePart = (sequencePart << 16);

        // randomize the lowest 2 bytes of the result, just in case two different client PCs call GetNewId() at exactly the same time
        var randomPart = Random.Next() & 0xFFFF;

        return sequencePart + randomPart;
    }

    // used if you want to generate an Id value for a historic time point (within the start and end dates)
    // there are no checks, compared to calls to GetNewId(), but the chances of colliding values are still almost zero
    public static long GetIdForDateTime(DateTime dt)
    {
        if (dt < PeriodStartDate || dt > PeriodStartDate)
            throw new ArgumentException($"value must be in the range {PeriodStartDate:dd MMM yyyy} - {PeriodEndDate:dd MMM yyyy}");

        var sequencePart = GetSequenceValueForDateTime(dt.ToUniversalTime());
        var randomPart = Random.Next() & 0xFFFF;
        return ( sequencePart << 16 ) + randomPart;
    }

    // Get a 6 byte sequence value from the specified date time - startDate => 0 --> endDate => 0x7FFFFFFFFFFF
    // For a 100 year time period, 1 unit of the sequence corresponds to about 0.022 ms
    private static long GetSequenceValueForDateTime(DateTime dt)
    {
        var ticksFromStart = dt.ToUniversalTime().Ticks - PeriodStartTicks;
        var proportionOfPeriod = (decimal)ticksFromStart / TotalPeriodTicks;
        var result = proportionOfPeriod * SEQUENCE_PART_PERMUTATIONS;
        return (long)result;
    }

    public static DateTime GetDateTimeForId(long value)
    {
        // strip off the random part - the two lowest bytes
        var timePart = value >> 16;
        var proportionOfTotalPeriod = (decimal) timePart / SEQUENCE_PART_PERMUTATIONS;
        var ticks = (long)(proportionOfTotalPeriod * TotalPeriodTicks);
        var result = PeriodStartDate.AddTicks(ticks);
        return result;
    }
}