CombGuid। .Net अनुप्रयोगों में SQL सर्वर के अनुकूल गाइड मान उत्पन्न करना

टेबल के लिए प्राथमिक कुंजी के रूप में uuid का उपयोग करने के कई फायदे हैं, जिनमें से एक डेटाबेस सर्वर तक पहुंच के बिना, स्वतंत्र रूप से क्लाइंट एप्लिकेशन में बनाई गई वस्तुओं के लिए पहचानकर्ता प्राप्त करने की क्षमता है। लेकिन एक प्राथमिक कुंजी के रूप में uuid का उपयोग करने में एक खामी है: क्लाइंट एप्लिकेशन द्वारा उत्पन्न गाइड SQL सर्वर के लिए "मैत्रीपूर्ण" नहीं हो सकता है, जो बदले में एक नया रिकॉर्ड जोड़ते समय ओवरहेड हो सकता है। सम्मिलित ऑपरेशन की लागत में संभावित वृद्धि इस तथ्य से उपजी है कि एसक्यूएल सर्वर आमतौर पर टेबल को स्टोर करने के लिए बी-ट्री के रूप में जाना जाता संरचनाओं का उपयोग करता है जिसके लिए प्राथमिक कुंजी निर्दिष्ट है। तालिका में एक नया रिकॉर्ड जोड़ते समय, एसक्यूएल सर्वर, प्राथमिक कुंजी द्वारा छंटनी के अनुसार, उस शीट की खोज करता है जिस पर डाला गया रिकॉर्ड रखा जाना चाहिए। छद्म यादृच्छिक uuid पीढ़ी एल्गोरिदम को देखते हुए, नए रिकॉर्ड का सॉर्टिंग क्रम भी यादृच्छिक है और यह संभव है कि जिस शीट पर रिकॉर्ड रखा जाना चाहिए वह पूरी तरह से भरा हो। ऐसे मामलों में, SQL सर्वर को शीट को दो में विभाजित करना होगा और उस शीट पर जाने वाले बी-ट्री शाखाओं का पुनर्निर्माण करना होगा। नए रिकॉर्ड जोड़ते समय क्लस्टर इंडेक्स को लगातार बनाए रखने की आवश्यकता के साथ SQL सर्वर का सामना नहीं करने के लिए, आप बढ़ते क्रम में प्राथमिक कुंजी मान उत्पन्न कर सकते हैं। वर्तमान आरोही क्रम में गाइड उत्पन्न करने का एक तरीका वर्तमान समय में उत्पन्न गाइड के सॉर्टिंग क्रम को बांधना है। इस तरह से उत्पन्न पहचानकर्ताओं को अक्सर कॉम्बग्यूड कहा जाता है, इस तथ्य से जूझते हुए कि वे दो हिस्सों से निर्मित होते हैं - एक छद्म यादृच्छिक भाग, जैसा कि सामान्य मार्गदर्शक में है, और एक स्ट्रिंग जो समयबद्ध है।

SQL सर्वर uuids की तुलना कैसे करता है

SQL सर्वर .net से एक अलग तरीके से uuid मानों को सॉर्ट करता है। बाइट समूहों पर दाएं से बाएं तक तुलना की जाती है। बाइट समूह के अंदर, तुलना पहले से ही दाएं से बाएं है। (एक बाइट समूह एक '-' वर्ण द्वारा सीमांकित अनुक्रम है।) यदि आप दो यूआईडी मानों की तुलना करते हैं,
@ u1 = '206AEBE7-ABF0-47A8-8AA5-6FDDF39B9644F'
और
@ u2 = '0F8257A1-B40C-4DA0-8A37-8BBC55183CAE', आउटपुट है कि @ u2> @ u1, क्योंकि, जैसा कि ऊपर बताया गया है, SQL सर्वर सबसे सही बाइट समूहों से तुलना शुरू करता है, जहां 6FDDF39B9E4F <8B55183 है। तकनीकी रूप से अधिक बोलने वाले, घटते क्रम में 9 बाइट्स, डेटाबेस में uuid छँटाई क्रम पर सबसे अधिक प्रभाव डालते हैं।

मैग्नम लाइब्रेरी में कंबाइंड कार्यान्वयन

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

