ठूलो table मा सुस्त aggregate queries कसरी सुधार्ने?

Question

IT Interview Practice · Accepted Answer

ढिलो एग्रिगेट क्वेरी सुधार्न पहिले **नतिजाको अर्थ के हो र कुन काममा समय लागिरहेको छ** पत्ता लगाउनुहोस्। एग्रिगेटले पङ्क्तिहरूलाई सारांशमा जोड्छ, जस्तै व्यापारीअनुसार आम्दानी। यसको लागत कति डेटा पढ्न र जोड्नुपर्छ भन्नेमा निर्भर हुन्छ।

गत महिनाको आम्दानी देखाउने ड्यासबोर्ड सोच्नुहोस्। यही उदाहरणबाट क्वेरी सुधार्ने, पहिल्यै तयार सारांश राख्ने वा रिपोर्टिङ अर्को प्रणालीमा सार्ने निर्णय गर्न सकिन्छ।

## 1. छिटो बनाउनुअघि उत्तर सही छ भन्ने निश्चित गर्नुहोस्

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

सामान्य गल्ती भनेको एउटा भुक्तानीलाई अर्डरका धेरै वस्तुसँग जोडेर भुक्तानी रकम जोड्नु हो:

```text
[Payment: 100] -> [Join with 3 items] -> [100, 100, 100]
                                               |
                                          [SUM = 300]
```

यी सङ्ख्या उदाहरण हुन्। क्वेरीले भुक्तानी दोहोर्‍याएको छ, त्यसैले यसलाई छिटो बनाउँदा गलत कुल मात्र छिटो आउँछ। कार्यसम्पादन मूल्याङ्कन गर्नुअघि सही व्यावसायिक तहमा एग्रिगेट गर्नुहोस् वा जोइन बदल्नुहोस्।

## 2. कार्यान्वयनको महँगो भाग खोज्नुहोस्

एक्जिक्युसन प्लानले नतिजा निकाल्न प्रयोग भएका काम देखाउँछ। तालिकालाई अर्को इन्डेक्स मात्र चाहिएको ठान्नुको सट्टा महँगा चरण र तिनको इनपुट आकार जाँच्नुहोस्।

| अवलोकन | अनुसन्धान गर्ने प्रश्न |
| --- | --- |
| धेरै असम्बन्धित पङ्क्ति पढिन्छन् | फिल्टर वा पार्टिसन प्रुनिङले तिनलाई हटाउन सक्छ? |
| वास्तविक पङ्क्ति सङ्ख्या अनुमानभन्दा धेरै फरक छ | तथ्याङ्कले यो डेटाको प्रतिनिधित्व गर्छ? |
| जोइनले एउटै काम धेरै पटक गर्छ | इनपुट धेरै ठूलो छ वा पहुँच विधि अनुपयुक्त छ? |
| समूह बनाउँदा वा क्रम मिलाउँदा अस्थायी डेटा डिस्कमा लेखिन्छ | मेमोरी सीमा बदल्नुअघि इनपुट घटाउन सकिन्छ? |

PostgreSQL मा EXPLAIN (ANALYZE, BUFFERS) ले क्वेरी चलाएर वास्तविक कार्यान्वयनको विवरण दिन्छ। महँगो अनुसन्धान नियन्त्रित वातावरणमा वा उत्पादन प्रणालीका लागि सोचेर छुट्याइएको स्रोत सीमाभित्र गर्नुहोस्। [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html)।

## 3. हालकै डेटाबेसमा काम घटाउनुहोस्

ड्यासबोर्डका लागि चाहिएको महिना र स्तम्भ मात्र छान्नुहोस्। प्लानले असम्बन्धित पार्टिसन साँच्चै छोड्छ कि छोड्दैन र जोइनले सारांशलाई नचाहिने डेटा ल्याउँछ कि ल्याउँदैन जाँच्नुहोस्।

पर्याप्त पढाइ बचाउँदा इन्डेक्स उपयोगी हुन्छ। रिपोर्टलाई धेरैजसो पङ्क्ति चाहिन्छ भने क्रमिक स्क्यान उपयुक्त हुन सक्छ। इन्डेक्स देखियो कि देखिएन मात्र होइन, नतिजाको प्लान र मापन गरिएको लागत हेर्नुहोस्।

क्रम मिलाउने काम डिस्कमा पोखिन्छ भने इनपुट घटाएर समाधान हुन सक्छ। प्रत्येक क्वेरीको मेमोरी बढाउँदा धेरै रिपोर्ट सँगै चल्दा RAM सकिन सक्छ। प्रतिनिधिमूलक समवर्ती भारमा परीक्षण गर्नुहोस्।

