यह खत्म नहीं होगा।
अधिकतम बिगिंट 9223372036854775807 है। 1000 इंसर्ट/सेकंड पर जो 106751991167 दिनों के लायक है। लगभग 300 मिलियन वर्ष, यदि मेरा गणित सही है।
यहां तक कि अगर आप इसे विभाजित करते हैं, तो ऑफसेट का उपयोग करते हुए, जहां 100 सर्वरों में से प्रत्येक के पास मूल्यों की एक समर्पित उप-श्रेणी होती है (x*100+0 ... x*100+99 ), आप रन आउट नहीं होंगे। 100,000 इंसर्ट/सेकंड करने वाली 10,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
यदि आप वास्तव में मानते हैं कि आपकी साइट के लिए आपके आवेदन में एक बड़ी सीमा तक पहुंचना संभव है, तो आप एक समग्र कुंजी - जैसे (shard_id, उपकुंजी) - या एक uuid कुंजी का उपयोग कर सकते हैं।
एक नए एप्लिकेशन में इससे निपटने की कोशिश करना समयपूर्व अनुकूलन है। गंभीरता से, एक नए एप्लिकेशन से उस तरह के विकास तक, क्या आप उसी स्कीमा का उपयोग करेंगे? या डेटाबेस इंजन? या कोडबेस भी?
आप GUID कुंजी सिस्टम में GUID टकराव के बारे में भी चिंता कर सकते हैं। आखिरकार, जन्मदिन विरोधाभास का अर्थ है कि GUID टकराव आपके विचार से अधिक होने की संभावना है - अविश्वसनीय रूप से, बेहद असंभव पर।
इसके अलावा, जैसा कि बैरी ब्राउन टिप्पणियों में बताते हैं, आप कभी भी इतना डेटा स्टोर नहीं करेंगे। यह अत्यधिक उच्च लेनदेन दरों के साथ उच्च मंथन तालिकाओं के लिए केवल एक चिंता का विषय है। उन तालिकाओं में, एप्लिकेशन को केवल शून्य पर रीसेट की जाने वाली कुंजी, प्रविष्टियों को फिर से दर्ज करने, या अन्य मुकाबला करने की रणनीतियों का मुकाबला करने में सक्षम होना चाहिए। ईमानदारी से, हालांकि, एक उच्च यातायात संदेश कतार तालिका भी शीर्ष पर नहीं जा रही है।
देखें:
गंभीरता से, भले ही आप अगला गूटविटफेसग्राम बनाते हों, यह तब तक कोई समस्या नहीं होगी जब तक कि आपके तीसरे आवेदन के पुनर्लेखन की उपयोग-दर-तारीख पूरी न हो जाए...
