क्या SSD पर भारी MySQL डेटा आयात इसे नुकसान पहुंचा सकता है?

Question

मुझे MySQL डेटाबेस में काफी डेटा (~ 100 मिलियन पंक्तियाँ, ~ 100 बार) आयात करना पड़ता है। वर्तमान में, यह मेरी हार्ड डिस्क ड्राइव पर संग्रहीत है, और मेरे आयात की अड़चन हार्ड डिस्क ड्राइव लिखने की गति प्रतीत होती है।

मैंने सुना है कि एसएसडी को बड़े पैमाने पर लगातार लिखना पसंद नहीं है, और यह उन्हें नुकसान पहुंचाता है। तुम क्या सोचते हो? क्या यह वास्तव में आधुनिक एसएसडी पर एक मुद्दा है?

Comments

जब तक आप ओवर-प्रोविजनिंग के लिए विभाजन वाले क्षेत्र के बाहर 2-3 जीबी (कहते हैं) छोड़ देते हैं, मुझे लगता है कि आप इसके साथ सुरक्षित हैं। मैं इसके साथ ज्यादा समस्या नहीं देखता हूं। अधिकांश SSD में पहले से ही डिस्क का कुछ हिस्सा है जो ऑपरेटिंग सिस्टम के लिए सुलभ नहीं है। हार्ड-ड्राइव बहुत भर जाने की स्थिति में पहनने के लेवलिंग और ओवरप्रोविजनिंग के लिए इस स्थान का उपयोग किया जाता है। ये अतिरिक्त जीबी एसएसडी को नुकसान से बचने के लिए डेटा वितरित करने के लिए अधिक जगह देंगे। यदि आप हार्ड-कोर हैं और इसके साथ आगे बढ़ना चाहते हैं, तो आप यह पता लगा सकते हैं कि आपके ssd में कितने मेमोरी चिप्स हैं और चिप के साथ 1GB दें। 10 चिप्स 10 बिना विभाजन के जीबी है।

— इस्माइल मिगुएल

यह कितना कम मूल्य का है, हम नियमित रूप से इससे कहीं अधिक डेटा आयात करते हैं। हमारी एक तालिका में आपके द्वारा आयात किए जा रहे डेटा की तुलना में बहुत अधिक डेटा है, और हमारे पास सौ टेबल के एक जोड़े हैं। हम SSDs का उपयोग करते हैं। मुझे उम्मीद है कि तुम ठीक हो जाओगे

— क्रिसइंमोंटॉन

आजकल SSD, OS सपोर्ट के बिना भी खुद को लेवलिंग पहनने के लिए काफी स्मार्ट हैं (भले ही OS उसी ब्लॉक को फिर से लिखने के लिए कहता हो, SSD का कंट्रोलर हर बार पारदर्शी तरीके से एक अलग ब्लॉक को लिखता है) इसलिए यह ठीक रहेगा।

रेड हेरिंग। SSDs की विफलता दर चिंता की बात नहीं है - यह काफी लंबा होगा कि वे अभी भी बराबर कताई जंग की तुलना में अधिक समय तक रहेंगे।

— सोब्रीक

लोग अपने SSDs के बारे में बहुत अधिक चिंता करते हैं। मूल रूप से आप कभी भी दुर्घटना से अपने SSD को "नष्ट" करने के लिए प्रबंधन नहीं करेंगे, और यहां तक ​​कि इसे उद्देश्य से करने पर सप्ताह या महीनों के निरंतर लेखन की आवश्यकता हो सकती है। यहां तक ​​कि अगर आप इसे "नष्ट" करते हैं, तो भी यह डेटा को केवल पढ़ने के लिए प्रदान करेगा। चिंता करना बंद करें और बस इसका उपयोग करें। आप यह भी पूछ सकते हैं कि आपका HDD का रीड / राइट हेड कैसे तेजी से खराब हो जाता है।

— mic_e

Answer 1

यह वास्तव में इसका सीधा जवाब नहीं है।

SSDs निरंतर लिखने के बारे में परवाह नहीं करते हैं कि किसी विशेष क्षेत्र को कितनी बार ओवरराइट किया जाता है। जब SSDs पहली बार बाहर निकले, तो SQL जैसा कुछ एक बुरा शब्द था क्योंकि सामान्य रूप से ऑपरेटिंग सिस्टम ने पारंपरिक HDD की तरह ड्राइव का इलाज किया था और विफलताएं अक्सर होती थीं।

तब से, ड्राइव बड़े, सस्ते, अधिक विश्वसनीय हो गए हैं, अधिक पढ़ने / लिखने के लिए और ऑपरेटिंग सिस्टम होशियार हो गए हैं।

SQL में SSDs न केवल आम है, बल्कि अक्सर प्रोत्साहित किया जाता है। डीबीए बहन साइट के लिए स्वतंत्र महसूस करें ।

