Den løber ikke tør.
Den maksimale bigint er 9223372036854775807. Ved 1000 indstik/sekund er det 106751991167 dage værd. Næsten 300 millioner år, hvis min matematik er rigtig.
Selv hvis du partitionerer det ud, ved hjælp af offsets, hvor f.eks. 100 servere hver har et dedikeret underområde af værdierne (x*100+0 ... x*100+99 ), kommer du ikke til at løbe tør. 10.000 maskiner, der laver 100.000 indsatser/sekund, kan få dig derhen om cirka tre århundreder. Selvfølgelig er det flere transaktioner i sekundet end New York Stock Exchange i hundreder af år solidt...
Hvis du gør overskrider datatypestørrelsesgrænsen for den genererede nøgle, vil nye indsættelser mislykkes. I PostgreSQL (da du har tagget denne PostgreSQL) med en bigserial du vil se:
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)
For en almindelig serial du får en anden fejl, fordi sequence er altid 64-bit, så du når det punkt, hvor du skal ændre nøgletypen til bigint eller få en fejl som:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Hvis du virkelig tror på, at det er muligt for dit websted at nå grænsen for en bigint i din applikation, kan du bruge en sammensat nøgle - f.eks (shard_id, undernøgle) - eller en uuid-nøgle.
At forsøge at håndtere dette i en ny applikation er for tidlig optimering. Seriøst, fra en ny applikation til den slags vækst, vil du bruge det samme skema? Eller databasemotor? Eller endda kodebase?
Du kan lige så godt bekymre dig om GUID-kollisioner i GUID-nøglesystemer. Fødselsdagsparadokset betyder trods alt, at GUID-kollisioner er mere sandsynlige, end du tror - på utroligt, sindssygt usandsynligt.
Desuden, som Barry Brown påpeger i kommentarerne, vil du aldrig gemme så meget data. Dette er kun en bekymring for høje churn-tabeller med sindssygt høje transaktionsrater. I disse tabeller skal applikationen blot være i stand til at klare nøglen nulstillet, indtastninger omnummereret eller andre håndteringsstrategier. Ærligt talt, men selv en meddelelseskø med høj trafik kommer ikke til at toppe.
Se:
Seriøst, selvom du bygger det næste Gootwitfacegram, vil dette ikke være et problem, før langt efter sidste anvendelsesdato for din tredje applikationsomskrivning...