Innodb_file_per_table का उपयोग क्यों?

Question

अतिशयोक्ति (बेशक IMHO) के लिए कई लेख हैं innodb_file_per_table। मैं समझता हूं कि innodb_file_per_tableव्यक्तिगत तालिकाओं पर बेहतर नियंत्रण होना चाहिए; हर टेबल का बैकअप अलग से लें। हालांकि, बेहतर प्रदर्शन का दावा संदिग्ध है।

मेरे परीक्षण में, 60GB के डेटाबेस के लिए innodb_file_per_tableऔर उसके प्रदर्शन में कोई अंतर नहीं है ibdata1। बेशक, यह सामान्य प्रश्नों के साथ एक सरल परीक्षा थी, और वास्तविक जीवन में जटिल प्रश्नों के लिए स्थिति अलग हो सकती है (यही कारण है कि मैंने यह प्रश्न पूछा था)। 64-बिट लिनक्स के साथ ext4बड़ी फ़ाइलों को प्रभावी ढंग से संभाल सकता है।

innodb_file_per_tableअधिक डिस्क के साथ , I / O संचालन की आवश्यकता होती है; और यह जटिल JOINएस और FOREIGN KEYबाधाओं में महत्वपूर्ण है ।

टेबल्सस्पेस एकल पर साझा किया जाता है ibdata; कैसे अलग मेज के लिए समर्पित टेबलस्पेस डिस्क स्थान बचा सकता है? बेशक, प्रत्येक तालिका के लिए टेबल स्पेस को मुक्त करना आसान है ALTER, लेकिन यह अभी भी एक महंगी प्रक्रिया है (टेबल लॉक के साथ)।

प्रश्न: क्या innodb_file_per_tablemysql के बेहतर प्रदर्शन पर कोई प्रभाव पड़ता है? यदि हाँ, तो क्यों?

Comments

मेरे प्रश्न का यह उत्तर देखें: dba.stackexchange.com/questions/7924/… साथ ही मदद कर सकता है।

— के.एम.

Answer 1

मुझे नहीं लगता कि यह प्रदर्शन की बात है लेकिन प्रबंधन की।

प्रति तालिका अलग फाइल के साथ, आप विभिन्न डेटाबेस को अलग-अलग स्टोरेज डिवाइस में स्टोर कर सकते हैं।

आप फ़ाइल सिस्टम में बहुत बड़े डेटाबेस के मामले से निपट सकते हैं जो बड़ी फ़ाइलों को संभाल नहीं सकते हैं (कम से कम समस्या को तब तक स्थगित कर सकते हैं जब तक कि एक फ़ाइल फ़ाइल आकार सीमा तक नहीं पहुंच जाती)।

आपके पास अनियंत्रित टेबलस्पेस वृद्धि नहीं है। यदि आपके पास कुछ बड़ी तालिकाएँ हैं जिन्हें आप छोड़ देते हैं, तो ibdataफ़ाइल छोटी रह जाती है।

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

Comments

तालिकाओं का विकास ठीक वैसा ही है जैसा आप चाहते हैं innodb_file_per_table ।

— जुज

Answer 2

Innodb_file_per_table का उपयोग क्यों?

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

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

यदि एक खोई हुई मेज को पुनर्प्राप्त करने का प्रयास किया जा रहा है, तो इसकी प्रतिलिपि .ibdऔर .frmफ़ाइल की प्रतिलिपि बनाने के लिए पर्याप्त होना चाहिए , साथ ही साथ information_schema(जो कि बहुत छोटा है ibdata1)। इस तरह, आप उन्हें एक डमी सर्वर में रख सकते हैं और पूरी, बड़े पैमाने पर चीज़ की नकल किए बिना अपनी तालिका निकाल सकते हैं।

हालांकि, बेहतर प्रदर्शन का दावा संदिग्ध है। … Innodb_file_per_table के साथ, अधिक डिस्क I / O संचालन की आवश्यकता है; और यह जटिल JOINs और FOREIGN KEY बाधाओं में महत्वपूर्ण है।

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

यह सच है कि फ़ाइल-प्रति-तालिका के साथ अधिक डिस्क I / O संचालन होंगे, लेकिन केवल थोड़ा अधिक। सिस्टम कैसे काम करता है, इसके बारे में सोचें।

