वितरित डेटाबेस वातावरण में अद्वितीय कुंजी

यदि आप डेटा को कई भौतिक डेटाबेस में विभाजित करते हैं,
विश्व स्तर पर विशिष्ट पहचानकर्ताओं का समर्थन करना अब एक मामूली काम नहीं है।
मैंने संभावित विकल्पों को एक साथ रखने और उनके पेशेवरों और विपक्षों पर विचार करने की कोशिश की।

क्या आवश्यकताएं (विशिष्टता के अलावा) चाबियों को प्रस्तुत की जा सकती हैं?

कुंजी को नीरसता से बढ़ाना चाहिए
इसकी आवश्यकता क्यों है:

• स्वचालित प्राकृतिक छँटाई (कालानुक्रम सहित)
• यादृच्छिक कुंजी के साथ की तुलना में तेजी से प्रविष्टि

उपरोक्त केवल पेड़ों का उपयोग करने वाले अनुक्रमितों के लिए प्रासंगिक है।

क्लाइंट साइड पर कुंजी बननी चाहिए
इसकी आवश्यकता क्यों है:

• आवेदन तुरंत वांछित शार्द (क्लस्टर नोड) में बदल सकता है, क्योंकि ऑब्जेक्ट को सहेजने से पहले ही अद्वितीय कुंजी ज्ञात है
• एक आवेदन एक ही बार में (एक लेन-देन या बैच नौकरी में) कई संबंधित वस्तुओं को बचा सकता है

मुख्य आकार सीमा (उदा। केवल 64 बिट्स)
इसकी आवश्यकता क्यों है:

• कुछ मामलों में, 128- या 160-बिट पहचानकर्ता एक समस्या हो सकती है। उदाहरण के लिए, स्फिंक्स खोज केवल पूर्णांक दस्तावेज़ पहचानकर्ताओं (64-बिट संस्करण में 64 बिट्स) का समर्थन करती है।
• 32- या 64-बिट कुंजियों वाला एक सूचकांक सैद्धांतिक रूप से मनमानी लंबाई की कुंजियों के साथ तेजी से काम करना चाहिए।
• 32- या 64-बिट कुंजियों वाला एक सूचकांक अधिक कॉम्पैक्ट है और परिणामस्वरूप, पूरी तरह से मेमोरी में फिट बैठता है (बड़ी मात्रा में डेटा के लिए प्रासंगिक)।

अद्वितीय कुंजी उत्पन्न करने के तरीके क्या हैं?

एप्लिकेशन-साइड आईडी पीढ़ी (UUID, आदि)

UUID के साथ , सब कुछ अपेक्षाकृत सरल है - हम एक पुस्तकालय लेते हैं और आवेदन पक्ष पर चाबियाँ उत्पन्न करते हैं। UUID का व्यापक रूप से कई प्रणालियों में उपयोग किया जाता है। मूल्य इस तरह से बनता है कि टकराव असंभव है।

विपक्ष:
• मानक यूयूआईडी की लंबाई 128 बिट्स है (जो वास्तव में, आप अक्सर हेक्साडेसिमल अंकों की एक स्ट्रिंग के रूप में सीधे स्टोर करना चाहते हैं, जो कि 32 बाइट्स है)
• आमतौर पर, एक UUID कुंजियों की एक प्राकृतिक छँटाई प्रदान नहीं करता है

प्रमुख पीढ़ी के लिए अलग सेवा

इस विकल्प का उपयोग किया जाता है, उदाहरण के लिए, फ्लिक और ट्विटर द्वारा।

विपक्ष:
• अतिरिक्त घटकों की शुरूआत के कारण प्रणाली की जटिलता
• मुख्य जनरेटर की उच्च उपलब्धता सुनिश्चित करने के लिए संभावित रूप से विफलता का एक बिंदु या अतिरिक्त प्रयासों की आवश्यकता होती है

मूल्य सीमाओं द्वारा डेटाबेस की ओर ऑटो-वृद्धि

मानों की पूरी श्रृंखला को उपग्रहों में विभाजित किया गया है और प्रत्येक शर्ड (क्लस्टर नोड) अपनी सीमा के लिए जिम्मेदार है, उदाहरण के लिए:

     1 - 0 .. 3FFFFFFF,
     2 - 40,000,000 .. 7FFFFFFF,
     3 - 80000000 .. BFFFFFFF,
     4 - C0000000 .. FFFFFFFF

विपक्ष:
• डेटाबेस को ऑटो-इन्क्रीमेंट (कई NoSQL स्टोरेज के लिए लागू नहीं) का समर्थन करना चाहिए
प्राकृतिक छंटाई संभव नहीं है
• ग्राहक "वस्तु को डालने से पहले कुंजी" नहीं जानता है। कुंजी को खोजने के लिए आपको एक अलग अनुरोध करने की आवश्यकता है।
• क्लस्टर नोड्स की संख्या में वृद्धि करना लगभग असंभव है

इंस्टाग्राम ऑटो इंक्रीमेंट

यह निर्णय इंस्टाग्राम टीम के तकनीकी ब्लॉग (फोटो शेयरिंग एप्लिकेशन) में वर्णित किया गया था।

वे 64-बिट कुंजी का उपयोग करते हैं, जो डेटाबेस (PostgreSQL) की ओर से उत्पन्न होता है और इसमें बिट फ़ील्ड होते हैं

63 31 0 |======|======|======|======|======|======|======|======| | CUSTOM TIMESTAMP | SHARD ID | AUTO | 

जहाँ
- CUSTOM TIMESTAMP (41 बिट्स) - 2011-01-01 00:00:00 से मिलीसेकंड में समय
- SHARD ID (13 बिट्स) - तार्किक विभाजन पहचानकर्ता ( SHARD ID की संख्या भौतिक नोड्स की संख्या से अधिक है)
- AUTO (10 बिट) - एक अनुक्रम (अनुक्रम), तार्किक विभाजन (शार्द) के भीतर अद्वितीय

पेशेवरों (सीमाओं पर ऑटो-वेतन वृद्धि की तुलना में):
• स्वचालित कालानुक्रमिक छंटाई

और आप क्या विकल्प जानते हैं और उपयोग करते हैं?