Няма да свърши.
Максималният bigint е 9223372036854775807. При 1000 вмъквания/секунда това струва 106751991167 дни. Почти 300 милиона години, ако математиката ми е вярна.
Дори ако го разделите, като използвате отмествания, където да речем 100 сървъра имат отделен поддиапазон от стойности (x*100+0 ... x*100+99 ), няма да свършите. 10 000 машини, извършващи 100 000 вмъквания в секунда, може да ви отведат дотам за около три века. Разбира се, това са повече транзакции в секунда от Нюйоркската фондова борса за стотици години...
Ако направите превишава ограничението за размер на типа данни на генерирания ключ, новите вмъквания няма да бъдат успешни. В PostgreSQL (тъй като сте маркирали този PostgreSQL) с bigserial ще видите:
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)
За обикновен serial ще получите различна грешка, защото sequence винаги е 64-битов, така че ще стигнете до момента, в който трябва да промените типа ключ на bigint или да получите грешка като:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Ако наистина вярвате, че е възможно вашият сайт да достигне ограничението за bigint във вашето приложение, можете да използвате съставен ключ – да речем (shard_id, subkey) – или uuid ключ.
Опитът да се справим с това в ново приложение е преждевременна оптимизация. Сериозно, от ново приложение до този вид растеж, ще използвате ли същата схема? Или база данни? Или дори кодова база?
Може също да се притеснявате за сблъсъци на GUID в системи с GUID ключ. В крайна сметка парадоксът на рождения ден означава, че сблъсъци с GUID са по-вероятни, отколкото си мислите - при невероятно, безумно малко вероятно.
Освен това, както посочва Бари Браун в коментарите, никога няма да съхранявате толкова много данни. Това е повод за безпокойство само за маси с висок отлив с безумно високи проценти на транзакции. В тези таблици приложението просто трябва да може да се справи с нулиране на ключа, преномериране на записи или други стратегии за справяне. Честно казано обаче, дори таблица с опашка за съобщения с висок трафик няма да надмине.
Вижте:
Сериозно, дори ако изградите следващата Gootwitfacegram, това няма да е проблем до изтичане на срока на годност на третото ви пренаписване на приложението...
