मेमोरी ऑप्टिमाइज़्ड टेबल्स - क्या वास्तव में उन्हें बनाए रखना इतना मुश्किल हो सकता है?


18

मैं एमएस एसक्यूएल 2012 से 2014 तक के उन्नयन के लाभों की जांच कर रहा हूं। एसक्यूएल 2014 के बड़े बिक्री बिंदुओं में से एक मेमोरी ऑप्टिमाइज़ टेबल है, जो स्पष्ट रूप से प्रश्नों को सुपर-फास्ट बनाता है।

मैंने पाया है कि मेमोरी अनुकूलित तालिकाओं पर कुछ सीमाएँ हैं, जैसे:

  • कोई (max)आकार फ़ील्ड नहीं
  • अधिकतम ~ 1KB प्रति पंक्ति
  • कोई timestampखेत नहीं
  • कोई संगणित स्तंभ नहीं
  • कोई UNIQUEअड़चन नहीं

ये सभी उपद्रव के रूप में योग्य हैं, लेकिन अगर मैं वास्तव में प्रदर्शन लाभ प्राप्त करने के लिए उनके आसपास काम करना चाहता हूं, तो मैं एक योजना बना सकता हूं।

असली किकर तथ्य यह है कि आप एक ALTER TABLEबयान नहीं चला सकते हैं , और आपको हर बार जब आप एक सूचकांक की सूची में एक फ़ील्ड जोड़ते हैं तो आपको इस रिग्मारोल से गुजरना होगाINCLUDE । इसके अलावा, ऐसा प्रतीत होता है कि आपको लाइव DB पर MO तालिकाओं में कोई भी स्कीमा परिवर्तन करने के लिए सिस्टम से उपयोगकर्ताओं को बंद करना होगा।

मुझे यह पूरी तरह से अपमानजनक लगता है, इस हद तक कि मैं वास्तव में विश्वास नहीं कर सकता कि Microsoft इस सुविधा में बहुत अधिक विकास पूंजी लगा सकता था, और इसे बनाए रखने के लिए इतना अव्यावहारिक छोड़ दिया। यह मुझे इस निष्कर्ष पर ले जाता है कि मुझे छड़ी के गलत छोर को प्राप्त करना होगा; मुझे स्मृति-अनुकूलित तालिकाओं के बारे में कुछ गलत समझ लेना चाहिए, जिससे मुझे विश्वास हो गया कि वास्तव में यह है कि उन्हें बनाए रखना कहीं अधिक कठिन है।

तो, मुझे क्या गलत समझा है? क्या आपने MO तालिकाओं का उपयोग किया है? क्या किसी प्रकार का गुप्त स्विच या प्रक्रिया है जो उन्हें उपयोग करने और बनाए रखने के लिए व्यावहारिक बनाती है?

जवाबों:


18

नहीं, इन-मेमोरी वास्तव में यह अनपॉलिज्ड है। यदि आप एजाइल से परिचित हैं, तो आप "न्यूनतम shippable उत्पाद" की अवधारणा को जान पाएंगे; इन-मेमोरी वह है। मुझे लगता है कि MS को SAP के हाना और उसके ilk की प्रतिक्रिया की आवश्यकता थी। यह वही है जो 2014 की रिलीज के लिए समय सीमा में डिबग किया जा सकता है।

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


SQL सर्वर 2016 अब आम तौर पर उपलब्ध है। जैसा कि मैंने माना था, In-Memory OLTP को कई एन्हांसमेंट मिले हैं। अधिकांश परिवर्तन कार्यक्षमता को लागू करते हैं जो पारंपरिक तालिकाओं ने कुछ समय के लिए आनंद लिया है। मेरा अनुमान है कि भविष्य की विशेषताओं को एक ही समय में मेमोरी और पारंपरिक टेबल दोनों के लिए जारी किया जाएगा। टेम्पोरल टेबल एक केस-इन-पॉइंट है। इस संस्करण में नया यह इन-मेमोरी और डिस्क-आधारित तालिकाओं दोनों द्वारा समर्थित है ।


14