## 4. परिणाम पहिल्यै तयार गर्ने कि नगर्ने तय गर्नुहोस्

धेरै प्रयोगकर्ताले उही कुल माग्छन् र केही ढिलाइ स्वीकार्य छ भने मूल अर्डर बारम्बार स्क्यान गर्दा काम खेर जान्छ। सारांश तालिकाले दिन, व्यापारी र मुद्राअनुसार कुल राख्न सक्छ; ड्यासबोर्डले यी साना परिणाम जोड्छ।

```text
[Orders] -> [Scheduled / incremental calculation]
                              |
                       [Daily summaries] -> [Dashboard]
```

हरेक अनुरोधमा गर्नुको सट्टा साझा गणना एक पटक गर्दा लाभ हुन्छ। मटेरियलाइज्ड भ्यु क्वेरीको परिणाम राख्ने अर्को तरिका हो, जसको आफ्नै अद्यावधिक व्यवहार हुन्छ।

यो बचतसँग जिम्मेवारी पनि आउँछन्:

- नतिजा कति पटक अद्यावधिक हुन्छ तय गर्नुहोस् र प्रयोगकर्तालाई यसको ताजापन देखाउनुहोस्।
- फिर्ता रकम, ढिला अर्डर र सुधार दोहोरो गणना नगरी लागू गर्नुहोस्।
- दोहोरिएको प्रशोधन सुरक्षित बनाउनुहोस् र सारांश फेरि निर्माण गर्ने तरिका राख्नुहोस्।
- औसत जोड्दा योगफल र सङ्ख्या राख्नुहोस्; औसतहरूको औसत गलत हुन सक्छ।

यो ड्यासबोर्डमा तयार सारांश तब मात्र उपयुक्त हुन्छ जब यसको ताजापन र सुधारका नियमले पहिलो चरणको आवश्यकता पूरा गर्छन्।

## 5. मापनले उचित देखाएपछि रिपोर्टिङ छुट्याउनुहोस्

फराकिला विश्लेषणात्मक स्क्यान अझै महँगा छन् र खरिदमा असर गर्छन् भने त्यही कामका लागि उपयुक्त विश्लेषणात्मक भण्डार मूल्याङ्कन गर्नुहोस्। समक्रमणको ढिलाइ, पुनर्प्राप्ति र अर्को प्रणाली चलाउने लागत समावेश गर्नुहोस्।

रिड रेप्लिकाले रिपोर्टिङको भार छुट्याउन सक्छ, तर उही क्वेरी त्यहाँ पनि महँगो हुन सक्छ। छुट्याउँदा लागत तिर्ने ठाउँ बदलिन्छ; लागत नै हट्छ भन्ने हुँदैन।

प्रत्येक परिवर्तनलाई भरपर्दो नतिजा र उही परीक्षण भारसँग तुलना गर्नुहोस्। प्रतिक्रिया समय, स्रोत, ताजापन र लेखाइमा प्रभाव जाँच्नुहोस्।

**सम्झनुहोस्:** सही नतिजा → मापन गरिएको अवरोध → अनावश्यक काम घटाउने → उपयुक्त भए तयार सारांश → अझै आवश्यक भए छुट्टै विश्लेषण प्रणाली।

अवलोकन	अनुसन्धान गर्ने प्रश्न
धेरै असम्बन्धित पङ्क्ति पढिन्छन्	फिल्टर वा पार्टिसन प्रुनिङले तिनलाई हटाउन सक्छ?
वास्तविक पङ्क्ति सङ्ख्या अनुमानभन्दा धेरै फरक छ	तथ्याङ्कले यो डेटाको प्रतिनिधित्व गर्छ?
जोइनले एउटै काम धेरै पटक गर्छ	इनपुट धेरै ठूलो छ वा पहुँच विधि अनुपयुक्त छ?
समूह बनाउँदा वा क्रम मिलाउँदा अस्थायी डेटा डिस्कमा लेखिन्छ	मेमोरी सीमा बदल्नुअघि इनपुट घटाउन सकिन्छ?

1. छिटो बनाउनुअघि उत्तर सही छ भन्ने निश्चित गर्नुहोस्

2. कार्यान्वयनको महँगो भाग खोज्नुहोस्

3. हालकै डेटाबेसमा काम घटाउनुहोस्

4. परिणाम पहिल्यै तयार गर्ने कि नगर्ने तय गर्नुहोस्

5. मापनले उचित देखाएपछि रिपोर्टिङ छुट्याउनुहोस्

सम्बन्धित प्रश्नहरू