SQL Server 2014 में इन-मेमोरी ओएलटीपी। भाग I

इन-मेमोरी ओएलटीपी कार्यक्षमता (एक हेकोटन परियोजना) को SQL सर्वर में विशिष्ट OLTP संचालन के प्रसंस्करण को गति देने के लिए डिज़ाइन किया गया है। जैसा कि आप जानते हैं, डेटाबेस सर्वर पर लोड, यह Microsoft SQL सर्वर या Oracle / MySQL या SAP / Sybase या IBM DB2, आदि हो, दो वर्गों में विभाजित किया जा सकता है: डेटा संग्रह और वे क्या एकत्र किए गए, इसका विश्लेषण क्योंकि इसे अन्यथा क्यों एकत्र किया जाएगा? कार्यों के पहले वर्ग को ओएलटीपी (ऑन-लाइन ट्रांसेक्शनल प्रोसेसिंग) कहा जाता है। यह डेटाबेस में अपेक्षाकृत कम संख्या में टेबल को शामिल करने वाले लघु अद्यतन लेनदेन की विशेषता है। ऐसे अनुप्रयोगों के उदाहरण एक बैंकिंग दिवस, दूरसंचार बिलिंग आदि हैं। कार्यों के दूसरे वर्ग को ओएलएपी (ऑन-लाइन एनालिटिकल प्रोसेसिंग) कहा जाता है और बड़े पैमाने पर लंबे पढ़ने, टेबल की एक महत्वपूर्ण संख्या को कवर करने और उनसे एक नियम के रूप में, एक रिकॉर्ड के रूप में, बाध्यकारी, छंटाई, समूहीकरण, कुल कार्य आदि की विधेय के साथ भरा हुआ है। एक नियम के रूप में, कार्यों के विभिन्न वर्गों के लिए डेटा संरचनाओं को अलग किया जाता है ताकि एक दूसरे के साथ हस्तक्षेप न हो, और यदि पहले डेटाबेस संरचना को कई कोडक नियमों को ध्यान में रखते हुए बनाया गया है, तो दूसरा, इसके विपरीत, "स्टार (स्नोफ्लेक)" योजना के अनुसार इसे असामान्य और प्रदर्शन किया जाता है।

मेमोरी में DBMS का प्रयास नई सहस्राब्दी की शुरुआत में दिखाई दिया, जब यह पता चला कि मूर के कानून के बावजूद, प्रोसेसर की घड़ी की गति और गति में तेजी से वृद्धि नहीं हुई, लेकिन, इसके विपरीत, आईएलपी और अन्य चाल के बावजूद एक फ्लैट संतृप्ति रेखा पर पहुंच गया। एक ही समय में, एक बार अभद्र रूप से महंगी होने वाली रैंडम एक्सेस मेमोरी की कीमतें भयावह रूप से घट रही हैं और 90 के दशक की तुलना में हजारों गुना कम हो गई हैं। हाँ, डेटाबेस सर्वर निर्माताओं ने खुद को बताया। 2005 में, ओरेकल ने TimesTen DBMS-memory, 2007 में IBM, सॉलिड कंपनी, और Microsoft को खरीदा, इस मामले में बाहर से कुछ नहीं लिया, क्योंकि उन्होंने अपनी टीम में शिक्षित करने का फैसला किया।



