एकल थ्रेडेड बनाम मल्टीथ्रेडेड डेटाबेस प्रदर्शन के बारे में


58

H2 प्रदर्शन के संबंध में एक अच्छी प्रतिष्ठा वाला एक एकल थ्रेडेड डेटाबेस है। अन्य डेटाबेस बहु-थ्रेडेड हैं।

मेरा सवाल है: जब एक मल्टी-थ्रेड डेटाबेस एक सिंगल थ्रेड डेटाबेस से अधिक दिलचस्प हो जाता है? कितने उपयोगकर्ता हैं? कितनी प्रक्रियाएं? ट्रिगर क्या है? किसी को भी साझा करने का अनुभव है?

सारांश

  • सामान्य अड़चन डिस्क एक्सेस है
  • SSD तेज हैं, लेकिन नाजुक (विफलता प्रक्रिया एक है)
  • एक सिंगल थ्रेड सिस्टम पर एक लंबी क्वेरी अन्य सभी को ब्लॉक कर देगी
  • मल्टी-थ्रेडिंग सिस्टम को कॉन्फ़िगर करना मुश्किल हो सकता है
  • सिंगल कोर सिस्टम पर भी मल्टीथ्रेडेड डेटाबेस फायदेमंद होते हैं

इस प्रश्न के उद्देश्य के लिए थ्रेड का अर्थ है "धागा या प्रक्रिया" जहां तक ​​मैं बता सकता हूं - जैसे पोस्टग्रैज मल्टी-थ्रेडेड नहीं है, लेकिन प्रश्न (H2, पोस्टग्रेज) की तुलना (Oracle, SQL सर्वर आदि) से करने की कोशिश नहीं कर रहा है
जैक डगलस

जवाबों:


31

यहाँ मेरी राय है:

आमतौर पर एक DB सिस्टम का टोंटी (या सबसे धीमा हिस्सा) डिस्क है। सीपीयू केवल अंकगणितीय संचालन, प्रसंस्करण या सीपीयू के किसी अन्य कार्य के दौरान घूमता है। उचित आर्किटेक्चर के साथ, मल्टीथ्रेडिंग धीमी डिस्क रीड / राइट करने के बजाय सीपीयू पर क्वेरी के भार को ऑफसेट करने में मदद कर सकती है। ऐसे मामले हैं जहां एक गणना किए गए कॉलम (जो पहले डिस्क पर सहेजा गया था) बनाने के लिए सीपीयू चक्रों का उपयोग करके एक मूल्य की गणना करना तेजी से है और डिस्क से इस कॉलम को पढ़ें।

कुछ RDBMS में एक अस्थायी DB (tempdb) होता है, जिसका उपयोग सभी DBs द्वारा सॉर्टिंग, हैशिंग, अस्थायी चर आदि के लिए किया जाता है ... इस tempdb फ़ाइलों को गुणा करने और विभाजित करने का उपयोग tempdb के थ्रूपुट को बेहतर बनाने के लिए किया जा सकता है , जिससे समग्र सर्वर प्रदर्शन में सुधार होता है।

मल्टीथ्रेडिंग (समानांतरवाद) का उपयोग करके, क्वेरी के परिणाम सेट को केवल एक कोर का उपयोग करने के बजाय सर्वर के विभिन्न कोर पर संसाधित होने के लिए विभाजित किया जा सकता है। यह सुविधा हमेशा प्रदर्शन में सुधार नहीं करती है, लेकिन ऐसे मामले हैं जहां यह करता है, और इसलिए यह सुविधा उपलब्ध है।

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

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


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

@Stan - मुझे लगता multithreadedहै कि इस संदर्भ में इसका मतलब कुछ अलग है , अर्थात सभी लेन-देन क्रमबद्ध हैं क्योंकि ल्यूक ने अपने उत्तर में उल्लेख किया है।
जैक डगलस

@JVststry ~ नहीं, वास्तव में नहीं। SSDs पर जेफ एटवुड के विचारों को पढ़ें ... उनके पास उच्च विफलता दर है। सबसे अच्छी बात यह है कि डेटा को अच्छी तरह से अनुक्रमित करना और अच्छी तरह से लिखित प्रश्नों का होना।
jcolebrand

@jcolebrand ठीक है, उन्हें लगता है कि जब वे विफल होते हैं, तब केवल एक मजबूत बैकअप प्रणाली के साथ गति के लिए उनकी वकालत करते हैं
Jérôme Verstrynge

2
@Jverstry ~ हाँ, और यदि आप उस अवधारणा को समझते हैं, और इसके साथ ठीक हैं, और अपने संपूर्ण उत्पादन वातावरण को फिर से बनाने में मन नहीं लगाते हैं (या किक करने के लिए स्वचालित विफलता का इंतजार कर रहे हैं और फिर निकट भविष्य में किसी बिंदु पर पुनर्निर्माण कर रहे हैं) इसके लिए जाओ, वे चीजों को अभी भी तेज कर देंगे, हां।
jcolebrand

47

