मुझे GUS को MySQL तालिकाओं में कैसे स्टोर करना चाहिए?




guid uuid (7)

क्या मैं वर्कर (36) का उपयोग करता हूं या ऐसा करने के लिए कोई बेहतर तरीका है?


"बेहतर" उस पर निर्भर करता है जिसके लिए आप अनुकूलित कर रहे हैं।

स्टोरेज आकार / प्रदर्शन बनाम विकास की आसानी के बारे में आप कितना ख्याल रखते हैं? सबसे महत्वपूर्ण बात यह है कि क्या आप पर्याप्त GUID उत्पन्न कर रहे हैं, या उन्हें अक्सर पर्याप्त रूप से ला रहे हैं, यह महत्वपूर्ण है?

अगर उत्तर "नहीं" है, तो char(36) पर्याप्त से अधिक है, और यह GUID को मृत-सरल संग्रहित / लाता है। अन्यथा, binary(16) उचित है, लेकिन आपको सामान्य स्ट्रिंग प्रस्तुति से पीछे और आगे कनवर्ट करने के लिए MySQL और / या अपनी प्रोग्रामिंग भाषा पसंद पर निर्भर होना होगा।


GUID स्ट्रिंग में टाइमस्टैम्प के बिट लेआउट के लिए KCD द्वारा पोस्ट की गई GuidToBinary दिनचर्या को ध्यान में रखा जाना चाहिए। यदि स्ट्रिंग एक संस्करण 1 यूयूआईडी का प्रतिनिधित्व करती है, जैसे यूयूआईडी () mysql रूटीन द्वारा लौटाए गए लोगों की तरह, तो टाइम घटक घटक 1-जी में एम्बेडेड होते हैं, डी को छोड़कर।

12345678-9ABC-DEFG-HIJK-LMNOPQRSTUVW
12345678 = least significant 4 bytes of the timestamp in big endian order
9ABC     = middle 2 timestamp bytes in big endian
D        = 1 to signify a version 1 UUID
EFG      = most significant 12 bits of the timestamp in big endian

जब आप बाइनरी में कनवर्ट करते हैं, तो अनुक्रमण के लिए सबसे अच्छा क्रम होगा: EFG9ABC12345678D + बाकी।

आप 12345678 को 78563412 पर स्वैप नहीं करना चाहते हैं क्योंकि बड़े एंडियन पहले से ही सर्वश्रेष्ठ बाइनरी इंडेक्स बाइट ऑर्डर प्राप्त करते हैं। हालांकि, आप चाहते हैं कि सबसे महत्वपूर्ण बाइट निचले बाइट्स के सामने चले जाएं। इसलिए, ईएफजी पहले जाते हैं, इसके बाद मध्यम बिट्स और निचले बिट्स होते हैं। एक मिनट के दौरान uuid () के साथ एक दर्जन या तो यूयूआईडी उत्पन्न करें और आपको देखना चाहिए कि यह क्रम सही रैंक कैसे उत्पन्न करता है।

select uuid(), 0
union 
select uuid(), sleep(.001)
union 
select uuid(), sleep(.010)
union 
select uuid(), sleep(.100)
union 
select uuid(), sleep(1)
union 
select uuid(), sleep(10)
union
select uuid(), 0;

/* output */
6eec5eb6-9755-11e4-b981-feb7b39d48d6
6eec5f10-9755-11e4-b981-feb7b39d48d6
6eec8ddc-9755-11e4-b981-feb7b39d48d6
6eee30d0-9755-11e4-b981-feb7b39d48d6
6efda038-9755-11e4-b981-feb7b39d48d6
6f9641bf-9755-11e4-b981-feb7b39d48d6
758c3e3e-9755-11e4-b981-feb7b39d48d6 

