Non si esaurirà.
Il bigint massimo è 9223372036854775807 . A 1000 inserti/secondo vale 106751991167 giorni. Quasi 300 milioni di anni, se i miei calcoli sono corretti.
Anche se lo si partiziona, utilizzando offset in cui diciamo che 100 server hanno ciascuno un sottointervallo dedicato dei valori (x*100+0 ... x*100+99 ), non ti esaurirai. 10.000 macchine che eseguono 100.000 inserti al secondo potrebbero arrivarci in circa tre secoli. Ovviamente, sono più transazioni al secondo della Borsa di New York per centinaia di anni solidi...
Se fai superare il limite della dimensione del tipo di dati della chiave generata, i nuovi inserimenti avranno esito negativo. In PostgreSQL (dal momento che hai taggato questo PostgreSQL) con un bigserial vedrai:
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)
Per un normale serial riceverai un errore diverso, perché la sequence è sempre a 64 bit, quindi raggiungerai il punto in cui dovrai cambiare il tipo di chiave in bigint o ricevi un errore come:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Se credi davvero che sia possibile per il tuo sito raggiungere il limite di un bigint nella tua applicazione, puoi utilizzare una chiave composita, ad esempio (shard_id, sottochiave) o una chiave uuid.
Cercare di affrontare questo problema in una nuova applicazione è un'ottimizzazione prematura. Seriamente, da una nuova applicazione a quel tipo di crescita, utilizzerai lo stesso schema? O motore di database? O anche codebase?
Potresti anche preoccuparti delle collisioni GUID nei sistemi con chiave GUID. Dopotutto, il paradosso del compleanno significa che Le collisioni GUID sono più probabili di quanto pensi - a incredibilmente, follemente improbabile.
Inoltre, come sottolinea Barry Brown nei commenti, non memorizzerai mai così tanti dati. Questa è solo una preoccupazione per le tabelle di abbandono elevato con tassi di transazione follemente alti. In quelle tabelle, l'applicazione deve solo essere in grado di far fronte alla reimpostazione della chiave su zero, alle voci rinumerate o ad altre strategie di gestione. Onestamente, però, anche una tabella di code di messaggi ad alto traffico non raggiungerà il massimo.
Vedi:
Seriamente, anche se crei il prossimo Gootwitfacegram, questo non sarà un problema fino a molto tempo dopo la data di scadenza della tua terza riscrittura dell'applicazione...