मेरे विचार यह करने के लिए हैं, मान लें कि SQL सर्वर ठीक से अनावश्यक डिस्क के साथ बनाया गया है। यदि नहीं, तो वैसे भी असफलता की उम्मीद करें।

Comments

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

— एक CVn

@ माइकलकॉर्जलिंग हाँ, ठीक है। मेरे दिमाग में "ठीक से बनाया गया" भी असफलता के मामले में डेटाबेस का बैकअप मानता है ... लेकिन कभी-कभी ऐसा भी होता है जिसे छोड़ दिया जाना चाहिए ठीक नहीं है, धन्यवाद कहा जाना चाहिए।

— ऑस्टिन टी फ्रेंच

Answer 2

रीड्स ठीक हैं, और एसएसडी के बिना किसी हानिकारक प्रभाव से पढ़े गए उनके बिट्स हो सकते हैं।

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

मुझे केवल यह कहना चाहिए कि नए एंटरप्राइज़ ड्राइव पर लिखने की सीमा बहुत बड़ी है। सैमसंग के नए 845DC प्रो को लें। वारंटी पर 5 साल के लिए प्रति दिन 10 ड्राइव लिखना अच्छा है। मैं कल्पना करता हूं कि यह उस संख्या से दोगुना होगा। इसे संख्या में डालने के लिए, 800 जीबी मॉडल पर 5 वर्षों में 14,600 टीबी लिखा गया है।
या प्रति वर्ष 2920 टीबी,
या पांच साल के लिए प्रति दिन 8 टीबी ।

मुझे एक वारंटी के साथ एक हार्ड ड्राइव दिखाएं जो उस उपयोग को कवर करती है। मुझे यकीन नहीं है कि आप एक दिन में 8 टीबी को एचडीडी में लिख सकते हैं: - (50 एमबी / एस औसत थ्रूपुट * 60 (सेकंड) * 60 (मिनट) * 24 (घंटे) = 4,320,000 एमबी / दिन = 4.32 टीबी / दिन) यह पता चलता है कि आप (औसत ड्राइव पर) नहीं कर सकते।

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

SSD चलाने के लिए भी सस्ता है, कूलर, शांत और उद्यम मॉडल विशेष रूप से बिजली के मुद्दों के लिए प्रतिरोधी हैं। कोई और सिर दुर्घटना की आशंका नहीं है और निश्चित रूप से, आपके डेटाबेस एक्सेस की जरूरतों के लिए एक विशाल प्रदर्शन वृद्धि हुई है।

Comments

क्या मैं पूछ सकता हूं कि नीचे की ओर क्यों?

— Ctrl-alt-dlt

आप पूछ सकते हैं, लेकिन आप प्राप्त नहीं कर सकते, जाहिरा तौर पर।

— निधि मोनिका का मुकदमा

Answer 3

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

हालांकि इस लेख के अनुसार , डेटा के पेटाबाइट्स को एसएसडी को लिखा गया है और अभी भी परिचालन में है। यह संभवतः लेवलिंग पहनने के लिए अग्रिमों के कारण है :

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

आपकी विशेष स्थिति में मेरे पास गति के लिए एसएसडी पर डेटाबेस रहता है, लेकिन दैनिक आधार पर बैकअप होता है। तुम भी एक RAID 1 सरणी में दो SSDs प्राप्त करने पर विचार कर सकते हैं । एक ही समय में दो SSD के असफल होने की संभावना कम है।

नोट: RAID सरणियाँ बैकअप नहीं हैं !!!! कोई फर्क नहीं पड़ता कि आप एक RAID सरणी का उपयोग करते हैं या नहीं, एक बैकअप है। कोई फर्क नहीं पड़ता कि आप एक एसएसडी का उपयोग करते हैं या नहीं, एक बैकअप है।

Comments

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

— अरोन

लिंक किए गए लेख से: "एसएसडी में इलेक्ट्रॉनिक्स नंद के बाहर पहनने से बहुत पहले विफल हो रहे हैं" ... रुको, क्या?

— माइकल

Answer 4

मान लें कि आपके आयात में कोई अपडेट नहीं है और कोई विलोपन नहीं है। तो आप सभी सम्मिलन कर रहे हैं। यह केवल लेनदेन लॉग में नया डेटा लिखना चाहिए।

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

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

मान लें कि आप पूरी तरह से एसएसडी नहीं भर रहे हैं, तो उन हॉट स्पॉट (जैसे बफ़र्स / स्वैप) के लिए पर्याप्त खाली स्थान होना चाहिए, जो पहनने के स्तर के एल्गोरिदम के माध्यम से पहनने को कम करने के लिए मंथन किया जा रहा है।

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