• एक अखंड डेटाबेस के लिए:

  1. सर्वर शुरू किया गया है
  2. ibdata1 खोला है
  3. हेडर और मेटा-डेटा पढ़ा जाता है
  4. मेमोरी में स्ट्रक्चर और मेटा-डेटा कैश्ड हैं
  5. क्वेरीज़ होती हैं
     1. सर्वर डिस्क तक पहुंचता है और पहले से खोले गए डेटा को पढ़ता है ibdata1
     2. सर्वर डेटा को मेमोरी में कैश कर सकता है

• प्रति-तालिका डेटाबेस के लिए:

  1. सर्वर शुरू किया गया है
  2. ibdata1 खोला है
  3. हेडर और मेटा-डेटा पढ़ा जाता है
  4. प्रत्येक व्यक्ति .ibd फ़ाइल को खोला जाता है
  5. प्रत्येक से हैडर और मेटा-डेटा पढ़ा जाता है .ibd फ़ाइल
  6. मेमोरी में स्ट्रक्चर और मेटा-डेटा कैश्ड हैं
  7. क्वेरीज़ होती हैं
     1. सर्वर डिस्क तक पहुंचता है और पहले से खोले गए डेटा को पढ़ता है .ibd फ़ाइल
     2. सर्वर डेटा को मेमोरी में कैश कर सकता है

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

जैसे, सर्वर शुरू होने पर केवल कुछ और I / O ऑपरेशन होते हैं; दौड़ते समय नहीं। इसके अलावा, जबकि प्रत्येक व्यक्ति.ibd फ़ाइल का अपना अलग ओवरहेड (फ़ाइल हस्ताक्षर, संरचनाएं आदि) होता है, उन्हें मेमोरी में कैश किया जाता है और प्रत्येक क्वेरी के लिए पुनः नहीं पढ़ा जाता है। इसके अलावा, समान संरचनाओं को एक साझा टेबल-स्पेस के साथ भी पढ़ा जाता है, इसलिए मुश्किल से किसी भी (यदि कोई हो तो) अधिक मेमोरी की आवश्यकता होती है।

क्या innodb_file_per_table का mysql के बेहतर प्रदर्शन पर असर है?

वास्तव में, अगर कुछ भी, प्रदर्शन वास्तव में खराब हो सकता है ।

साझा तालिका-स्थान का उपयोग करते समय, पढ़ने और लिखने के संचालन को कभी-कभी / अक्सर जोड़ा जा सकता है ताकि सर्वर एक बार में कई तालिकाओं से डेटा का एक स्वैच पढ़े ibdata ।

हालाँकि, यदि डेटा कई फ़ाइलों के बीच फैला हुआ है, तो उसे हर एक के लिए अलग-अलग I / O ऑपरेशन करना होगा।

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

Tablespace सिंगल ibdata पर साझा किया जाता है; कैसे अलग तालिकाओं के लिए समर्पित टेबल डिस्क स्थान बचा सकता है?

ऐसा नहीं होता। यदि कुछ भी है, तो यह डिस्क उपयोग को बढ़ाता है ।

मेरे पास परीक्षण करने के लिए एक 60GB डेटाबेस नहीं है, लेकिन मेरे "पैलेट्री" व्यक्तिगत डेटाबेस में मेरा वर्डप्रेस इंस्टॉलेशन और व्यक्तिगत उपयोग और विकास परीक्षण के लिए कुछ छोटे टेबल हैं, जो साझा टेबल-स्पेस का उपयोग करते हुए ~ 30 एमबी में वजन करते हैं। इसे फ़ाइल-प्रति-तालिका में परिवर्तित करने के बाद, यह ~ 85MB तक फूल गया। यहां तक ​​कि सब कुछ छोड़ने और फिर से आयात करने से, यह अभी भी> 60 एमबी था।

यह वृद्धि दो कारकों के कारण है:

• के लिए पूर्ण न्यूनतम आकार ibdata1है- किसी कारण के लिए — 10 एमबी, भले ही आपके पास इसमें कुछ भी न हो, लेकिन इसमें information_schemaसंग्रहित न हो।