पहले दो यूयूआईडी समय के साथ निकटतम उत्पन्न हुए थे। वे केवल पहले ब्लॉक के अंतिम 3 निबल्स में भिन्न होते हैं। ये टाइमस्टैम्प के कम से कम महत्वपूर्ण बिट्स हैं, जिसका अर्थ है कि हम उन्हें दाईं ओर धक्का देना चाहते हैं जब हम इसे एक अनुक्रमणीय बाइट सरणी में परिवर्तित करते हैं। काउंटर उदाहरण के रूप में, अंतिम आईडी सबसे वर्तमान है, लेकिन केसीडी के स्वैपिंग एल्गोरिदम इसे तीसरे आईडी (डीसी से पहले 3 डी, पहले ब्लॉक से अंतिम बाइट्स) से पहले रखेगा।

अनुक्रमण के लिए सही क्रम होगा:

1e497556eec5eb6... 
1e497556eec5f10... 
1e497556eec8ddc... 
1e497556eee30d0... 
1e497556efda038... 
1e497556f9641bf... 
1e49755758c3e3e... 

सहायक जानकारी के लिए यह आलेख देखें: http://mysql.rjweb.org/doc.php/uuid

*** ध्यान दें कि मैं टाइमस्टैम्प के उच्च 12 बिट्स से संस्करण निबल को विभाजित नहीं करता हूं। यह आपके उदाहरण से डी निबल है। मैं बस इसे सामने फेंक देता हूँ। तो मेरा बाइनरी अनुक्रम डीईएफजी 9एबीसी और इसी तरह से समाप्त होता है। इसका तात्पर्य है कि मेरे सभी अनुक्रमित यूयूआईडी एक ही नींबू से शुरू होते हैं। लेख एक ही बात करता है।


उन लोगों के लिए जो सिर्फ इस पर ठोकर खा रहे हैं, अब परकोना द्वारा शोध के अनुसार एक बेहतर विकल्प है।

इसमें इष्टतम अनुक्रमण के लिए यूयूआईडी भाग को पुनर्गठित करना शामिल है, फिर कम भंडारण के लिए बाइनरी में परिवर्तित करना शामिल है।

here पूरा लेख पढ़ें


चार (36) एक अच्छा विकल्प होगा। इसके अलावा MySQL के UUID () फ़ंक्शन का उपयोग किया जा सकता है जो 36-वर्ण टेक्स्ट प्रारूप (हाइफ़न के साथ हेक्स) देता है जिसका उपयोग डीबी से ऐसी आईडी के पुनर्प्राप्ति के लिए किया जा सकता है।


मेरे डीबीए ने मुझसे पूछा कि जब मैंने अपनी वस्तुओं के लिए GUID को स्टोर करने का सबसे अच्छा तरीका पूछा, तो मुझे 16 बाइट्स स्टोर करने की आवश्यकता क्यों थी जब मैं एक ही चीज को 4 बाइट्स में एक इंटीजर के साथ कर सकता था। चूंकि उसने मुझे उस चुनौती को मेरे पास रखा था, इसलिए मैंने सोचा कि अब इसका उल्लेख करने का अच्छा समय था। ऐसा कहे जाने के बाद...

यदि आप स्टोरेज स्पेस का सबसे इष्टतम उपयोग करना चाहते हैं तो आप एक GUID को CHAR (16) बाइनरी के रूप में स्टोर कर सकते हैं।


मैं इसे एक char (36) के रूप में स्टोर करूंगा।


यदि आपके पास मानक GUID के रूप में स्वरूपित एक char / varchar मान है, तो आप इसे आसानी से CONCAT + SUBSTR के उन सभी दिमाग-दबाने वाले अनुक्रमों के बिना सरल CAST (MyString AS BINARY16) का उपयोग करके BINARY (16) के रूप में स्टोर कर सकते हैं।

बिनरी (16) फ़ील्ड की तुलना स्ट्रिंग की तुलना में बहुत तेज़ / क्रमबद्ध / अनुक्रमित की जाती है, और डेटाबेस में दो गुना कम स्थान लेती है





uuid