नई तकनीक के साथ समस्याओं में से एक - विशेष रूप से एक वी 1 रिलीज जिसे बहुत जोर-शोर से खुलासा किया गया है, जो कि फीचर-पूर्ण नहीं है - यह है कि हर कोई बैंडबाजे पर कूदता है और मानता है कि यह प्रत्येक कार्यभार के लिए एकदम सही है। यह। हेकोटन का प्यारा स्थान 2-4 सॉकेट पर बहुत सारे बिंदुओं के साथ ओएलटीपी वर्कलोड 256 जीबी है। क्या यह आपके कार्यभार से मेल खाता है?

कई सीमाओं को मूल रूप से संकलित प्रक्रियाओं के साथ इन-मेमोरी टेबल के साथ करना पड़ता है। आप निश्चित रूप से इन-मेमोरी टेबल का उपयोग करके इन सीमाओं में से कुछ को बाईपास कर सकते हैं, लेकिन मूल रूप से संकलित प्रक्रियाओं का उपयोग नहीं कर सकते हैं, या कम से कम विशेष रूप से नहीं।

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

मूल रूप से, अगर यह आपके लिए अभी तक इसके V1 रूप में इसके लायक नहीं है, तो इसका उपयोग न करें। यही कारण है कि एक सवाल हम आप के लिए जवाब कर सकते हैं नहीं है, आपको बताना है कि ग्राहकों के बहुत सिवाय हैं सीमाओं के साथ रहने के लिए तैयार है, और उन्हें के बावजूद महान लाभ के लिए सुविधा का उपयोग कर रहे हैं।

SQL सर्वर 2016

यदि आप SQL सर्वर 2016 की ओर अपने रास्ते पर हैं, तो मैंने इन-मेमोरी ओएलटीपी में आपके द्वारा देखे जाने वाले एन्हांसमेंट के साथ-साथ कुछ सीमाओं के उन्मूलन के बारे में भी ब्लॉग किया है । सबसे एहम:

  • अधिकतम टिकाऊ तालिका आकार में वृद्धि: 256 जीबी => 2 टीबी
  • LOB / MAX कॉलम, Nullable कॉलम पर अनुक्रमणिका, BIN2 टकराव आवश्यकताओं को हटाने
  • प्रक्रियाओं की पुनरावृत्ति और पुनरावृत्ति
  • ALTER TABLE के लिए कुछ समर्थन - यह ऑफ़लाइन होगा लेकिन आपको अनुक्रमणिका को बदलने और / या ड्रॉप / री-क्रिएट करने में सक्षम होना चाहिए (हालांकि यह वर्तमान CTP बिल्ड पर समर्थित नहीं लगता है, इसलिए इसे गारंटी के रूप में न लें)
  • DML ट्रिगर्स, FK / चेक की कमी, MARS
  • OR, NOT, IN, EXISTS, DISTINCT, UNION, OUTER JOINs
  • समानता

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

3
@ अंश ठीक है, इसलिए इसका उपयोग न करें। या केवल स्थिर तालिकाओं को स्मृति में रखें। या एक अलग डिज़ाइन पर विचार करें जहाँ आप लगातार कॉलम (EAV) जोड़ रहे हैं। जैसा कि यह है, मुझे लगता है कि आप सिर्फ यह कह रहे हैं कि यह तकनीक आपके लिए नहीं है। मेरे बच्चे हैं इसलिए मुझे कोई शिकायत नहीं है कि पोर्श केमैन एस मेरे लिए व्यावहारिक नहीं है - या कम से कम एक दैनिक चालक के रूप में नहीं। शायद मैं इसे सप्ताहांत पर उपयोग कर सकता हूं (जैसे शायद आप अपने स्कीमा के कुछ हिस्सों के लिए इन-मेमोरी ओएलटीपी का उपयोग कर सकते हैं, लेकिन सब कुछ नहीं)। यह तथ्य कि आपके पास ऐसी आवश्यकताएं हैं जो कि आम नहीं हैं, और V1 सुविधाओं के साथ यह संघर्ष, Microsoft की गलती नहीं है।
हारून बर्ट्रेंड