• एक साझा तालिका-स्थान के साथ, केवल ibdata1ओवरहेड जैसे फ़ाइल हस्ताक्षर, मेटा-डेटा, आदि हैं, लेकिन प्रति-तालिका के साथ, प्रत्येक व्यक्तिगत .ibdफ़ाइल में वह सब है। इसका मतलब है कि कुल (यहां तक ​​कि एक काल्पनिक <10MB ibdata1) कम से कम कुछ बड़ा होगा:

  GetTotalSizeofOverhead() * GetNumTables()

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

Answer 3

यह हमेशा हमेशा के लिए innodb_file_per_table का उपयोग करने का मेरा कारण है:

प्रति तालिका फ़ाइल के बिना, ibdata फ़ाइल कभी भी संकुचित या सिकुड़ती या कम नहीं होती है। जब आप कोई पंक्ति नहीं हटाते हैं, तो एक तालिका, या एक डेटाबेस ड्रॉप करें। यदि आप एक सक्रिय कतार प्रणाली है, तो 2GB डेटा कुछ ही समय में 20GB फ़ाइल बन सकता है।

मान लें कि आप परिवर्तन से पहले अपनी वर्तमान 1GB तालिका का बैकअप बनाना चाहते हैं, फिर बाद में इसे छोड़ दें। आप अपने ibdata में अब अप्रयुक्त स्थान की एक जीबी के साथ फंस गए हैं। ओह।

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

इसके अलावा, यहाँ पढ़ने के लिए एक अच्छी पोस्ट है: http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table

Comments

मुझे एहसास हुआ कि यह हमेशा ऐसा करने के लिए अच्छा है। SSD द्वारा समर्थित चुंबकीय भंडारण सरणियों को तालिकाओं के लिए छोटी फ़ाइलों के मुकाबले अधिक प्रभावी ढंग से कैश पढ़ / लिख सकते हैं। तालिकाओं के गुच्छा के लिए, जो उस समय का 99.99% सिर्फ 'पढ़ा' जाता है, लेकिन लिखा नहीं जाता है, वे हमेशा स्टोरेज कंट्रोलर के कैश में होते हैं, जो प्रतिक्रिया समय में बहुत कमी है।

— sdkks

Answer 4

मेरा कारण innodb_file_per_table का उपयोग न करना प्रदर्शन है।

मैंने mysql 5.5.45 लिनक्स सेंटोस रिलीज़ 6.7 पर 450 तालिकाओं के साथ हमारे डेटाबेस के लिए कुछ परीक्षण किए

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

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

हो सकता है कि आप यह जान सकें कि उत्पादन सर्वर के लिए आप innodb_file_per_table का उपयोग कर सकते हैं, लेकिन CI वातावरण के लिए (एकीकरण जारी रखता है) जो इकाई परीक्षण शुरू करता है (DB का उपयोग करता है) और भी डेवलपर्स जो इकाई परीक्षण शुरू करते हैं बहुत बेहतर है प्रदर्शन के कारण इसका उपयोग न करें।

Comments

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

— कॉलिनएम

Answer 5

यह डेटा को अधिक प्रबंधनीय बनाता है क्योंकि आप अप्रयुक्त स्थान को पुनः प्राप्त कर सकते हैं, जो अच्छा है।

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

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

यहाँ किसी से एक पोस्ट है कि इस मुद्दे का अनुभव किया है: http://umangg.blogspot.com/2010/02/innodbfileper.net.html

Answer 6

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

innodb_file_per_table ibdata भंडारण की तुलना में बड़े पैमाने पर निर्माण और छोड़ने वाली वस्तुओं को धीमा कर देता है और उत्पादन के लिए लागू नहीं होता है लेकिन निरंतर परीक्षण के लिए प्रासंगिक होना चाहिए।

https://www.percona.com/blog/2015/02/24/mysqls-innodb_file_per_table-slowing/

Answer 7

IMHO यह बेहतर है innodb_file_per_table का उपयोग करें, यह अधिक सुरक्षित है। यदि आप इसका उपयोग नहीं करते हैं, तो आपको FAT32 सिस्टम पर समस्या हो सकती है जहां केवल 4 जीबी फ़ाइल की अनुमति है। मैंने इसके बारे में स्लोवाक भाषा में लेख लिखा था ( https://www.itsoft.sk/preco-sa-neuvolni-miesto-na-disku-po-zmazani-mysql-tabulky/ )।