प्रति दिन 1000 लेकिन <10000 नए रिकॉर्ड को संभालने की आवश्यकता है
GUID / UUIDs, ऑटो वेतन वृद्धि संख्या आदि का उपयोग नहीं कर सकते
आदर्श रूप से 5 या 6 चार्ट लंबा होना चाहिए, निश्चित रूप से अल्फा हो सकता है
यदि उपलब्ध हो तो मौजूदा, प्रसिद्ध अल्गोस का पुन: उपयोग करना चाहेंगे
वहाँ कुछ भी?
जवाबों:
बेस 62 का उपयोग छोटे यूआरएल और संक्षिप्त URL के लिए किया जाता है। यह "अद्वितीय", मानव-पढ़ने योग्य आईडी बनाने के लिए एक अच्छी तरह से समझी गई विधि है। बेशक, आपको विशिष्ट पहचान सुनिश्चित करने के लिए बनाई गई आईडी को स्टोर करना होगा और निर्माण पर डुप्लिकेट की जांच करनी होगी। (जवाब के नीचे कोड देखें)
बेस 62 विशिष्टता मेट्रिक्स
आधार 62 में 5 चार्ट आपको 62 ^ 5 अद्वितीय आईडी = 916,132,832 (~ 1 बिलियन) देगा 10k आईडी पर प्रति दिन आप 91k + दिनों के लिए ठीक होंगे
आधार 62 में 6 चार्ट आपको 62 ^ 6 अद्वितीय आईडी = 56,800,235,584 (56+ बिलियन) प्रति दिन 10k आईडी पर आपको 5+ मिलियन दिनों के लिए ठीक होंगे
बेस 36 विशिष्टता मेट्रिक्स
6 चार्ट आपको 36 ^ 6 अद्वितीय आईडी = 2,176,782,336 (2+ बिलियन) देंगे
7 चार्ट आपको 36 ^ 7 अद्वितीय आईडी = 78,364,164,096 (78+ बिलियन) देंगे
कोड:
public void TestRandomIdGenerator()
{
// create five IDs of six, base 62 characters
for (int i=0; i<5; i++) Console.WriteLine(RandomIdGenerator.GetBase62(6));
// create five IDs of eight base 36 characters
for (int i=0; i<5; i++) Console.WriteLine(RandomIdGenerator.GetBase36(8));
}
public static class RandomIdGenerator
{
private static char[] _base62chars =
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
.ToCharArray();
private static Random _random = new Random();
public static string GetBase62(int length)
{
var sb = new StringBuilder(length);
for (int i=0; i<length; i++)
sb.Append(_base62chars[_random.Next(62)]);
return sb.ToString();
}
public static string GetBase36(int length)
{
var sb = new StringBuilder(length);
for (int i=0; i<length; i++)
sb.Append(_base62chars[_random.Next(36)]);
return sb.ToString();
}
}
आउटपुट:
z5KyMg wd4SUp uSzQtH UPrGAT UIf2IS QCF9GNM5 0UV3TFSS 3MG91VKP 7NTRF10T AJK3AJU7
मैं http://hashids.org/ की सलाह देता हूं जो किसी भी संख्या (जैसे DB ID) को एक स्ट्रिंग (नमक का उपयोग करके) में परिवर्तित करता है।
यह इस स्ट्रिंग को संख्या में वापस डिकोड करने की अनुमति देता है। इसलिए आपको इसे डेटाबेस में संग्रहीत करने की आवश्यकता नहीं है।
JavaScript, Ruby, Python, Java, Scala, PHP, Perl, Swift, Clojure, Objective-C, C, C ++ 11, Go, Erlang, Lua, Elixir, ColdFusion, Groovy, Kotlin, Nim, VBA के लिए libs है। CoffeeScript और Node.js और .NET के लिए।
मुझे ओपी के समान आवश्यकताएं थीं। मैंने उपलब्ध पुस्तकालयों में देखा लेकिन उनमें से अधिकांश यादृच्छिकता पर आधारित हैं और मैं ऐसा नहीं चाहता था। मुझे वास्तव में कुछ भी नहीं मिला जो यादृच्छिक और अभी भी बहुत कम पर आधारित नहीं था ... इसलिए मैंने अपनी खुद की तकनीक फ़्लिकर उपयोग के आधार पर रोलिंग को समाप्त कर दिया , लेकिन कम समन्वय की आवश्यकता के लिए संशोधित किया और लंबे समय तक ऑफ़लाइन रहने की अनुमति दी।
संक्षेप में:
नुकसान:
लाभ
मैंने क्लाइंट पक्ष के लिए एक जावास्क्रिप्ट पुस्तकालय, साथ ही जावा ईई सर्वर कार्यान्वयन दोनों को प्रकाशित किया है। अन्य भाषाओं में सर्वर को लागू करना आसान होना चाहिए।
यहाँ परियोजनाएं हैं:
suid - वितरित सेवा-विशिष्ट आईडी जो छोटी और प्यारी हैं
suid-server-java - जावा EE टेक्नोलॉजी स्टैक के लिए Suid-server कार्यान्वयन।
दोनों पुस्तकालय एक उदार क्रिएटिव कॉमन्स ओपन सोर्स लाइसेंस के तहत उपलब्ध हैं। इसकी उम्मीद करने से किसी और को कम यूनिक आईडी की तलाश में मदद मिल सकती है।
suid?
जब मैंने इस समस्या को हल किया तो मैंने बेस 36 का उपयोग किया, मैं कुछ साल पहले विकसित कर रहा था। मुझे मानव पठनीय रूप से अद्वितीय संख्या (वर्तमान कैलेंडर वर्ष के भीतर) को उत्पन्न करने की आवश्यकता थी । मैंने चालू वर्ष की पहली जनवरी को आधी रात से मिलीसेकंड में समय का उपयोग करने का विकल्प चुना (इसलिए प्रत्येक वर्ष, टाइमस्टैम्प डुप्लिकेट कर सकता है) और इसे आधार संख्या 36 में बदल सकता है। यदि सिस्टम को विकसित किया जा रहा है, तो यह एक घातक मुद्दे में बदल गया है, इसने बेस 36 नंबर (7 वर्ण) उत्पन्न किया जो कि वेब इंटरफेस के माध्यम से एक अंतिम उपयोगकर्ता को प्रदर्शित किया गया था, जो तब एक तकनीकी सहायता वाले व्यक्ति के सामने आने वाली समस्या (और संख्या) को रिले कर सकता था (जो तब इसका उपयोग लॉग में उस बिंदु को खोजने के लिए किया जा सकता है जहां स्टैकट्रेस शुरू हुआ था)। 56af42g7 जैसा नंबर2016-01-21T15: 34: 29.933-08: 00 या 5f0d3e0c-da96-11e5-bdd2-0a1d41d68578 जैसे यादृच्छिक UUID जैसे टाइमस्टैम्प की तुलना में उपयोगकर्ता को पढ़ना और रिले करना सरल है ।
मुझे वास्तव में 22 अक्षरों की एक स्ट्रिंग प्राप्त करने के लिए बेस 64 प्रारूप का उपयोग करके GUID को कूटबद्ध करने और ट्रेलिंग == को छोटा करने की सरलता पसंद है (यह कोड की एक पंक्ति लेता है, और आप इसे हमेशा GUID में बदल सकते हैं)। अफसोस की बात है, इसमें कभी-कभी + और / अक्षर शामिल होते हैं। डेटाबेस के लिए ठीक है, URL के लिए महान नहीं है, लेकिन इससे मुझे अन्य उत्तरों की सराहना करने में मदद मिली :-)
से https://www.codeproject.com/Tips/1236704/Reducing-the-string-Length-of-a-Guid क्रिस्टियन वैन बर्गन से
हमने पाया कि बेस 64 का उपयोग करते हुए ASCII प्रतिनिधित्व के लिए गाइड (16 बाइट्स) को परिवर्तित करने का परिणाम केवल 22 अक्षरों का एक प्रयोग करने योग्य और अभी भी अनूठा संदेश था।
var newGuid = Guid.NewGuid();
var messageID = Convert.ToBase64String(newGuid.ToByteArray());
var message22chars = Convert.ToBase64String(Guid.NewGuid().ToByteArray()).Substring(0,22);
उदाहरण के लिए: गाइड 'e6248889-2a12-405a-b06d-9695b82c0a9c' (स्ट्रिंग लंबाई: 36) को बेस 64 का प्रतिनिधित्व मिलेगा: 'iYgk5hIqWwCwbbZaVuCwKnA ==' (स्ट्रिंग लंबाई: 24)
Base64 प्रतिनिधित्व '==' वर्णों के साथ समाप्त होता है। आप केवल विशिष्टता पर किसी भी प्रभाव के बिना, इन को काट सकते हैं। लंबाई में केवल 22 अक्षरों के पहचानकर्ता के साथ आपको छोड़कर।