इन-मेमोरी ओएलएपी के साथ शुरू हुआ। शिक्षा का पहला फल ColumnStore इंजन वर्टीकैप में SQL Server 2008 R2 के एक्सेल और SharePoint के लिए PowerPivot के रूप में जारी किया गया था। जैसा कि नाम से प्रतीत होता है, कॉलम इंडेक्स को इसलिए डिज़ाइन किया गया है ताकि प्रत्येक पेज में मेमोरी में अधिक डेटा रैम करने के लिए (संपीड़ित SQL Server 2008 में दिखाई देने वाले कंप्रेशन से ~ ~ 2 गुना बेहतर) कॉलम का एक टुकड़ा शामिल हो। परंपरागत रूप से, OLAP कॉलम इंडेक्स से लाभान्वित होता है, क्योंकि, जैसा कि हम याद करते हैं, यह एक विशाल रीड है। एक नियम के रूप में, उन सभी स्तंभों (या श्रेणी) के साथ पढ़ना आवश्यक है जिनके द्वारा निर्देशिका (माप तालिका, तारा किरणें) फैक्ट टेबल (हब) में विदेशी कुंजियों के स्तंभों के साथ जुड़ी हुई हैं ताकि उनके बीच एक जुड़ाव (या अर्ध-जुड़ाव) का निर्माण किया जा सके। SQL सर्वर 2012 में, इस संबंध में दो उपयोगी बातें हुईं। सबसे पहले, xVelocity (पूर्व में वर्टीकैप) विश्लेषण सेवाओं में तथाकथित तबुलर मॉडल के रूप में दिखाई दिया, जो कि पारंपरिक बहुआयामी लोगों के लिए एक विकल्प था, जो भगवान निषिद्ध थे, SQL Server 7.0 के साथ। दूसरे, कॉलम इंडेक्स अपने आप में एक चीज नहीं रह गया है, और इसे आवश्यकतानुसार निर्माण करना संभव हो गया है - कमांड बनाएँ [NONCLUSTERED] COLUMNSTORE INDEX T-SQL में दिखाई दिया। स्तंभ इंडेक्स पर प्रतिबंधों का एक स्तंभ तुरंत लगाया गया था, जिनमें से सबसे गंभीर, निश्चित रूप से अद्यतन विवरण विफल रहा था क्योंकि डेटा को एक तालिका में अद्यतन नहीं किया जा सकता है जिसमें एक गैर-स्तंभित स्तंभ सूची है। UPDATE स्टेटमेंट जारी करने से पहले कॉलमस्टोर इंडेक्स को डिसेबल करने पर विचार करें, और फिर UPDATE पूरा होने के बाद कॉलमस्टोर इंडेक्स का पुनर्निर्माण करें। SQL सर्वर 2014 में, यह बुराई अद्यतन क्लस्टर किए गए स्तंभ अनुक्रमणिका से निपट गई थी। खैर, एक कॉलम के रूप में ... एक कॉलम इंडेक्स को अपडेट करने के लिए, एक डेल्टा स्टोर और डिलीट बिटमैप को उस पर लटका दिया गया था। जब कोई रिकॉर्ड हटा दिया जाता है, तो वह भौतिक रूप से गायब नहीं होता है, और उस पर बिटमैप को हटाने का एक ध्वज सेट किया जाता है। जब रिकॉर्ड डाला जाता है, तो यह डेल्टा स्टोर में समाप्त हो जाता है। दोनों कि, और एक और सामान्य रूप से सभी निम्नलिखित प्लस और minuses के साथ बी-ट्री (रोस्टोर)। एक टपल मूवर पृष्ठभूमि प्रक्रिया है जो डेल्टा स्टोर के साथ क्रॉल करती है और जोड़े गए रिकॉर्ड को कॉलमस्टोर सेगमेंट में परिवर्तित करती है, लेकिन, आमतौर पर बोलना, कॉलम इंडेक्स को पढ़ने का मतलब है कि न केवल कॉलमस्टोर पढ़ना, बल्कि ये दो साथी भी हैं, क्योंकि आपको हटाए गए रिकॉर्ड को फ़िल्टर करने और बनाने की आवश्यकता है संघ जोड़ा गया। फिर भी, रिलीज़ होने के दो हफ्ते बाद, SQL Sever 2014 ने स्वतंत्र विश्लेषणात्मक परीक्षणों TPC-H में रिकॉर्ड परिणाम दिखाए, नॉन-क्लस्टर (स्टैंडअलोन) स्टैंडिंग में वेट कैटेगरी 1, 3 और 10 टीबी डेटाबेस वॉल्यूम के द्वारा तालिका में पहली पंक्तियाँ लीं। इस प्रकार, हम इस बात पर विचार करेंगे कि इन-मेमोरी OLAP के साथ सब कुछ ठीक है और इन-मेमोरी OLTP पर आगे बढ़ें।



