No se agotará.
El bigint máximo es 9223372036854775807 . A 1000 inserciones/segundo, eso equivale a 106751991167 días. Casi 300 millones de años, si mis cálculos son correctos.
Incluso si lo divide, use compensaciones donde, digamos, 100 servidores tienen cada uno un subrango dedicado de los valores (x*100+0 ... x*100+99 ), no te vas a quedar sin. 10 000 máquinas que hacen 100 000 inserciones por segundo podrían llevarlo allí en unos tres siglos. Por supuesto, son más transacciones por segundo que la Bolsa de Valores de Nueva York durante cientos de años...
Si haces exceda el límite de tamaño del tipo de datos de la clave generada, las nuevas inserciones fallarán. En PostgreSQL (ya que ha etiquetado este PostgreSQL) con un bigserial verás:
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 un serial ordinario obtendrá un error diferente, porque la sequence siempre es de 64 bits, por lo que llegará al punto en el que tendrá que cambiar el tipo de clave a bigint o recibe un error como:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Si realmente cree que es posible que su sitio alcance el límite de un bigint en su aplicación, podría usar una clave compuesta, digamos (shard_id, subclave), o una clave uuid.
Tratar de lidiar con esto en una nueva aplicación es una optimización prematura. En serio, desde una nueva aplicación hasta ese tipo de crecimiento, ¿usarás el mismo esquema? O motor de base de datos? ¿O incluso código base?
También podría preocuparse por las colisiones de GUID en los sistemas con clave GUID. Después de todo, la paradoja del cumpleaños significa que Las colisiones de GUID son más probables de lo que piensas - en increíblemente, increíblemente improbable.
Además, como señala Barry Brown en los comentarios, nunca almacenará tantos datos. Esto es solo una preocupación para las tablas de abandono alto con tasas de transacción increíblemente altas. En esas tablas, la aplicación solo necesita ser capaz de hacer frente a la clave que se restablece a cero, las entradas se vuelven a numerar u otras estrategias de afrontamiento. Sin embargo, honestamente, incluso una tabla de cola de mensajes de alto tráfico no va a llegar al tope.
Ver:
- esta información de IBM sobre el agotamiento en serie
- Una publicación de blog reciente sobre este tema
En serio, incluso si construyes el próximo Gootwitfacegram, esto no será un problema hasta mucho después de la fecha de caducidad de la reescritura de tu tercera aplicación...
