Es wird nicht ausgehen.
Die maximale Bigint ist 9223372036854775807 . Bei 1000 Einfügungen/Sekunde sind das 106751991167 Tage wert. Fast 300 Millionen Jahre, wenn meine Rechnung stimmt.
Selbst wenn Sie es partitionieren, indem Sie Offsets verwenden, bei denen beispielsweise 100 Server jeweils einen dedizierten Unterbereich der Werte haben (x*100+0 ... x*100+99 ), werden Sie nicht ausgehen. 10.000 Maschinen mit 100.000 Beilagen/Sekunde könnten Sie in etwa drei Jahrhunderten dorthin bringen. Das sind natürlich mehr Transaktionen pro Sekunde als die New Yorker Börse seit Hunderten von Jahren solide...
Wenn Sie tun die Datentypgrößenbeschränkung des generierten Schlüssels überschreiten, schlagen neue Einfügungen fehl. In PostgreSQL (da Sie dieses PostgreSQL getaggt haben) mit einem bigserial Sie werden sehen:
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)
Für eine gewöhnliche serial Sie erhalten einen anderen Fehler, da die sequence ist immer 64-Bit, also erreichen Sie den Punkt, an dem Sie den Schlüsseltyp auf bigint ändern müssen oder erhalte eine Fehlermeldung wie:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Wenn Sie wirklich glauben, dass Ihre Website das Limit für Bigint in Ihrer Anwendung erreichen kann, können Sie einen zusammengesetzten Schlüssel - sagen wir (shard_id, subkey) - oder einen uuid-Schlüssel verwenden.
Der Versuch, dies in einer neuen Anwendung zu bewältigen, ist eine verfrühte Optimierung. Im Ernst, werden Sie von einer neuen Anwendung bis zu dieser Art von Wachstum dasselbe Schema verwenden? Oder Datenbank-Engine? Oder sogar Codebasis?
Sie können sich auch Gedanken über GUID-Kollisionen in Systemen mit GUID-Schlüsseln machen. Schließlich bedeutet das Geburtstagsparadoxon, dass GUID-Kollisionen wahrscheinlicher sind als Sie denken - bei unglaublich, wahnsinnig unwahrscheinlich.
Darüber hinaus werden Sie, wie Barry Brown in den Kommentaren betont, niemals so viele Daten speichern. Dies ist nur ein Problem für High-Churn-Tabellen mit wahnsinnig hohen Transaktionsraten. In diesen Tabellen muss die Anwendung nur in der Lage sein, mit dem Zurücksetzen des Schlüssels auf Null, der Neunummerierung von Einträgen oder anderen Bewältigungsstrategien fertig zu werden. Ehrlich gesagt, wird selbst eine Tabelle mit Nachrichtenwarteschlangen mit hohem Datenverkehr nicht die Obergrenze erreichen.
Siehe:
Im Ernst, selbst wenn Sie das nächste Gootwitfacegram erstellen, wird dies kein Problem sein, bis das Verfallsdatum Ihrer dritten Anwendungsumschreibung weit überschritten ist...