अगर एक बात है जो मैं कह सकता हूं कि MySQL के बारे में यह है कि InnoDB, इसका ट्रांसेक्शनल (ACID-compliant) स्टोरेज इंजन, वास्तव में मल्टीथ्रेडेड है। हालाँकि, यह उतना ही गुणित है जितना कि आप CONFIGURE IT! यहां तक ​​कि सही "बॉक्स से बाहर," एक डिफ़ॉल्ट सीपीयू वातावरण में InnoDB शानदार प्रदर्शन करता है। InnoDB मल्टीथ्रेडिंग क्षमताओं का लाभ उठाने के लिए, आपको कई विकल्पों को सक्रिय करना याद रखना चाहिए।

innodb_thread_concurrency ऊपरी समवर्ती धागों की संख्या पर ऊपरी सीमा निर्धारित करता है जिसे InnoDB खुला रख सकता है। इसके लिए सेट करने के लिए सबसे अच्छा राउंड नंबर (सीपीयू का 2 एक्स नंबर) + डिस्क की संख्या है। अद्यतन : जैसा कि मैंने पेरकोना एनवाईसी कॉन्फ्रेंस से पहली बार सीखा है, आपको इनओबीडी स्टोरेज इंजन को अलर्ट करने के लिए इसे 0 पर सेट करना चाहिए ताकि जिस पर्यावरण में यह चल रहा है उसके लिए सबसे अच्छी संख्या में थ्रेड मिलें।

innodb_concurrency_ticket ऐसे थ्रेड्स की संख्या सेट करता है जो इंक्यूबेशन के साथ कंसीडर चेकिंग को बायपास कर सकते हैं। उस सीमा तक पहुँच जाने के बाद, थ्रेड कंसिस्टेंसी जाँच फिर से आदर्श बन जाती है।

innodb_commit_concurrency समवर्ती लेनदेन की संख्या निर्धारित करता है जिसे प्रतिबद्ध किया जा सकता है। चूंकि डिफॉल्ट 0 होता है, इसे सेट न करना किसी भी तरह के लेनदेन को एक साथ करने की अनुमति देता है।

innodb_thread_sleep_delay, इनसोबी क्यू को पुनः दर्ज करने से पहले एक InnoDB धागा मिलिसेकंड की संख्या निर्धारित करता है। डिफ़ॉल्ट 10000 (10 सेकंड) है।

innodb_read_io_threads और innodb_write_io_threads (MySQL 5.1.38 के बाद से दोनों) पढ़े और लिखने के लिए निर्दिष्ट थ्रेड की संख्या आवंटित करते हैं। डिफ़ॉल्ट 4 है और अधिकतम 64 है।

innodb_replication_delay थ्रेड में देरी को थोपता है दास पर innodb_thread_concurrency पहुँच जाता है।

innodb_read_ahead_threshold एसिंक्रोनस रीडिंग पर स्विच करने से पहले extents की निर्धारित संख्या (64 पृष्ठ [पेज = 16K]) की रेखीय रीडिंग की अनुमति देता है।

अगर मैंने और विकल्प चुने तो समय बच जाएगा। आप उनके बारे में MySQL के डॉक्यूमेंटेशन में पढ़ सकते हैं ।

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

मैंने MySQL 5.5 के कई बफ़र पूल इंस्टेंसेस (9 बफ़र पूल इंस्टेंसेस में 162GB) के साथ खेला है और इस तरह से मेमोरी में डेटा ऑटो-पार्टिशन करने का प्रयास किया है। कुछ विशेषज्ञों का कहना है कि इससे आपको 50% प्रदर्शन में सुधार होना चाहिए। मुझे जो मिला, वह एक टन धागा लॉकिंग था जो वास्तव में InnoDB क्रॉल बना था। मैंने 1 बफर (162GB) पर स्विच किया और दुनिया में फिर से सब ठीक हो गया। मुझे लगता है कि आपको इसे सेट करने के लिए पेरकोना विशेषज्ञों की आवश्यकता होगी। मैं कल न्यूयॉर्क में पेरकोना MySQL सम्मेलन में आऊंगा और इस बारे में पूछूंगा कि यदि अवसर खुद ही आ जाता है।

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

सुप्रभात, शुभ संध्या, और शुभ रात्रि !!!

UPDATE 2011-05-27 20:11

गुरुवार को न्यूयॉर्क में पेरकोना MySQL सम्मेलन से वापस आ गया । क्या सम्मेलन? बहुत कुछ सीखा है, लेकिन मुझे एक जवाब मिला है कि मैं InnoDB के बारे में देखूंगा। मुझे रोनाल्ड ब्रैडफोर्ड ने बताया कि innodb_thread_concurrency को 0 पर सेट करने से InnoDB थ्रेड कॉन्सिरेन्सी के साथ आंतरिक रूप से कार्रवाई का सबसे अच्छा पाठ्यक्रम तय करेगा। मैं इसके साथ MySQL 5.5 में आगे प्रयोग करूंगा।

UPDATE 2011-06-01 11:20

