Il ne s'épuisera pas.
Le bigint maximum est 9223372036854775807 . À 1000 insertions/seconde, cela équivaut à 106751991167 jours. Près de 300 millions d'années, si mes calculs sont bons.
Même si vous le partitionnez, utilisez des décalages où, disons, 100 serveurs ont chacun une sous-gamme dédiée des valeurs (x*100+0 ... x*100+99 ), vous n'allez pas en manquer. 10 000 machines réalisant 100 000 insertions/seconde pourraient vous permettre d'y parvenir en trois siècles environ. Bien sûr, c'est plus de transactions par seconde que la Bourse de New York depuis des centaines d'années...
Si vous faites dépassez la taille limite du type de données de la clé générée, les nouvelles insertions échoueront. Dans PostgreSQL (puisque vous avez balisé ce PostgreSQL) avec un bigserial vous verrez :
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)
Pour un serial ordinaire vous obtiendrez une erreur différente, car la sequence est toujours 64 bits, vous atteindrez donc le point où vous devrez changer le type de clé en bigint ou obtenir une erreur comme :
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Si vous pensez vraiment qu'il est possible que votre site atteigne la limite d'un bigint dans votre application, vous pouvez utiliser une clé composite - disons (shard_id, subkey) - ou une clé uuid.
Essayer de gérer cela dans une nouvelle application est une optimisation prématurée. Sérieusement, d'une nouvelle application à ce type de croissance, utiliserez-vous le même schéma ? Ou moteur de base de données ? Ou même codebase ?
Vous pourriez aussi bien vous inquiéter des collisions GUID dans les systèmes à clé GUID. Après tout, le paradoxe de l'anniversaire signifie que les collisions GUID sont plus probables que vous ne le pensez - à incroyablement, incroyablement improbable.
De plus, comme le souligne Barry Brown dans les commentaires, vous ne stockerez jamais autant de données. Ce n'est un problème que pour les tables à taux de désabonnement élevé avec des taux de transaction incroyablement élevés. Dans ces tables, l'application doit juste être capable de faire face à la remise à zéro de la clé, à la renumérotation des entrées ou à d'autres stratégies d'adaptation. Honnêtement, cependant, même une table de file d'attente de messages à fort trafic ne va pas dépasser.
Voir :
Sérieusement, même si vous construisez le prochain Gootwitfacegram, ce ne sera pas un problème jusqu'à bien après la date de péremption de votre troisième réécriture d'application...