जैसा कि पहले ही उल्लेख किया गया है, हेक्सटन एसक्यूएल सर्वर के अगले संस्करण का कोड नाम नहीं है, जैसा कि डेनाली, कटमे, युकोन, आदि थे, लेकिन वास्तव में, एक इन-मेमोरी इंजन, अर्थात् विकसित करने के लिए एक परियोजना। उत्पाद का घटक। यह घटक न केवल वर्तमान संस्करण में सबसे हड़ताली नवाचार है, बल्कि संभवतः, पूरे उत्पाद लाइन के पैमाने पर, 16-बिट एश्टन-टेट / माइक्रोसॉफ्ट एसक्यूएल सर्वर 1.0 से शुरू होता है, जो 25 साल पहले जारी किया गया था। हेकटन एक ग्रीक शब्द है और इसका मतलब एक सौ या एक-एक सौ = एक सौ बार है, जो कग्बे संकेत देता है कि यह केवल दस के साथ एक की तुलना में कूलर नहीं है। मैं इस गलत धारणा के खिलाफ तुरंत चेतावनी देना चाहूंगा कि हेकोटन एक प्रकार का विस्तारित संस्करण है, क्योंकि यह मेमोरी से जुड़ी एक मेज के साथ काम करता है, जो एक नियमित डिस्क की तरह काम करता है, जिसमें निष्पादन योजनाएं शामिल हैं, जिसमें लॉक का उपयोग करके लेन-देन की अखंडता सुनिश्चित करना शामिल है। हेकटन एक कॉम्पैक्ट स्वतंत्र कर्नेल है जिसे SQL सर्वर कार्यकारी तंत्र के अंदर एकीकृत किया गया है, जो कि व्याख्यायित निष्पादन योजनाओं की अनुपस्थिति में पारंपरिक डेटाबेस इंजन की तुलना में विशेषता है, तार्किक डेटा अखंडता को सुनिश्चित करने के साधन के रूप में लॉक करता है और भौतिक अखंडता के लिए लाच करता है। मैं आपको याद दिलाता हूं कि latches (मुझे नहीं पता कि वे वैचारिक रूप से सही तरीके से रूसी में कैसे अनुवाद किए गए हैं, संभवत: latches) हल्के ताले हैं जो डेटा पेज, इंडेक्स पेज, कुछ सेवा संरचनाओं को उनके पढ़ने के समय या मेमोरी में बदलने के तुरंत बाद लगाए जाते हैं; ताले से जो पूरे लेनदेन में हो सकता है। इसलिए, विवरण में जाने के बिना, हम मान सकते हैं कि गतिरोध मौजूद नहीं है। बारीकियां हैं, लेकिन इतनी दर्दनाक नहीं। एक और अंतर यह है कि ताले को नियंत्रित किया जा सकता है (उदाहरण के संकेत, अलगाव स्तर)। कुंडी विशुद्ध रूप से SQL सर्वर द्वारा संचालित है। मैं उनकी आंतरिक संरचना के विवरण में नहीं जाऊंगा, जो लोग चाहते हैं कि बीओएल या एवगेनी खाबरोव के पृष्ठ पर जा सकते हैं। मैं सिद्धांत से नहीं टकराऊंगा, चलो बेहतर उदाहरणों के लिए नीचे उतरें।



चलो एक डेटाबेस बनाते हैं और इसमें एक फाइल ग्रुप इन-मेमोरी ओएलटीपी के तहत आता है।

CREATE DATABASE hekaton_test ALTER DATABASE hekaton_test ADD FILEGROUP fg_hekaton_test CONTAINS MEMORY_OPTIMIZED_DATA ALTER DATABASE hekaton_test ADD FILE (name='fg_hekaton_test1', filename='c:\Temp\fg_hekaton_test1') TO FILEGROUP fg_hekaton_test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लिपि १



