Nie wyczerpie się.
Maksymalny bigint to 9223372036854775807 . Przy 1000 wstawek na sekundę to 106751991167 dni. Prawie 300 milionów lat, jeśli mam rację.
Nawet jeśli podzielisz to, używając przesunięć, gdzie powiedzmy 100 serwerów każdy ma dedykowany podzakres wartości (x*100+0 ... x*100+99 ), nie zabraknie ci. 10 000 maszyn wykonujących 100 000 wstawek na sekundę może dotrzeć tam za około trzy stulecia. Oczywiście to więcej transakcji na sekundę niż giełda nowojorska od setek lat solidnie...
Jeśli tak przekroczyć limit rozmiaru typu danych wygenerowanego klucza, nowe wstawienia nie powiodą się. W PostgreSQL (ponieważ oznaczyłeś ten PostgreSQL) za pomocą bigserial zobaczysz:
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)
Dla zwykłego serial otrzymasz inny błąd, ponieważ sequence jest zawsze 64-bitowy, więc dojdziesz do punktu, w którym musisz zmienić typ klucza na bigint lub otrzymaj błąd taki jak:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Jeśli naprawdę wierzysz, że Twoja witryna może osiągnąć limit bigint w Twojej aplikacji, możesz użyć klucza złożonego — powiedzmy (shard_id, subkey) — lub klucza uuid.
Próba poradzenia sobie z tym w nowej aplikacji to przedwczesna optymalizacja. Poważnie, od nowej aplikacji do tego rodzaju wzrostu, czy będziesz używać tego samego schematu? Lub silnik bazy danych? A może nawet baza kodu?
Równie dobrze możesz martwić się o kolizje GUID w systemach z kluczem GUID. W końcu paradoks urodzin oznacza, że kolizje z identyfikatorami GUID są bardziej prawdopodobne, niż myślisz - w niewiarygodnie, szalenie mało prawdopodobne.
Co więcej, jak wskazuje Barry Brown w komentarzach, nigdy nie będziesz przechowywać tak dużej ilości danych. Dotyczy to tylko stołów o dużej churn z niesamowicie wysokimi wskaźnikami transakcji. W tych tabelach aplikacja musi po prostu poradzić sobie z resetowaniem klucza do zera, przenumerowaniem wpisów lub innymi strategiami radzenia sobie. Szczerze mówiąc, nawet tabela kolejki wiadomości o dużym natężeniu ruchu nie będzie się kończyć.
Zobacz:
Poważnie, nawet jeśli zbudujesz następny Gootwitfacegram, nie będzie to stanowiło problemu, dopóki nie minie data ważności trzeciego przepisania aplikacji...