Answer 5

यह कोई मुद्दा नहीं है।

सबसे पहले, पिछले वर्षों के दौरान एसएसडी में बहुत सुधार हुआ है। Overprovisioning और लेवलिंग (और एक छोटी राशि के लिए, TRIM कमांड, हालांकि आपके मामले में लागू नहीं है) ने उन्हें भारी शुल्क, सामान्य प्रयोजन डिस्क के रूप में काफी उपयुक्त बना दिया है। मैं अपने विकास पीसी (जो नियमित रूप से बहुत संकलन करता है) पर कुछ भी उपयोग नहीं कर रहा है, यहां तक ​​कि मिटाए चक्र चक्र के पास कहीं भी आने के बिना।

आगे, यह कथन:

SSDs को बड़े पैमाने पर निरंतर लिखना पसंद नहीं है, और यह उन्हें नुकसान पहुंचाता है

गलत है। इसके विपरीत, अक्सर छोटे लिखते हैं , अगर कुछ भी, एसएसडी को नुकसान हो सकता है।

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

इसलिए, बड़े लेखन बहुत SSD के अनुकूल होते हैं जबकि छोटे लेखन नहीं होते हैं।

छोटे लेखन के मामले में, नियंत्रक को एक ब्लॉक को पढ़ना होगा, कॉपी को संशोधित करना होगा, एक अलग ब्लॉक को मिटाना होगा और इसे प्रोग्राम करना होगा। कैशिंग के बिना, सबसे खराब संभव मामले में, आपको 512 किलोबाइट लिखने के लिए 512.000 ब्लॉक को मिटाना होगा। सबसे अच्छा संभव मामले में (बड़े, निरंतर लिखना) आपको ठीक 1 मिटाने की आवश्यकता है।

MySQL डेटाबेस में आयात करना कई अलग-अलग इंसर्ट प्रश्न करने से बहुत अलग है। इंजन बहुत सारे लेखन (डेटा और सूचकांक दोनों) को एक साथ समेटने में सक्षम है और आवेषण के प्रत्येक जोड़े के बीच सिंक की आवश्यकता नहीं है। यह एक बहुत अधिक SSD के अनुकूल लिखने के पैटर्न की मात्रा है।

Comments

सेक्टर पारंपरिक रूप से 1 KiB हैं? प्रशस्ति, कृपया। घूर्णी ड्राइव पर, दो सेक्टर आकार सामान्य होते हैं: 512 बाइट्स (पारंपरिक, मेरे 4 टीबी एचडीडी पर, आईबीएम-कॉम्पिटिबल्स में 1981 या इसके आसपास) और 4096 बाइट्स ("उन्नत प्रारूप")। फ़ाइल सिस्टम स्तर आवंटन इकाइयाँ आकार में भिन्न हो सकती हैं, लेकिन यह पूरी तरह से एक अलग मामला है और पूरी तरह से एक फ़ाइल सिस्टम का निर्माण है जो डेटा संरचनाओं को आवंटन को फ़ाइल सिस्टम में एक उचित आकार पर नज़र रखने के लिए बनाता है जो उन्हें एक आवश्यक रूप से गतिशील रूप से विकसित नहीं करते हैं ; इसके अलावा, मुझे संदेह है कि निश्चित 1 KiB ब्लॉक आकार व्यवहार में बहुत आम हैं।

— बजे एक CVn

@ MichaelKjörling: आपके बहुत मूल्यवान इनपुट के लिए धन्यवाद। आपने उत्तर को पढ़ा और समझा, क्या आपने नहीं किया? प्रासंगिक तथ्य यह है कि एसएसडी के भौतिक ब्लॉक आकार हैं, जो कि तार्किक क्षेत्र के आकार (जो कि मैंने कहीं भी 500 से 4096 बाइट्स, यहां तक ​​कि गैर-पावर-ऑफ-टू साइज़) को देखते हुए उससे कहीं अधिक बड़े हैं। कोई उद्धरण की जरूरत है।

— डेमॉन

Answer 6

एसएसडी को यह पसंद नहीं है। यदि आप अधिकतम लेखन गति 5-10 वर्ष (प्रति दिन 24 घंटे, प्रति सप्ताह 7 दिन) रखते हैं, तो आप एक टूटे हुए एसएसडी के साथ समाप्त हो सकते हैं।

ऑप्टिकल फाइबर केबल। 5 वर्षों के बाद अधिकांश सर्वर अपने जीवन के किफायती अंत तक पहुंच गए हैं।

अस्वीकरण:
SSD की पहली पीढ़ी के साथ यह कोशिश न करें। वे जहां कम मजबूत हैं।

Comments

