2009-02-04 10 views
11

मैं ऐसे एप्लिकेशन पर काम कर रहा हूं जो जीमेल में देखी गई यूआरएल आईडी के समान एक व्यावसायिक कुंजी (प्राथमिक कुंजी के रूप में ऑटो वृद्धि क्षेत्र के अतिरिक्त) के रूप में एक हेक्स वैल्यू लागू करेगा। । मैं कॉलम में एक अनूठी बाधा डाल रहा हूं और मूल रूप से वर्चर फील्ड खोजने से दूर होने के लिए मूल्य को एक बड़ा रूप देने के बारे में सोच रहा था, लेकिन यह सोच रहा था कि यदि क्षेत्र अद्वितीय है तो यह आवश्यक है।अद्वितीय वर्चर फ़ील्ड बनाम अनूठे वर्चर फ़ील्ड का मेरा एसएसएलक्यूएल प्रदर्शन

आंतरिक वृद्धि ऑटो वृद्धि क्षेत्र का उपयोग करके किया जाएगा और हेक्स वैल्यू फ़िल्टरिंग के लिए क्लॉज में उपयोग किया जाएगा।

वैरर (एक्स), या संभवतया एक चर (x) के रूप में मूल्य को स्टोर करने के लिए हेक्स से रूपांतरण करने के लिए अतिरिक्त काम पर कितना प्रदर्शन हिट होगा, मूल्य को एक पूर्णांक के रूप में स्टोर करने के लिए डेटाबेस में? क्या यह अतिरिक्त जटिलता के लायक है?

मैंने छोटी संख्या में पंक्तियों (50k) पर त्वरित परीक्षण किया और इसी तरह के खोज परिणाम समय थे। यदि कोई बड़ा प्रदर्शन मुद्दा है तो यह रैखिक, या घातीय होगा?

मैं इंजन के रूप में InnoDB का उपयोग कर रहा हूं।

उत्तर

5

क्या आपका हेक्स एक GUID मानता है? हालांकि मैं इंडेक्स के रूप में ऐसी लंबी वस्तुओं के प्रदर्शन के बारे में चिंतित था, मैंने पाया है कि आधुनिक डेटाबेस पर लाखों रिकॉर्डों पर प्रदर्शन अंतर काफी महत्वहीन है।

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

ऊपर की तरफ, यदि आप एक GUID का उपयोग करते हैं तो आप रिकॉर्ड किए गए रिकॉर्ड के लिए सर्वर स्वतंत्रता प्राप्त करते हैं और एकाधिक सर्वरों पर डेटा विलय करने में अधिक लचीलापन प्राप्त करते हैं (जो कि मेरी देखभाल है, क्योंकि हमारी प्रणाली बाल प्रणालियों से डेटा एकत्र करती है)।

कि मेरे संदेह का बैकअप लेने के लिए लगता है इस लेख पर एक ग्राफ है: Myths, GUID vs Autoincrement

1

हेक्स मान एक UUID (जावा के कार्यान्वयन) से उत्पन्न होता है; यह छोटी लंबाई (संभवतः 16 वर्ण) तक धोया और छोटा कर दिया गया है। एल्गोरिदम जिसके लिए अभी भी चर्चा चल रही है (वर्तमान में एसएचए)। हेक्स बनाम पूर्णांक में मान को संग्रहीत करने का एक लाभ यह है कि अगर हमें आकार बढ़ाने की आवश्यकता होती है (जो मुझे इस आवेदन के साथ 16 char पर नहीं दिख रहा है) तो हम आसानी से छंटनी की लंबाई बढ़ा सकते हैं और पुराने मूल्यों को डर के बिना छोड़ सकते हैं टकराव की पूर्णांक मानों में कनवर्ट करना इसके लिए अच्छी तरह से काम नहीं करेगा।

एक GUID/UUID का उपयोग कर छंटनी का कारण बस यूआरएल और एपीआई (जहां इनका उपयोग किया जाएगा) को और अधिक अनुकूल बनाने का कारण है।

+1

व्यक्तिगत रूप से, मैं वास्तव में बचने की कोशिश करता हूं उपयोगकर्ता इंटरफ़ेस में उपयोगकर्ता को GUID में उजागर करना। यहां तक ​​कि एक यूआरएल लाइन भी। हालांकि, मैं एक सत्र का उपयोग करके या विशिष्ट कोड का उपयोग करके उन्हें * प्रदर्शन के लिए * आंतरिक रूप से और उन्हें छीनने का सुझाव दूंगा। इस तरह और आइटम = 1 मैंने दिखाया पहला आइटम है ... मैं GUID * आंतरिक रूप से * खींचता हूं। – Godeke

1

अन्य सभी समान हैं, डेटा को छोटा रखने से यह तेजी से चल जाएगा। अधिकांशतः क्योंकि इसमें कम जगह लेनी होगी, इसलिए कम डिस्क I/o, इंडेक्स को इत्यादि रखने के लिए कम मेमोरी की आवश्यकता है। 50k पंक्तियों को नोटिस करने के लिए पर्याप्त नहीं है कि ...

संबंधित मुद्दे