Ferramentas para desenvolvedores · Gerador UUID
ULID, Snowflake, KSUID e UUIDv7: IDs classificáveis comparados
· Fundo
uuid criptografia APIs do navegador
UUIDs aleatórios não são classificados por hora de criação, portanto, vários formatos colocam um carimbo de data/hora primeiro. Esta postagem compara ULID, Snowflake, KSUID e UUIDv7 em layout, tamanho, monotonicidade e compatibilidade.
IDs aleatórios e o índice que os odeia — o problema que os identificadores ordenados por tempo resolvem
UUIDs aleatórios v4 espalham pontos de inserção em uma chave primária de árvore B conforme novos registros chegam, causando divisões e reorganização de páginas. Inserções em posições aleatórias degradam o desempenho de gravação e aumentam significativamente a fragmentação do disco. Os bancos de dados de alto rendimento toleram esse custo – o preço de identificadores verdadeiramente independentes e descoordenados – mas o custo é real. Se você precisar de UUIDs para classificar por hora de criação, poderá melhorar drasticamente as características do índice adicionando um prefixo de carimbo de data/hora. Vários formatos surgiram: ULID, Snowflake, KSUID e RFC 9562 v7. Cada um faz compensações diferentes em tamanho (26 caracteres para 128 bits), precisão do carimbo de data/hora (segundos a nanossegundos), compatibilidade de UUID e se a coordenação do gerador de ID requer centralização. Os benchmarks de banco de dados mostram que o desempenho de inserção melhora significativamente.
ULID — um carimbo de data/hora de milissegundos de 48 bits mais 80 bits aleatórios em 26 caracteres Crockford base32, com uma opção monotônica
ULID (Identificador lexicograficamente classificável universalmente exclusivo) codifica um carimbo de data / hora de milissegundos de 48 bits e uma carga útil aleatória de 80 bits em 26 caracteres de Crockford base32. A representação do texto é classificada corretamente em ordem lexicográfica, tornando os ULIDs adequados para sistemas onde a ordenação e a legibilidade do carimbo de data/hora são importantes – processamento de log, rastreamento distribuído, microsserviços onde os identificadores precisam ser facilmente legíveis na saída humana. ULID oferece uma variante monotônica em que vários identificadores gerados no mesmo milissegundo incrementam a parte aleatória em vez de repetir, garantindo que mesmo rajadas rápidas de ID mantenham uma ordem de geração estrita. A desvantagem é que ULID não é um UUID: ele não cabe em uma coluna de banco de dados UUID padrão de 128 bits sem conversão de codificação. A precisão de ULID cobre aproximadamente 8925 anos.
Snowflake — IDs de 64 bits de um carimbo de data/hora, um ID de trabalhador e uma sequência, e a coordenação necessária
Snowflake é um identificador de 64 bits originalmente projetado pelo Twitter, estruturado como um carimbo de data / hora de milissegundos de 41 bits, um ID de trabalhador de 10 bits e um número de sequência de 12 bits. O carimbo de data/hora de 41 bits cobre aproximadamente 69 anos e transborda em 2106, exigindo coordenação de época e planejamento de migração. O ID do trabalhador distingue identificadores gerados por diferentes servidores ou processos – cada gerador Snowflake deve conhecer seu próprio ID de trabalhador exclusivo sem entrar em conflito com outros. Snowflake é 64 bits em vez de 128, tornando-o metade do tamanho de um UUID, mais rápido para indexar e mais eficiente em armazenamento por identificador. Ele classifica por hora e ID do trabalhador, útil para rotear solicitações ou logs por origem. A desvantagem é operacional: cada gerador deve receber um ID de trabalhador, os relógios devem ser mantidos sincronizados.
KSUID — um carimbo de data/hora de segundos com uma grande carga aleatória, classificada como bytes
KSUID (K-Sortable Unique Identifier) é um identificador de 128 bits que consiste em um segundo carimbo de data e hora Unix de 32 bits e uma carga útil aleatória de 96 bits, normalmente codificada como caracteres 27 base62. O formato pode ser classificado em ordem lexicográfica e a parte aleatória é criptograficamente correta para seu tamanho. KSUID é menos amplamente adotado do que ULID ou Snowflake, mas oferece semântica distinta: o carimbo de data / hora é facilmente decodificado para um segundo legível por humanos (útil em logs e depuração), e a porção aleatória de 96 bits é grande o suficiente para que vários KSUIDs gerados no mesmo segundo tenham efetivamente zero probabilidade de duplicação sem coordenação de sequência. Ao contrário do Snowflake, KSUID não requer coordenação de ID de trabalhador ou alocação central. KSUID opera em segundos em vez de milissegundos, portanto, vários IDs em um segundo são classificados aleatoriamente, a menos que você implemente lógica adicional.
UUIDv7 — a resposta padrão que se adapta às colunas e ferramentas UUID existentes
RFC 9562 v7 é um identificador de 128 bits que consiste em um carimbo de data / hora Unix de milissegundos de 48 bits, 12 bits de precisão de submilissegundos (utilizável como um contador de sequência) e 62 bits aleatórios, todos combinados. Ele classifica corretamente como uma string lexicográfica e como bytes de 128 bits em bancos de dados. Crucialmente, é um UUID válido - ele define o nibble da versão para 7 e os bits variantes para o padrão RFC 9562, tornando-o compatível com todas as ferramentas, colunas de banco de dados e API que lidam com UUIDs. Nenhuma conversão de codificação é necessária e a infraestrutura UUID existente não requer nenhuma modificação. Se vários identificadores v7 forem gerados no mesmo milissegundo, RFC 9562 recomenda usar o campo submilissegundo como um contador monotônico em vez de bits aleatórios. V7 representa uma escolha pragmática para manter a compatibilidade UUID.
Monotonicidade em um milissegundo — como cada formato lida com rajadas e por que isso é importante para as garantias do pedido
Monotonicidade é a propriedade de que, se dois eventos ocorrerem em ordem observável, seus IDs serão comparados na mesma ordem. Na granularidade de nível de milissegundo em hardware moderno, vários eventos ocorrem rotineiramente no mesmo tique do relógio, portanto, qualquer esquema de ID classificável deve lidar corretamente com a ordem abaixo de milissegundos. ULID oferece um modo monotônico explícito onde a parte aleatória aumenta em vez de randomizar. Snowflake inclui um número de sequência de 12 bits que aumenta em um tique de milissegundos. KSUID não possui um mecanismo integrado, portanto, eventos abaixo de um segundo são classificados aleatoriamente, a menos que lógica adicional seja adicionada. RFC 9562 v7 recomenda usar o campo submilissegundo como um contador monotônico. Se o seu sistema gerar milhares de UUIDs por segundo, a monotonicidade em um milissegundo afetará significativamente a ordem das consultas.
O que isso não cobre: benchmarks de rendimento, que dependem do hardware e da linguagem; a postagem permanece qualitativa
Os benchmarks de rendimento e os dados de desempenho não estão incluídos porque dependem muito da arquitetura de hardware, da implementação da linguagem, do mecanismo de banco de dados e da estratégia de cache. As características de desempenho do banco de dados variam significativamente dependendo se você está medindo inserções aleatórias, consultas de intervalo, sobrecarga de índice ou rendimento total sob carga de produção realista. A postagem permanece qualitativa, comparando formatos conceitualmente com base em seus designs, em vez de fornecer números específicos do ambiente que poderiam ser enganosos. A avaliação de desempenho no mundo real requer testes em seu próprio ambiente com sua própria carga de trabalho, base de código e restrições operacionais. Comparar diferentes formatos de ID é um exercício valioso.
Conclusão: a compatibilidade geralmente decide – o gerador ToolAcre produz UUIDs aleatórios; use sua verificação bem formada para confirmar se um UUIDv7 da sua biblioteca é analisado como UUID
A compatibilidade geralmente decide qual formato escolher. Se o esquema do seu banco de dados já requer colunas UUID, v7 é a resposta moderna para classificação sem sair do ecossistema UUID. Se estiver construindo um novo sistema com tipos de ID personalizados, ULID oferece representação de texto menor e vantagens de precisão de milissegundos. Se você precisa de armazenamento de 64 bits e pode gerenciar a coordenação de ID do trabalhador por meio de alocação centralizada, o Snowflake é uma escolha comprovada em sistemas de alto volume. A compensação fundamental é entre compatibilidade padrão (escolha v7) e propriedades alternativas como tamanho menor (Snowflake) ou legibilidade base32 (ULID). Faça escolhas com base nas restrições do sistema e nas decisões do ecossistema.