उत्तर खोजने (क्वेरी के आकार में) की सैद्धांतिक घातीय जटिलता को देखते हुए, रिलेशनल डेटाबेस बिल्कुल क्यों काम करते हैं?

Question

ऐसा नहीं है कि एक प्रश्न का उत्तर नहीं मिलता के लिए जाना जाता प्रतीत हो रहा है एक संबंधपरक डेटाबेस से अधिक विकास एक समय की जरूरत है, | D | | क्यू | , और एक प्रतिपादक से छुटकारा नहीं मिल सकता है | क्यू | ।$Q$$D$$|D|^{|Q|}$$|Q|$

जैसा कि बहुत बड़ा हो सकता है, हमें आश्चर्य है कि डेटाबेस व्यवहार में क्यों काम करते हैं।$D$

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

घातांक पर नोट्स `हटाने योग्य नहीं’$|Q|$

यह दिखाने के लिए कि प्रतिपादक हटाने योग्य नहीं है, एक क्वेरी का उपयोग करके पूछ सकता है कि क्या डेटाबेस द्वारा दिए गए ग्राफ में आकार n का कोई क्‍लिक मौजूद है । यह जांचने के लिए कि क्या ग्राफ में n -clique है, NP-पूर्ण समस्या है। इसके अलावा, यह पैरामीटर n के साथ तय-पैरामीटर ट्रैक्टेबल नहीं है । विवरण में पाया जा सकता है, जैसे, लिबकिन, एल।: तत्वों के परिमित मॉडल सिद्धांत। स्प्रिंगर (2004) या पापादिमित्रिउ, सीएच, यानककिस, एम .: डेटाबेस प्रश्नों की जटिलता पर। जे। कम्प्यूट। Syst। विज्ञान। 58 (3), 407–427 (1999)$|Q|$$n$$n$$n$

Comments

साधारण प्रश्न (जैसे SELECT * FROM users WHERE username="abc" AND passwrod="xyz") सरल खोजें हैं, जिन्हें चलाने के लिए O (| D |) लेते हैं। यदि प्रासंगिक डेटाबेस फ़ील्ड पर कोई इंडेक्स है, तो वह O (लॉग | D |) ले जाएगा। मैं डेटाबेस में नहीं हूं, लेकिन मुझे नहीं लगता कि अधिक जटिल प्रश्नों का घातीय समय लगेगा।

— एमएस डौस्टी

@ मिज़: आपके उदाहरण में, जटिलता , जो अभी भी बहुपद है। ऐसा लगता है कि, यदि क्वेरी में k जोड़ हैं, तो जटिलता O ( | D | k + 1 ) है । यह फिक्स्ड k के लिए एक बहुपद है, लेकिन मुझे लगता है कि बड़े k के लिए, क्वेरी को चलाना अभ्यास में बहुत धीमा होगा। इसलिए हर कीमत पर बहुत से लोगों से बचना चाहिए। $O(|D|^2)$$O(|D|^{k+1})$

— एम एस डौस्टी

सबसे खराब स्थिति में क्वेरी की लंबाई में समय जटिलता घातीय है । यह विरोधाभास नहीं है कि कुछ लंबे प्रश्न तेजी से हैं। डेटाबेस चिकित्सकों को पता है कि विशिष्ट डेटाबेस इंजन में कौन से प्रश्न तेजी से चलते हैं, और वे वैसे भी क्वेरी की लंबाई के मामले में सबसे खराब स्थिति पर भरोसा नहीं करते हैं।

— Tsuyoshi Ito

@ केव: "इमवर्मन की वर्णनात्मक जटिलता पुस्तक के अंतिम अध्याय में एक छोटी सी चर्चा थी": बहुत अच्छा सुझाव। नाइटपैकिंग: इसकी चर्चा प्रचलित अध्याय में की गई है। @ मिज़: आपको एसक्यूएल का पेपर एक्सप्रेसिव पावर उपयोगी हो सकता है।

— बजे एमएस डौस्ती

@imz: "क्या इस ग्राफ में एक एन-क्लिक है" यह सामान्य प्रथा नहीं है। अधिकांश प्रश्न अधिक हैं जैसे @Sadeq बताते हैं, और एक मजबूत वृक्ष जैसी संरचना है। इसके अलावा, वास्तव में बड़े डेटाबेस के लिए भी एक पूरी तरह से रैखिक क्वेरी बहुत महंगा है, और एक डेटाबेस के एक स्केच के साथ काम करना है।

— आंद्र सलाम

Answer 1

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

ऐसा लगता है कि व्यवहार में सामना किए गए कई प्रश्न दोनों संयुग्म हैं और छोटी चौड़ाई है। तो बहुपद क्रम इस मामले में कम डिग्री है।

डैनियल मार्क्स ने हाल ही में सबमॉड्यूलर चौड़ाई पर STOC 2010 में एक पेपर प्रस्तुत किया था, जिसके पूर्ण संस्करण में चौड़ाई की विभिन्न धारणाओं का एक अच्छा सारांश और CSP सूत्रीकरण डेटाबेस औपचारिकता (इस सम्मेलन संस्करण का अभाव है) से संबंधित है।

• डैनियल मार्क्स, बाधात्मक संतुष्टि और संयोजी प्रश्नों के लिए ट्रैक्टेबल हाइपरग्राफ गुण , 2010. arxiv: 09.08.0801

यह एक पूर्ण उत्तर नहीं है, क्योंकि यह डेटाबेस प्रश्नों की "विशिष्ट" जटिलता से नहीं निपटता है, लेकिन सबसे खराब स्थिति विश्लेषण के साथ भी आसान प्रश्न हैं।

Answer 2

एक प्रश्न का उपयोग कर सकते हैं Q_n यह जांचने के लिए कि क्या एक ग्राफ, एक डेटाबेस के रूप में दर्शाया गया है, जिसमें एन तत्वों के साथ एक क्‍लिक है। यह जाँचने के लिए कि क्या किसी ग्राफ़ में कोई क्लिक है, एक एनपी-पूर्ण समस्या है। इसके अलावा, यह पैरामीटर n (पैरामीटर जिसका मतलब D ^ n) है, के साथ तय पैरामीटर नहीं है।

Comments

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

— इम्ज़-इवान ज़खरीशेव

@ मिज़: उन्होंने इसे एक उत्तर के रूप में रखा क्योंकि उन्हें टिप्पणी करने का कोई विशेषाधिकार नहीं है। कम से कम 50 प्रतिनिधि की आवश्यकता है। हर जगह टिप्पणी करने में सक्षम हो।

— टोमेक टारसिनेस्की

@Tomek, @imz, ठीक है, इस समय मेटा पर चर्चा की जा रही है यदि हमें उत्तर का उपयोग करते हुए टिप्पणी करने की अनुमति देनी चाहिए या नहीं।

— केवह

Answer 3

इस सवाल का जवाब देने का एक और तरीका है, "वे नहीं!"

यदि आप किसी विशिष्ट DBMS कार्यान्वयन को एक क्वेरी देते हैं जिसमें बहुत बड़ी संख्या में जोड़ होते हैं, तो यह योजना / अनुकूलन चरण (अकेले मूल्यांकन करने दें) से भी आगे नहीं बढ़ेगा, भले ही वह प्रश्न चक्रीय हो या अन्यथा बहुत सरल संरचना हो András ऊपर के लिए दृष्टिकोण।

लेकिन, "विशिष्ट" DBMS कार्यभार के लिए, इस तरह के प्रश्न उत्पन्न नहीं होते हैं।

Comments

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

— तेगिरी नेनाशी

Answer 4

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

Answer 5

कई-से-कई रिश्तों पर जोड़ केवल द्विघात होते हैं। ये अपेक्षाकृत दुर्लभ हैं: व्यवहार में, अधिकांश रिश्ते और जोड़ 1-से-कई हैं, इसलिए वे अनुक्रमित / कुंजियों को परिभाषित करने में रैखिक समय लेंगे। कई कई-से-अनेक मिलती वाली क्वेरी हैं एक गंभीर समस्या।