Não vai acabar.
O bigint máximo é 9223372036854775807 . A 1.000 inserções/segundo, isso vale 106751991167 dias. Quase 300 milhões de anos, se minha matemática estiver certa.
Mesmo se você particionar, usando deslocamentos onde digamos 100 servidores cada um tem um sub-intervalo dedicado dos valores (
x*100+0 ... x*100+99 ), você não vai ficar sem. 10.000 máquinas fazendo 100.000 inserções/segundo podem chegar lá em cerca de três séculos. Claro, isso é mais transações por segundo do que a Bolsa de Valores de Nova York por centenas de anos sólidos... Se você faz exceder o limite de tamanho do tipo de dados da chave gerada, novas inserções falharão. No PostgreSQL (desde que você marcou este PostgreSQL) com um
bigserial Você vai ver:CREATE TABLE bigserialtest ( id bigserial primary key, dummy text );
SELECT setval('bigserialtest_id_seq', 9223372036854775807);
INSERT INTO bigserialtest ( dummy ) VALUES ('spam');
ERROR: nextval: reached maximum value of sequence "bigserialtest_id_seq" (9223372036854775807)
Para um
serial comum você receberá um erro diferente, porque a sequence é sempre de 64 bits, então você chegará ao ponto em que terá que alterar o tipo de chave para bigint ou obter um erro como:regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Se você realmente acredita que é possível que seu site atinja o limite de um bigint em seu aplicativo, você pode usar uma chave composta - digamos (shard_id, subkey) - ou uma chave uuid.
Tentar lidar com isso em um novo aplicativo é uma otimização prematura. Sério, de um novo aplicativo para esse tipo de crescimento, você vai usar o mesmo esquema? Ou mecanismo de banco de dados? Ou mesmo base de código?
Você também pode se preocupar com colisões de GUID em sistemas com chave GUID. Afinal, o paradoxo do aniversário significa que colisões de GUID são mais prováveis do que você pensa - em incrivelmente, insanamente improvável.
Além disso, como Barry Brown aponta nos comentários, você nunca armazenará tantos dados. Esta é apenas uma preocupação para tabelas de alta rotatividade com taxas de transação insanamente altas. Nessas tabelas, o aplicativo só precisa ser capaz de lidar com a chave sendo redefinida para zero, as entradas renumeradas ou outras estratégias de enfrentamento. Honestamente, porém, mesmo uma tabela de filas de mensagens de alto tráfego não vai chegar ao topo.
Ver:
Sério, mesmo se você construir o próximo Gootwitfacegram, isso não será um problema até muito além da data de validade da sua terceira reescrita de aplicativo...
