Nedojde.
Maximální bigint je 9223372036854775807. Při 1000 vloženích za sekundu to znamená 106751991167 dní. Téměř 300 milionů let, pokud je moje matematika správná.
I když to rozdělíte, použijte offsety, kde řekněme 100 serverů má každý vyhrazený podrozsah hodnot (x*100+0 ... x*100+99 ), nedojde vám. 10 000 strojů provádějících 100 000 břitových destiček za sekundu by vás tam mohlo dostat přibližně za tři století. To je samozřejmě více transakcí za sekundu než na newyorské burze cenných papírů za stovky let...
Pokud uděláte překročíte limit velikosti datového typu vygenerovaného klíče, nové vložení se nezdaří. V PostgreSQL (od té doby, co jste tento PostgreSQL označili) s bigserial uvidíte:
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)
Pro obyčejný serial dostanete jinou chybu, protože sequence je vždy 64bitový, takže se dostanete do bodu, kdy budete muset změnit typ klíče na bigint nebo se zobrazí chyba jako:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Pokud skutečně věříte, že je možné, aby vaše stránky dosáhly limitu na bigint ve vaší aplikaci, můžete použít složený klíč – řekněme (shard_id, podklíč) – nebo klíč uuid.
Snažit se s tím vypořádat v nové aplikaci je předčasná optimalizace. Vážně, od nové aplikace po tento druh růstu, budete používat stejné schéma? Nebo databázový stroj? Nebo dokonce codebase?
Můžete se také obávat kolize GUID v systémech s klíčem GUID. Ostatně narozeninový paradox znamená, že kolize GUID jsou pravděpodobnější, než si myslíte - neuvěřitelně, šíleně nepravděpodobné.
Navíc, jak zdůrazňuje Barry Brown v komentářích, nikdy neuložíte tolik dat. To se týká pouze tabulek s vysokou mírou odchodu lidí s šíleně vysokou mírou transakcí. V těchto tabulkách se aplikace pouze musí umět vyrovnat s resetováním klíče na nulu, přečíslováním položek nebo jinými strategiemi zvládání. Upřímně řečeno, ani tabulka fronty zpráv s vysokým provozem nedosáhne vrcholu.
Viz:
Vážně, i když vytvoříte další Gootwitfacegram, nebude to problém, dokud nepřekročí datum použitelnosti vašeho třetího přepsání aplikace...