जहां तक ​​एक लंबी क्वेरी का सवाल है, तो InnoDB ACID- अनुरूप है और मल्टीवर्जन कंसीलर कंट्रोल का उपयोग करके बहुत अच्छी तरह से संचालित होता है । लेन-देन को अलगाव स्तर (डिफ़ॉल्ट रूप से दोहराए जाने योग्य रीड) में सक्षम होना चाहिए जो दूसरों को डेटा तक पहुंचने से रोकता है।

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


11

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

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

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

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


क्या H2 सभी अनुरोधों को क्रमबद्ध करता है - या केवल DML?
जैक डगलस

8

जो मैं बता सकता हूं, उससे "सिंगल थ्रेडेड" H2 के लिए एक मिथ्या नाम है। मुद्दा यह है कि यह सभी लेन-देन को क्रमबद्ध करता है (यानी उन्हें एक बार में एक करता है)।

इस बारे में महत्वपूर्ण प्रश्न कि क्या "ठीक है" या आपके आवेदन के लिए नहीं है "कितने उपयोगकर्ता हैं?" या यहां तक ​​कि "कितनी प्रक्रियाएं?", लेकिन "मेरे लेन-देन कब तक होने वाले हैं?"

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

--EDIT

ऐसा लगता है कि H2 वास्तव में लेनदेन को अनुक्रमित नहीं करता है - सिर्फ DML। दूसरे शब्दों में, एक एकल लेन-देन के भीतर बहुत सारे लघु अद्यतन अन्य अद्यतनों को अवरुद्ध नहीं करेंगे । हालाँकि जब तक आप प्रयोगात्मक MVCC सुविधा का उपयोग कर रहे हैं , टेबल लॉकिंग का मतलब है कि यह व्यवहार में समान प्रभाव डालता है। एक प्रायोगिक "मल्टी_थ्रेड" सुविधा भी है लेकिन इसका उपयोग उसी समय नहीं किया जा सकता है जब एमवीसीसी के रूप में


5

PostgreSQL साइट से बिट्स और टुकड़े उद्धृत करते हुए ... कृपया ध्यान दें कि मुझे इन तर्कों के गुणों का बिल्कुल पता नहीं है - वे केवल एक टिप्पणी में फिट नहीं थे।

डेवलपर से अक्सर पूछे जाने वाले प्रश्न ("थ्रेड्स का उपयोग क्यों नहीं किया जाता है ..."):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

वर्तमान में बैकएंड के लिए कई प्रक्रियाओं के बजाय थ्रेड्स का उपयोग नहीं किया जाता है क्योंकि: (...)

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

टोडो सूची से ("सुविधाएँ जो हमें नहीं चाहिए"):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

सभी एक ही प्रक्रिया में धागे के रूप में चल रहे हैं (नहीं चाहता था)

यह वर्तमान सेटअप से हमें प्राप्त होने वाली प्रक्रिया सुरक्षा को समाप्त कर देता है। थ्रेड निर्माण आमतौर पर आधुनिक सिस्टम पर प्रक्रिया निर्माण के रूप में एक ही ओवरहेड है, इसलिए यह शुद्ध थ्रेडेड मॉडल का उपयोग करने के लिए नासमझ लगता है, और MySQL और DB2 ने प्रदर्शित किया है कि थ्रेड्स कई मुद्दों को हल करते हैं। (...)

तो, फिर से ... मैं बिल्कुल ऊपर के गुण के बारे में पता नहीं है। यह एक टिप्पणी में फिट होने के लिए बहुत लंबा था।


-3

जब आप 1 से अधिक समानांतर क्वेरी डेटाबेस में जा रहे हों, तो एक मल्टीथ्रेडेड डेटाबेस आपको लाभान्वित करेगा। यह आपके उपयोगकर्ताओं की संख्या पर निर्भर करता है। यदि आपके पास एक ही समय में दस से अधिक उपयोगकर्ता काम कर रहे हैं, तो सबसे अधिक संभावना है कि वे एक ही समय में डेटाबेस पर एक से अधिक क्वेरी का उत्पादन करने जा रहे हैं।

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

क्या यह आपके प्रश्न का उत्तर देता है?


7
सिंगल कोर सिस्टम पर भी मल्टीथ्रेडेड डेटाबेस फायदेमंद होते हैं। यह अन्य सभी डेटाबेस एक्सेस को ब्लॉक करने से एक लंबे समय तक चलने वाली क्वेरी को रोकता है, साथ ही आप डिस्क या नेटवर्क I / O पर प्रतीक्षा कर रहे कई थ्रेड्स हो सकते हैं, जबकि एक अन्य थ्रेड सक्रिय रूप से प्रश्नों को पार्स कर रहा है, पूर्वनिर्मित डेटा को संसाधित कर रहा है,

एक उपयोगकर्ता एक प्रोग्राम का उपयोग कर सकता है जो कुछ कार्यों को पार्लेलाइज़ करता है। यदि डेटाबेस में मल्टी-थ्रेडिंग / मल्टी-प्रोसेसिंग क्षमताएं भी हैं, तो यह कार्यक्रम संभवतः सबसे अधिक लाभकारी होगा।
जोनलो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.