मुझे अच्छी तरह से पता है कि इसकी अधिकतम क्षमता 7/24 में किसी भी डिस्क का उपयोग करने से यह खराब हो जाएगा ... मेरा प्रश्न यह है कि क्या यह सीमित समय के लिए सुरक्षित है (चलो 2-3 बार कई बार कहते हैं)

— क्रिस्टोफेट

@christophetd - यह निर्भर करता है। डेटा की मात्रा का अनुमान लगाने के लिए अपने प्रश्न को अपडेट करें। इसके ड्राइव के प्रतिशत के बारे में अधिक। 80GB SSD पर 20GB प्रति घंटा लिखना सबसे बुरा है तो 1TB SSD पर 20GB घंटे करना।

— रामहुंड

एक ही नोट पर: ज्यादातर खाली ड्राइव होने का मतलब है कि पहनने वाली लेवलिंग में कई 'खाली' फ्लैश सेल का इस्तेमाल किया जाता है। (और डेटा की समान मात्रा वाला एक बड़ा ड्राइव%-emtier है)।

— हेन्नेस

Answer 7

यदि आप वास्तव में विवरण का पता लगाने में रुचि रखते हैं तो आपको निम्नलिखित प्रश्न का उत्तर देने की आवश्यकता होगी:

प्रत्येक पंक्ति में औसतन कितने बाइट हैं?

यदि आप मुझे बता सकते हैं कि 10 कॉलम हैं, तो प्रत्येक कॉलम varchar (100) है, और एन्कोडिंग UTF-8 है तो मैं सबसे खराब स्थिति का अनुमान लगा सकता हूं कि आपके पास प्रति पंक्ति 4,000 बाइट्स का डेटा है और कुछ और बाइट्स जोड़ें मेटा-डेटा तो 4,200 बाइट्स देता है?

आपकी यातना SQL 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesडिस्क पर लिखे गए डेटा की गणना करता है

42,000,000,000,000 / 1000 = 42,000,000,000 KB

42,000,000,000 / 1000 = 42,000,000 एमबी

42,000,000 / 1000 = 42,000 जीबी

42,000 / 1000 = 42 टीबी

इस सैद्धांतिक सबसे खराब स्थिति में आप डिस्क पर 42 टीबी लिखेंगे

इस लेख के अनुसार , @ क्रोनो द्वारा प्रदान की गई आप अपनी यातना एसक्यूएल के लगभग 25 और दौरों के लिए अच्छी होनी चाहिए।

Answer 8

जैसा कि SSDs पर इस राइटअप के पोस्टर में कहा गया है, जो वास्तव में हानिकारक है वह फिर से और फिर से डेटा के छोटे हिस्से लिख रहा है।

• बिट्स को {1,2,3} -bit कोशिकाओं में संग्रहित किया जाता है। इनका जीवनकाल सीमित है।
• कोशिकाओं को [2-16] KB पृष्ठों (सबसे छोटी लेखन इकाई) में वर्गीकृत किया गया है
• पृष्ठ (128-256 पृष्ठ-) ब्लॉक (सबसे छोटी मिटा देने वाली इकाई) में वर्गीकृत किए गए हैं
• एक पृष्ठ के लिए फिर से लिखा जा सकता है, यह --- और उसके पूरे ब्लॉक --- को पहले मिटाने की आवश्यकता है

यही कारण है कि यह करने के लिए सिफारिश की है

• कभी भी एक पृष्ठ से कम न लिखें,
• बफर छोटे लिखते हैं, और
• पढ़ने और लिखने के अनुरोधों को अलग करें
• "एक बड़ा एकल-थ्रेडेड लेखन कई छोटे समवर्ती लेखन से बेहतर है"

तो, एक बहुत बड़ी राशि एक बार बेहतर लगता है।

Comments

यह उत्तर वास्तव में कोई भी प्रासंगिक जानकारी प्रदान नहीं करता है जो कहा नहीं गया है, इसके अलावा, मूल रूप से इसमें निहित लिंक के साथ एक टिप्पणी है।

— रामहुंड

@Rhhound: क्या आप अपनी टिप्पणी के लिए अपना ओके देंगे (धन्यवाद, btw), और यह भी, अप्रचलित को टैग करने के लिए? या आप अभी भी पहले से ही कहा / अप्रासंगिक जानकारी पर विचार करते हैं?

— सर्व-इंक

हालांकि इसकी अब कोई कड़ी नहीं है, ईमानदारी से, तकनीकी जानकारी ही, वास्तव में उपयोगकर्ता के सवाल पर लागू नहीं होती है, जो एसएसडी I पर डेटाबेस चलाने के संबंध में है

— रामहाउंड

@ रामहाउंड: मेरे लिए यह आयात के बारे में लग रहा था, न कि रनिंग के बारे में। डाउनवोट्स को देखते हुए, ऐसा लगता है कि आप सही हैं

— सर्व-