PostgreSQL
 sql >> डेटाबेस >  >> RDS >> PostgreSQL

पोस्टग्रेज़ मैटेरियलाइज़्ड पाथ - ltree का उपयोग करने के क्या लाभ हैं?

TL;DR पुन:प्रयोज्य लेबल, जटिल खोज पैटर्न, और कई वंशज नोड्स (या एक एकल नोड जिसका पथ अभी तक पुनर्प्राप्त नहीं किया गया है) के विरुद्ध पूर्वज खोजों को भौतिक पथ अनुक्रमणिका का उपयोग करके पूरा नहीं किया जा सकता है।

खूनी विवरण में रुचि रखने वालों के लिए...

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

एल-पेड़ आपको खोजों के प्रकारों में लचीलेपन में एक स्पष्ट अंतर होगा। इन उदाहरणों पर विचार करें (ltree . से) आपके प्रश्न से जुड़े दस्तावेज़):

foo         Match the exact label path foo
*.foo.*     Match any label path containing the label foo
*.foo       Match any label path whose last label is foo

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

और फिर वास्तव में इस तरह के जटिल प्रश्न हैं (दस्तावेज़ों से भी):

Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain

एक भौतिक पथ सूचकांक यहां बेकार होगा, और इसे संभालने के लिए एक पूर्ण तालिका स्कैन की आवश्यकता होगी। यदि आप इसे SARGable क्वेरी के रूप में निष्पादित करना चाहते हैं तो l-tree एकमात्र विकल्प है।

लेकिन मानक पदानुक्रमित संचालन के लिए, इनमें से कोई भी खोजना:

  • माता-पिता
  • बच्चे
  • वंशज
  • रूट नोड्स
  • लीफ नोड्स

भौतिक पथ एल-पेड़ के समान ही काम करेगा। ऊपर लिंक किए गए लेख , एक सामान्य पूर्वज के सभी वंशजों की खोज करना b-पेड़ का उपयोग करके बहुत संभव है। क्वेरी प्रारूप WHERE path LIKE 'A.%' SARGable है बशर्ते आपकी अनुक्रमणिका ठीक से तैयार की गई हो (मुझे varchar_pattern_ops के साथ अपने पथ अनुक्रमणिका को स्पष्ट रूप से टैग करना था इसे काम करने के लिए)।

इस सूची में जो कमी है वह यह है कि सभी पूर्वजों को ढूंढा जा रहा है एक वंशज के लिए। क्वेरी प्रारूप WHERE 'A.B.C.D' LIKE path || '.%' दुर्भाग्य से सूचकांक का उपयोग नहीं करने जा रहा है। कुछ पुस्तकालयों द्वारा कार्यान्वित एक समाधान पथ से पूर्वजों के नोड्स को पार्स करना है, और उन्हें सीधे क्वेरी करना है:WHERE id IN ('A', 'B', 'C') . हालांकि, यह केवल तभी काम करेगा जब आप किसी विशिष्ट नोड के पूर्वजों को लक्षित कर रहे हों जिसका पथ आप पहले ही पुनर्प्राप्त कर चुके हैं। एल-पेड़ इस पर जीतने जा रहा है।




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. क्या एडीओ ओडीबीसी ड्राइवरों या केवल ओएलई डीबी प्रदाताओं के साथ काम करता है?

  2. Postgresql:सही या क्लॉज की संख्या के आधार पर रैंक की गणना करें

  3. ElementCollection के साथ JPA मैपिंग मल्टी-पंक्तियाँ

  4. IN के साथ पोस्टग्रेज क्वेरी बहुत धीमी है

  5. प्रत्येक पंक्ति को दो तिथियों के बीच यादृच्छिक डेटाटाइम के साथ अपडेट करें