यह एक फाइल की तरह फाइलग्रुप है, मेमोरी से डेटा इसमें बना रहेगा, और रिकवरी की प्रक्रिया में। तदनुसार पढ़ें। क्लस्टर किए गए कॉलमस्टोर की तरह, इसमें डेटा फाइलें होती हैं, जिनमें सम्मिलित या अपडेट के परिणाम में डाले गए रिकॉर्ड क्रमिक रूप से लिखे जाते हैं और डेल्टा फाइलें होती हैं जिनमें हटाए गए रिकॉर्ड के पहचानकर्ता संग्रहीत होते हैं। सबसे पहले, परिवर्तन, हमेशा की तरह, मेमोरी में परिलक्षित होते हैं, और 256K (डेटा के मामले में) के चेकपॉइंट ब्लॉक के साथ और 4K (डेल्टा) डिस्क पर डंप होते हैं, जिसे लेनदेन लॉग में नोट किया जाता है। डेटा-डेल्टा जोड़े का विलय स्वचालित रूप से तब होता है जब एक निश्चित आकार तक पहुँच जाता है और रैम के आकार पर निर्भर करता है, और sys.sp_xtp_merge_checkpoint_files प्रक्रिया द्वारा मैन्युअल रूप से भी किया जा सकता है। इस प्रक्रिया के बारे में यहाँ और पढ़ें।

इस प्रकार, स्मृति में तालिकाओं के प्लेसमेंट का मतलब यह नहीं है कि यदि सर्वर काट दिया जाता है, तो बैक-ब्रेकिंग श्रम द्वारा अधिग्रहित सब कुछ खो जाएगा। इन-मेमरी ओएलटीपी एक पूरी तरह से ट्रांसेक्शनल तकनीक है और ऑल्टरऑन सहित फॉल्ट टॉलरेंस को सपोर्ट करता है।



हौसले से बनाए गए डेटाबेस में, स्मृति में काम करने के लिए अनुकूलित एक तालिका बनाएं।

 use hekaton_test CREATE TABLE dbo.ShoppingCart ( ShoppingCartId int not null primary key nonclustered hash with (bucket_count=2000000), UserId int not null index ix_UserId nonclustered hash with (bucket_count=1000000), CreatedDate datetime2 not null, TotalPrice money ) WITH (MEMORY_OPTIMIZED=ON)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लिपि २



अंतिम विकल्प का अर्थ है कि तालिका को स्मृति में रखा जाएगा। प्रत्येक MEMORY_OPTIMIZED तालिका में कम से कम एक अनुक्रमणिका होनी चाहिए। कुल संख्या 8 से अधिक नहीं होनी चाहिए। अनुक्रमणिका के क्षेत्र अशक्त नहीं होने चाहिए। सूचकांक क्षेत्रों n (var) चार के लिए, BIN2 कॉल का उपयोग किया जाना चाहिए। कोई क्लस्टर इंडेक्स नहीं हैं, परिभाषा के अनुसार। क्लासिक बी-ट्री की संरचना, भी। स्मृति में तालिकाओं के लिए, अनुक्रमित एचएएसएच (बिंदु खोज के लिए बेहतर अनुकूल) और रेंज (जैसा कि नाम से पता चलता है, रेंज स्कैन के लिए बेहतर अनुकूल है)।

