Tidak akan habis.
Bigint maksimum adalah 9223372036854775807 . Pada 1000 sisipan/detik itu bernilai 106751991167 hari. Hampir 300 juta tahun, jika matematika saya benar.
Bahkan jika Anda mempartisinya, menggunakan offset di mana katakanlah 100 server masing-masing memiliki sub-rentang nilai khusus (x*100+0 ... x*100+99 ), Anda tidak akan kehabisan. 10.000 mesin yang melakukan 100.000 penyisipan/detik mungkin akan membawa Anda ke sana dalam waktu sekitar tiga abad. Tentu saja, itu lebih banyak transaksi per detik daripada Bursa Efek New York selama ratusan tahun solid...
Jika Anda melakukannya melebihi batas ukuran tipe data dari kunci yang dihasilkan, sisipan baru akan gagal. Di PostgreSQL (karena Anda telah menandai PostgreSQL ini) dengan bigserial Anda akan melihat:
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)
Untuk serial biasa Anda akan mendapatkan kesalahan yang berbeda, karena sequence selalu 64-bit, jadi Anda akan mencapai titik di mana Anda harus mengubah jenis kunci menjadi bigint atau mendapatkan kesalahan seperti:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Jika Anda benar-benar yakin bahwa situs Anda mungkin mencapai batas bigint dalam aplikasi Anda, Anda dapat menggunakan kunci komposit - katakanlah (shard_id, subkunci) - atau kunci uuid.
Mencoba menangani ini dalam aplikasi baru adalah optimasi prematur. Serius, dari aplikasi baru hingga pertumbuhan semacam itu, apakah Anda akan menggunakan skema yang sama? Atau mesin basis data? Atau bahkan basis kode?
Anda mungkin juga khawatir tentang tabrakan GUID dalam sistem kunci GUID. Lagi pula, paradoks ulang tahun berarti bahwa tabrakan GUID lebih mungkin terjadi daripada yang Anda pikirkan - sangat, sangat tidak mungkin.
Lebih jauh, seperti yang ditunjukkan Barry Brown dalam komentar, Anda tidak akan pernah menyimpan data sebanyak itu. Ini hanya masalah untuk tabel churn tinggi dengan tingkat transaksi yang sangat tinggi. Dalam tabel tersebut, aplikasi hanya perlu mampu mengatasi kunci yang disetel ulang ke nol, entri dinomori ulang, atau strategi penanganan lainnya. Sejujurnya, bahkan tabel antrian pesan lalu lintas tinggi tidak akan menjadi yang teratas.
Lihat:
Serius, bahkan jika Anda membuat Gootwitfacegram berikutnya, ini tidak akan menjadi masalah sampai melewati tanggal penggunaan dari penulisan ulang aplikasi ketiga Anda...
