(5-2) तरीके एक बड़ी SQL तालिका माइग्रेट करने के लिए

परिचय

सभी को नमस्कार! यह मेरा पहला लेख है और मैं इसे C # में एक जूनियर डेवलपमेंट इंजीनियर की ओर से लिख रहा हूं। इसलिए एसक्यूएल के बारे में कोई विस्तृत जानकारी नहीं होगी, केवल व्यावहारिक जानकारी और विचारों के बजाय एक स्पष्ट समस्या को हल करने के बारे में जो मुझे खुद के रूप में नए लोगों के लिए सामना करना पड़ा।

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

तो, मान लें कि आपके पास HTML पत्रों की एक तालिका के साथ एक वेब सेवा और SQL (MS-SQL) डेटाबेस है जो आपकी सेवा उपयोगकर्ताओं को भेजता है। आँकड़े और विश्लेषण एकत्र करने के लिए आवश्यक होने के बाद से पत्र को कई वर्षों तक संग्रहीत किया जाता है और हटाया नहीं जा सकता है। हालांकि, हर साल पत्रों की संख्या बढ़ रही है, डेटाबेस बढ़ रहा है, और SQL सर्वर पर जगह छोटी हो रही है (हमारे मामले में, एक अन्य कारक डेटाबेस को परीक्षण स्थल पर बहाल कर रहा था, क्योंकि इसका समय आनुपातिक रूप से बढ़ गया था) और इसके लिए कुछ करने की आवश्यकता है करने के लिए। सौभाग्य से, हमारे मामले में नि: शुल्क स्थान का एक गुच्छा के साथ एक मुफ्त सर्वर है (वास्तव में यह नहीं हो सकता है, और निश्चित रूप से यह एक अस्थायी समाधान है, लेकिन यह लेख के दायरे से परे है)। तो समस्या एक बड़ी तालिका (और "बड़ी" कहने की वजह से उत्पन्न हुई, मेरा मतलब है कि वास्तव में बड़ी तालिका, सब कुछ जो मैंने इसी तरह के समाधानों की तलाश में देखा 60-100 जीबी के क्षेत्र में था, हमारे मामले में तालिका का वजन 300 जीबी से अधिक था)।

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

विधि -1। डेटा

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

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

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

विधि 0. चुनें INTO

मजाक =) तो आप केवल अपने आप को एक आधार रख सकते हैं। हालांकि, अगर हम तालिका के छोटे आकार (फिर आप यहां क्या कर रहे हैं) के बारे में बात कर रहे हैं, तो आप इस निर्देश का उपयोग करके डेटाबेस को स्थानांतरित करने का प्रयास कर सकते हैं। इसके अलावा, यदि आपके पास एक परीक्षण आधार है, तो आप "माथे पर" इस ​​पद्धति का उपयोग करके कुल हस्तांतरण समय का मूल्यांकन करने के लिए एक प्रयोग कर सकते हैं।

विधि 1. बैकअप

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

* वार्तालाप के लिए एक अलग विषय को हटाने पर, ऐसा लग सकता है कि यह स्थानांतरित करने की तुलना में बहुत तेज़ है, लेकिन ऐसा नहीं है और सामान्य स्थिति में मैं भागों में हटाने की सलाह देता हूं।

विधि 2: MS-SQL प्रबंधन स्टूडियो

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

विधि 3. विभाजन

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

परिणाम

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

अंत में, मैं 2 महत्वपूर्ण बिंदुओं को जोड़ना चाहूंगा।

SQL में पंक्तियों को स्थानांतरित / हटाने की कोई भी प्रक्रिया एक त्रुटि के मामले में सब कुछ वापस करने की क्षमता के लिए लेन-देन लॉग में लॉग की गई है (मैंने पहले यह मान लिया था कि यह केवल लेनदेन के ढांचे के भीतर किया जाता है)। इसके अलावा, लॉग का आकार डेटा की मात्रा से भी थोड़ा अधिक है। सुनिश्चित करें कि आपके पास जगह की आवश्यक मात्रा है या लॉगिंग को अक्षम करें, लेकिन यह सुरक्षित नहीं है।

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