हारून, ईएवी क्या है?
शाऊल बेहार


2

आप Sql प्रबंधन प्रबंधन स्टूडियो के भीतर से, एक डिज़ाइनर को खींचने के लिए और एक डिज़ाइन किए गए नए कॉलम को राइट-क्लिक नहीं कर सकते । आप तालिका का नाम बदलने के साधन के रूप में तालिका नाम के भीतर भी क्लिक नहीं कर सकते । (एसक्यूएल 2014 मेरे इस लेखन के रूप में।)

इसके बजाय, आप तालिका पर राइट क्लिक कर सकते हैं, और एक नई क्वेरी विंडो के लिए एक कमांड बना सकते हैं। यह क्रिएट कमांड किसी भी नए कॉलम को जोड़कर संशोधित किया जा सकता है।

इसलिए, तालिका को संशोधित करने के लिए, आप डेटा को एक नई तालिका, अस्थायी तालिका या तालिका चर में संग्रहीत कर सकते हैं । तब आप तालिका को नए स्कीमा और अंत में छोड़ सकते हैं और बना सकते हैं में वास्तविक डेटा में वापस कॉपी कर सकते हैं । यह 3 कंटेनर शेल गेम ज्यादातर उपयोग के मामलों के लिए केवल थोड़ा कम सुविधाजनक है।

लेकिन, आपके पास मेमोरी ऑप्टिमाइज़्ड तालिकाओं से परेशान होने का कोई कारण नहीं है यदि कोई प्रदर्शन समस्या नहीं है जिसे आप हल करने का प्रयास कर रहे हैं।

फिर, यदि आपके उपयोग के मामले में सीमाएँ और कार्य-मूल्य इसके लायक हैं, तो आपको तौलना होगा। क्या आपको प्रदर्शन की समस्या है? क्या आपने बाकी सब कुछ आज़माया है? क्या इससे आपके प्रदर्शन में 10-100 गुना सुधार होगा? इसका उपयोग करना या इसका उपयोग नहीं करना संभवत: किसी भी तरह से बिना मस्तिष्क-मस्तिष्क के थोड़ा सा होने की संभावना है।


-2

आप किसी भी बड़ी समस्या के बिना ऑपरेशनल सर्वर में इन-मेमोरी ओएलटीपी का उपयोग कर सकते हैं। हमने इस तकनीक का उपयोग बैंकिंग और भुगतान कंपनी में किया है,

सामान्य तौर पर हम कार्य-भार बहुत अधिक होने पर स्मृति-अनुकूलित तालिकाओं का उपयोग कर सकते हैं। इन-मेमोरी ओएलटीपी का उपयोग करके आप 30X तक बेहतर प्रदर्शन तक पहुंच सकते हैं! Microsoft SQL सर्वर 2016 और 2017 में इस सीमाओं को ठीक करता है। स्मृति-अनुकूलित तालिकाओं में डिस्क-आधारित तालिकाओं की तुलना में पूरी तरह से अलग वास्तुकला है।

मेमोरी-ऑप्टिमाइज़्ड टेबल दो तरह की होती हैं। टिकाऊ टेबल और nondurable टेबल। टिकाऊ और गैर-टिकाऊ तालिकाएँ मेमोरी में टेबल डेटा को बनाए रखती हैं। Furthemore टिकाऊ टेबल रिकवरी डेटा और स्कीमा के लिए डिस्क पर डेटा को बनाए रखता है। अधिकांश परिचालनात्मक परिदृश्‍य में हमें टिकाऊ तालिकाओं का उपयोग करना चाहिए, क्योंकि यहां खोए गए डेटा महत्वपूर्ण हैं। ईटीएल लोडिंग और कैशिंग के लिए कुछ परिदृश्य में हम nondurable तालिकाओं का उपयोग कर सकते हैं।

आप इस ई-बुक्स का उपयोग कर सकते हैं और इस तकनीक का उपयोग करना सीख सकते हैं:

कालेन डेलाने: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

दिमित्री कोरोटेविच: https://www.apress.com/gp/book/9781484227718

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.