public static class CombGuid { static readonly DateTime _baseDate = new DateTime(1900, 1, 1); public static Guid Generate() { byte[] guidArray = Guid.NewGuid().ToByteArray(); DateTime now = DateTime.Now; // Get the days and milliseconds which will be used to build the byte string var days = new TimeSpan(now.Ticks - _baseDate.Ticks); TimeSpan msecs = now.TimeOfDay; // Convert to a byte array // Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333 byte[] daysArray = BitConverter.GetBytes(days.Days); byte[] msecsArray = BitConverter.GetBytes((long)(msecs.TotalMilliseconds/3.333333)); // Reverse the bytes to match SQL Servers ordering Array.Reverse(daysArray); Array.Reverse(msecsArray); // Copy the bytes into the guid Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2); Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4); return new Guid(guidArray); } } 

एल्गोरिथ्म बहुत सरल है।
9-10 बाइट्स में, 1 जनवरी 1900 के बाद से जितने दिन बीत चुके हैं, एनकोडेड है। हमें 2079 में स्रोतों के पुनर्निर्माण के लिए नहीं भूलना चाहिए, जब बीत चुके दिन की संख्या दो बाइट्स में फिट नहीं होगी। 11-15 बाइट्स का उपयोग दिन की शुरुआत से मिलीसेकंड को एन्कोड करने के लिए किया जाता है, किसी कारण से 3.333333 से विभाजित। कोड में टिप्पणियों से संकेत मिलता है कि यह ऑपरेशन इस तथ्य से संबंधित है कि SQL सर्वर में समय टिकटों की सटीकता 1/300 सेकंड है। एक अजीब समाधान, यह देखते हुए कि uuid बनाने की प्रक्रिया में, यह हमारे लिए कोई फर्क नहीं पड़ता कि SQL सर्वर टाइमस्टैम्प को कैसे संग्रहीत करता है, हम केवल uuid बनाने के लिए मिलीसेकंड का उपयोग करते हैं। मैंने इस सवाल को थोड़ा उलझाया, लेकिन मुझे केवल यह एहसास हुआ कि मैग्नम लाइब्रेरी के लेखक क्रिस पैटरसन ने कॉम्बगिड जनरेशन कोड को निहर्नेट से कॉपी किया था। जैसा कि आप यहां देख सकते हैं, जेनरेटकोम्ब विधि में समान कोड है। निष्पक्षता में, यह ध्यान दिया जाना चाहिए कि 3.333333 द्वारा मिलीसेकंड को विभाजित करने से एल्गोरिदम के संचालन पर विशेष प्रभाव नहीं पड़ता है, यह सिर्फ एक अतिरिक्त, वैकल्पिक कदम है।

गाइड बनाम कंब्यूइड। डेटाबेस में प्रविष्टि गति की तुलना करें

अंत में, हम उस बिंदु पर आते हैं, जिसके बारे में यह सब था कि गाइड.न्यूजीड () विधि द्वारा उत्पन्न कितने uuids की तुलना में सर्वर SQL टेबल में रिकॉर्ड डालने के संदर्भ में CombGuid.Generate () के माध्यम से बनाए गए हमारे भाइयों की तुलना में धीमा है।
परीक्षण के लिए, मैंने दो स्क्रिप्ट बनाईं जो SQL सर्वर पर तालिकाएँ बनाती हैं और इन तालिकाओं में 100,000 पंक्तियाँ सम्मिलित करती हैं। पहली स्क्रिप्ट डेटाबेस पंक्तियों में CombGuid.Generate () पद्धति का उपयोग करके बनाई गई Id के साथ सम्मिलित करती है, दूसरी - Guide.NewGuid () विधि का उपयोग करके।

टेस्ट स्क्रिप्ट का एक टुकड़ा।

 USE [CombIdTest] GO --   DBCC DROPCLEANBUFFERS; DBCC FREEPROCCACHE; CREATE TABLE [dbo].[CombId]( [ID] [uniqueidentifier] NOT NULL, [Value] [varchar](4000) NOT NULL, CONSTRAINT [PK_CombId] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO --      begin transaction insert into CombId Values ('5cb31d3d-3793-428e-beb0-a2e4047e255c','somevalue'); insert into CombId Values ('1e905fa1-e4d4-4a2c-a185-a2e4047e255d','somevalue'); --  99998  insert commit transaction 

प्रविष्टि करने से पहले, बफ़र कैश को फ़्लश किया जाता है और लेनदेन लॉग में कॉल की संख्या को कम करने के लिए प्रविष्टि को स्वयं एक लेनदेन में किया जाता है। प्रत्येक स्क्रिप्ट को तीन बार चलाया गया, क्लाइंट के आंकड़ों से "कुल निष्पादन समय" पैरामीटर को निष्पादन समय के रूप में लिया गया था। MSSQL सर्वर 2012 पर माप लिया गया था।

माप परिणाम (मिलीसेकंड में)।

	1	2	3	औसत
CombGuid	2795	2882	2860	2845.667
RandomGuid	3164	3129	3111	3134.667

एक स्क्रिप्ट का लाभ जो कॉम्ग्यूइड युक्त रिकॉर्ड सम्मिलित करता है, वह "नियमित" यूआईडी के साथ एक स्क्रिप्ट पर 10 प्रतिशत से अधिक है। CombGuid का उपयोग करने से तालिका के आकार पर भी सकारात्मक प्रभाव पड़ा - इसका आकार लगभग डेढ़ गुना छोटा था: 3.75 एमबी बनाम 5.25 एमबी।

खैर, अंत में सवालों के एक जोड़े

आप अपने डेटाबेस में प्राथमिक कुंजी के रूप में क्या उपयोग करते हैं?
यदि आप uuid या इसी तरह की बाइट संरचनाओं का उपयोग करते हैं, तो आप उन्हें कैसे उत्पन्न करते हैं?