डेवलपर टूल · UUID जनरेटर
यादृच्छिक UUID प्राथमिक कुंजी और बी-ट्री विखंडन: वास्तव में क्या होता है
· यह क्यों मायने रखती है
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
रैंडम v4 कुंजियाँ रैंडम इंडेक्स पेजों में डाली जाती हैं, और क्लस्टर्ड इंडेक्स इसके लिए भुगतान करते हैं। यह पोस्ट तंत्र, टेक्स्ट बनाम बाइनरी की भंडारण लागत और जहां समय-ऑर्डर किए गए UUID तस्वीर बदलते हैं, समझाती है।
जैसे-जैसे तालिका बढ़ती है, प्रविष्टियां धीमी हो जाती हैं - वह लक्षण जो डीबीए को उनकी मुख्य पसंद को देखने के लिए भेजता है
क्लस्टर्ड इंडेक्स वाले डेटाबेस में प्राथमिक कुंजी के रूप में एक यादृच्छिक UUID के साथ एक पंक्ति डालने से डेटाबेस बी-ट्री संरचना के भीतर एक यादृच्छिक स्थान पर नई पंक्ति डालने का कारण बनता है। अनुक्रमिक कुंजियाँ सबसे दाएँ पेज पर संलग्न होती हैं, सभी प्रविष्टियों को एक छोटे, कैश-निवासी क्षेत्र में रखती हैं। यादृच्छिक कुंजियाँ पूरे सूचकांक में आवेषण बिखेरती हैं, जिससे डेटाबेस को भौतिक भंडारण में दूर-दूर तक पेजों को पार करने और संशोधित करने के लिए मजबूर होना पड़ता है। जैसे-जैसे तालिका बढ़ती है और पेड़ गहरा होता है, प्रत्येक प्रविष्टि अधिक पेजों को छूती है और अधिक I/O संचालन का कारण बनती है। जो ऑपरेशन एक हजार पंक्तियों में सस्ता दिखाई देता था वह दस लाख पंक्तियों में महंगा हो जाता है। यह कोई सैद्धांतिक समस्या नहीं है; यह सम्मिलन थ्रूपुट में मापने योग्य गिरावट के रूप में प्रकट होता है।
क्लस्टर्ड बी-ट्री कैसे भरता है - अनुक्रमिक कुंजियाँ अंतिम पेज पर संलग्न होती हैं; यादृच्छिक कुंजियाँ संपूर्ण अनुक्रमणिका में पेजों को स्पर्श करती हैं
बी-पेड़ कैसे काम करते हैं, इसके लिए यह तंत्र मौलिक है क्योंकि वे पत्ती पेजों के भीतर क्रमबद्ध कुंजी क्रम को बनाए रखते हैं। जब आप किसी तालिका में कुंजी 10,001 के साथ एक पंक्ति डालते हैं जिसमें पहले से ही कुंजी 1 से 10,000 तक संग्रहीत होती है, तो डेटाबेस जानता है कि वह पंक्ति कहां है: अंत में, मौजूदा सबसे दाहिने पेज में यदि जगह है, या दाईं ओर जुड़े एक नए पेज में। जब आप एक ही तालिका में यादृच्छिक UUID जैसे 7524fae2-7dec-11d0-a765-00a0c91e6bf6 के साथ एक पंक्ति सम्मिलित करते हैं, तो डेटाबेस को उस UUID कैटेगरी में कुंजियों वाले लीफ पेज को खोजने के लिए ट्री को नेविगेट करना होगा, उस पेज के भीतर सटीक स्थिति का पता लगाना होगा और पंक्ति सम्मिलित करनी होगी। यदि वह पेज भरा हुआ है, तो वह विभाजित हो जाता है, उसकी आधी सामग्री को एक नए पेज पर ले जाता है और मूल नोड को अद्यतन करता है।
पेज विभाजन और कैश दबाव - क्यों यादृच्छिक प्रविष्टि की लागत अधिक I/O है और प्रभाव तालिका आकार के साथ क्यों बढ़ता है
रैंडम कुंजियाँ सबसे खराब स्थिति वाले इंसर्शन पैटर्न का निर्माण करती हैं क्योंकि प्रत्येक इंसर्ट सबसे दाहिने पेज पर जुड़ने के बजाय पेड़ में एक यादृच्छिक स्थान पर होता है। डेटाबेस को सही पेज की खोज करनी चाहिए, जिसमें आम तौर पर कई पेज पढ़ने की लागत होती है - पेड़ के प्रति स्तर एक। फिर उसे उस पेज को संशोधित करना होगा, जो पेड़ में फैलने वाले विभाजन को ट्रिगर कर सकता है। अधिक पेजों को संशोधित किया जाता है, अधिक लेखन होता है, और मेमोरी बफ़र पूल सक्रिय प्रविष्टि बिंदु पर केंद्रित रहने के बजाय पेड़ के विभिन्न क्षेत्रों के पेजों से भर जाता है। कैश बढ़ने से चूक जाता है और I/O बाधा बन जाता है, जैसे-जैसे तालिका बड़े पैमाने पर बढ़ती है, प्रविष्टि दर स्थिर हो जाती है।
पाठ या बाइनरी - 36-वर्ण स्ट्रिंग बनाम 16-बाइट मूल uuid या बाइनरी (16) कॉलम और सूचकांक आकार पर प्रभाव
डेटाबेस इंजनों में लागत एक समान नहीं है क्योंकि अलग-अलग सिस्टम पेज प्रबंधन को अलग-अलग तरीके से अनुकूलित करते हैं। आक्रामक संपीड़न, छोटे पेज आकार या इन-मेमोरी ऑपरेशन वाले डेटाबेस अनुक्रमिक और यादृच्छिक कुंजियों के बीच छोटे प्रदर्शन अंतर दिखा सकते हैं। बड़े पेजों, यांत्रिक डिस्क या सख्त मेमोरी सीमाओं वाले डेटाबेस में नाटकीय गिरावट दिखाई देगी। समस्या देखने योग्य और मापने योग्य है: 1,000 पंक्तियों, 100,000 पंक्तियों और 1,000,000 पंक्तियों पर प्रविष्टि दर मापें। यदि प्रति सेकंड की दर बड़े पैमाने पर तेजी से गिरती है, तो आप अपने विशिष्ट हार्डवेयर और डेटाबेस कॉन्फ़िगरेशन के साथ यादृच्छिक-प्रविष्टि दंड का अनुभव कर रहे हैं।
समय-क्रमित विकल्प - कैसे UUIDv7 और ULID सूचकांक के अंत में सम्मिलित करते समय विशिष्टता बनाए रखते हैं
स्ट्रिंग के रूप में UUID टेक्स्ट फॉर्म में 36 वर्णों का उपभोग करते हैं या चुने गए स्टोरेज प्रारूप के आधार पर बाइनरी UUID प्रकार के रूप में 16 bytes का उपभोग करते हैं। UTF-8 या ASCII कॉलम में 36-वर्ण स्ट्रिंग 36 bytes है, जबकि 64-बिट पूर्णांक के लिए 8 bytes है। स्ट्रिंग-UUID कॉलम पर इंडेक्स एक पूर्णांक कॉलम पर इंडेक्स से तीन गुना बड़ा है, यह मानते हुए कि कोई संपीड़न तकनीक लागू नहीं की जाती है। बड़े इंडेक्स का मतलब है कि कम इंडेक्स पेज बफर पूल में फिट होते हैं, जिसका मतलब है कि पेड़ को पार करते समय कम कैश हिट होता है। एक छोटा सूचकांक जो RAM में फिट होता है, एक बड़े सूचकांक से बेहतर प्रदर्शन करता है जिसे प्रविष्टि आदेश या कार्यभार पैटर्न की परवाह किए बिना, प्रत्येक क्वेरी पर डिस्क से पढ़ा जाना चाहिए।
कार्यान्वित उदाहरण - एक यादृच्छिक-कुंजी और एक समय-क्रम-कुंजी तालिका के लिए वर्णित समान सम्मिलित कार्यभार, गुणात्मक रूप से, आविष्कार किए गए बेंचमार्क के बिना
भंडारण अंतर प्राथमिक और द्वितीयक दोनों अनुक्रमितों के लिए महत्वपूर्ण रूप से मायने रखता है क्योंकि प्रत्येक द्वितीयक सूचकांक जिसमें प्राथमिक कुंजी शामिल है, को पूर्ण 36-वर्ण UUID या 16-बाइट बाइनरी UUID मान संग्रहीत करना होगा। यह प्राथमिक कुंजी लुकअप के लिए पूर्णांक कुंजी का उपयोग करके द्वितीयक अनुक्रमणिका को अनुक्रमित से काफी बड़ा बनाता है। प्रतिकृति, बैकअप और क्वेरी परिणाम सेट सभी बड़े सूचकांक आकार के साथ आनुपातिक रूप से बढ़ते हैं। ToolAcre UUID जनरेटर बाइनरी-संगत मान उत्पन्न करता है; डेटाबेस के आधार पर उन्हें बाइनरी(16) या GUID प्रकार के रूप में संग्रहीत करने से varchar(36) की तुलना में स्थान की बचत होती है और पूरे बोर्ड में कैश दक्षता में सुधार होता है। यह भंडारण अनुकूलन बड़े पैमाने की प्रणालियों के लिए महत्वपूर्ण है।
इसमें क्या शामिल नहीं है - ढेर-संगठित तालिकाएँ और डेटाबेस जहाँ प्राथमिक कुंजी क्लस्टर नहीं की जाती है, जहाँ प्रभाव छोटा होता है
एक सामान्य अनुकूलन UUID को आंतरिक रूप से बाइनरी के रूप में संग्रहीत करना और इसे केवल APआई या उपयोगकर्ता इंटरफ़ेस के लिए आवश्यक होने पर स्ट्रिंग के रूप में प्रदर्शित करना है। इंडेक्स और जॉइन ऑपरेशन कॉम्पैक्ट बाइनरी फॉर्म पर काम करते हैं; API प्रतिक्रिया या एप्लिकेशन कोड स्ट्रिंग प्रतिनिधित्व में परिवर्तित हो जाता है। कुछ डेटाबेस अंतर्निहित GUID या UUID प्रकार की पेशकश करते हैं जो इस रूपांतरण को स्वचालित रूप से संभालते हैं। दूसरों को स्पष्ट कास्टिंग ऑपरेशन की आवश्यकता होती है। 36-बाइट और 16-बाइट कॉलम के बीच प्रदर्शन अंतर वास्तविक है: दस लाख पंक्तियों वाली एक तालिका और 36-बाइट बनाम 16-बाइट UUID कॉलम कुंजी प्रति इंडेक्स स्तर 20 MB से भिन्न होती है, जो इंडेक्स फिटिंग के बीच का अंतर हो सकता है L3 कैश और मेमोरी लाने की आवश्यकता है।
टेकअवे: कोई संस्करण चुनने से पहले अपना सूचकांक जानें - ToolAcre जनरेटर यादृच्छिक UUID उत्पन्न करता है; यह तय करने के लिए पोस्ट का उपयोग करें कि क्या यह आपके स्टोरेज इंजन में फिट बैठता है
प्रविष्टि प्रदर्शन, सूचकांक आकार और क्वेरी विशेषताओं के बीच तालमेल के लिए कार्यभार पैटर्न के आधार पर वास्तुशिल्प निर्णयों की आवश्यकता होती है। यदि स्ट्रिंग ऊपर की ओर बढ़ रही हैं, उदाहरण के लिए टाइमस्टैम्प-आधारित स्ट्रिंग, तो एक अनुक्रमिक स्ट्रिंग कुंजी डालने में तेज़ हो सकती है, लेकिन यह यादृच्छिक UUID के समान स्थान का उपभोग करेगी और अस्थायी जानकारी लीक करेगी। एक यादृच्छिक UUID शब्दार्थ की दृष्टि से साफ-सुथरा है और इसमें लीक होने के लिए कोई टाइमस्टैम्प घटक नहीं है, लेकिन क्लस्टर्ड इंडेक्स में डालने में यह धीमा है और कुल मिलाकर भंडारण में बड़ा है। UUIDv7 जैसे समय-क्रम वाले विकल्प, संस्करण 4 यादृच्छिक पहचानकर्ताओं में टाइमस्टैम्प लीक से बचते हुए सम्मिलन इलाके को बनाए रखते हुए लाभ जोड़ते हैं।