हैश इंडेक्स का मुख्य घटक तथाकथित मैपिंग टेबल है, जिसके एक कॉलम में इंडेक्स कुंजी बनाने वाले क्षेत्रों के समतलीकरण के लिए हैश फ़ंक्शन को लागू करने के परिणाम संग्रहीत किए जाते हैं, दूसरे में, रिकॉर्ड करने के लिए पॉइंटर्स। चूंकि हैश फ़ंक्शन तर्क के पूरी तरह से अलग मूल्यों (करीबी लोगों के लिए उन्हें बस अलग होना है) के लिए एक ही परिणाम (टकराव पैदा होता है) दे सकता है, ये वास्तव में उन मेमोरी क्षेत्रों के संकेत होंगे जहां ओवरफ्लो चेन झूठ बोलते हैं। ऐसी प्रत्येक श्रृंखला एक द्वि-दिशात्मक सूची है। हैश इंडेक्स बनाते समय मुख्य पैरामीटर bucket_count है। यह मैच टेबल में स्लॉट की संख्या है। वे जितने कम होंगे, टकराव की संभावना उतनी ही अधिक होगी, प्रत्येक हैश से अधिक लंबी श्रृंखलाएं बढ़ेंगी। तदनुसार, यह स्पष्ट है कि यह सूचकांक कुंजी में अद्वितीय मूल्यों की संख्या से कम नहीं होना चाहिए। वास्तव में, यह 2 की अगली शक्ति तक गोल अनूठे मूल्यों की संख्या के रूप में अनुमानित है, और यह विस्तार से बताता है कि क्यों।

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

 CREATE TABLE dbo.UserSession ( SessionId int not null primary key nonclustered hash with (bucket_count=400000), UserId int not null, CreatedDate datetime2 not null, ShoppingCartId int, index ix_UserId nonclustered hash (UserId) with (bucket_count=400000) ) WITH (MEMORY_OPTIMIZED=ON, <b>DURABILITY=SCHEMA_ONLY</b>)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लिपि ३



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



मेमोरी में स्थित टेबल्स विशेष रूप से आंकड़ों के स्वत: अद्यतन का समर्थन नहीं करते हैं, विशेष रूप से, डेटा ... SET AUTO_UPDATE_STATISTICS ON। साथ ही काम नहीं करता है

exec sp_autostats @tblname = 'ShoppingCart'

इंडेक्स नाम AUTOSTATS अंतिम अपडेट

[ix_UserId] NULL से दूर

[PK__Shopping__7A789AE5730230283] बंद नाल

exec sp_autostats @tblname = 'ShoppingCart', @flagc = 'चालू'

- संचालन जिन्हें स्कीमा संस्करण में बदलाव की आवश्यकता होती है, उदाहरण के लिए नाम बदलने के लिए, मेमोरी अनुकूलित तालिकाओं के साथ समर्थित नहीं हैं।

हालांकि, आंकड़े मैन्युअल रूप से अपडेट किए जा सकते हैं: अद्यतन सांख्यिकी dbo.ShoppingCart FULLSCAN, NORECOMUTUTE के साथ।

सामान्य तौर पर, स्मृति में तालिकाओं में सीमाओं का एक गुच्छा होता है। अधिकांश टेबल संकेत समर्थित नहीं हैं: कोई टैब्लॉक, एक्सएलएक्स, पैग्लॉक, ... एनओएलओएक्स पर शपथ नहीं लेता है, लेकिन यह भी जवाब नहीं देता है, जैसे कि यह मौजूद नहीं था। गतिशील और कीसेट कर्सर चुपचाप स्थिर में अनुवाद करते हैं। TRUNCATE TABLE और MERGE कथन समर्थित नहीं हैं (जब स्मृति में तालिका गंतव्य है)। उपयोग किए जाने वाले क्षेत्रों के प्रकारों पर प्रतिबंध है। आप यहां उनके बारे में विस्तार से पढ़ सकते हैं, लेकिन परेशान न होने के लिए, हम देखेंगे कि क्या हुआ।

 SELECT name, description FROM sys.dm_os_loaded_modules WHERE description = 'XTP Native DLL'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लिपि ४



SQL सर्वर स्थापना निर्देशिका C: \ Program Files \ Microsoft SQL Server \ ... \ DATA \ xtp \ 11 \ dlls में दिखाई दिया, जिसे xtp_t_11_ <9 अंक> .dll कहा जाता है। ये हमारे ShoppingCart और UserSession टेबल हैं।

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



अगले भाग में, हम पारंपरिक डिस्क ऑब्जेक्ट्स की तुलना में हेक्टन, लॉक्स, जर्नलिंग और समग्र प्रदर्शन में संग्रहीत प्रक्रियाओं, लेनदेन अलगाव स्तरों के मूल संकलन पर विचार करने की योजना बनाते हैं।