મોટા ટેબલ પર ધીમી aggregate ક્વેરીને કેવી રીતે સુધારશો?

Question

IT Interview Practice · Accepted Answer

ધીમા aggregateને ઝડપી કરતાં પહેલાં **પરિણામનો અર્થ શું છે અને કઈ ક્રિયામાં સમય જાય છે** તે શોધો. Aggregate રેકોર્ડ ભેગા કરીને સારાંશ બનાવે છે, જેમ કે વેપારી પ્રમાણે આવક. તેનો ખર્ચ કેટલો ડેટા વાંચવો અને ભેગો કરવો પડે તેના પર આધારિત છે.

છેલ્લા મહિનાની આવક બતાવતું ડૅશબોર્ડ ધારો. આ ઉદાહરણથી નક્કી કરો કે ક્વેરી સુધારવી, તૈયાર સારાંશ રાખવો કે રિપોર્ટિંગ બીજી જગ્યાએ ખસેડવું.

## 1. ઝડપી કરતાં પહેલાં જવાબ સાચો છે તે જુઓ

આવક એટલે ચૂકવાયેલા કે બનાવેલા ઓર્ડર, રિફંડ કેવી રીતે ગણાશે અને કયા ચલણ સામેલ છે તે સ્પષ્ટ કરો. ડૅશબોર્ડ કેટલું તાજું હોવું જોઈએ તે પણ પૂછો. આ નિર્ણયો ક્વેરી અને શક્ય સુધારા બંને બદલે છે.

સામાન્ય ભૂલ એ છે કે પેમેન્ટને ઓર્ડરની ઘણી વસ્તુઓ સાથે જોડીને પછી પેમેન્ટની રકમનો સરવાળો કરવો:

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

આ આંકડા ઉદાહરણ છે. જોડાણે પેમેન્ટને ઘણી વાર ગણ્યું છે, એટલે ઝડપ વધારવાથી ખોટો કુલ વહેલો મળશે. પ્રદર્શન તપાસતાં પહેલાં યોગ્ય વ્યવસાયિક સ્તરે aggregate કરો અથવા join બદલો.

## 2. અમલનો ખર્ચાળ ભાગ શોધો

Execution plan પરિણામ મેળવવા વપરાતી ક્રિયાઓ બતાવે છે. ટેબલને બીજો index જોઈએ જ એવું માનવાને બદલે ખર્ચાળ પગલાં અને તેમનાં ઇનપુટનું કદ જુઓ.

| નિરીક્ષણ | તપાસવાનો પ્રશ્ન |
| --- | --- |
| ઘણા બિનજરૂરી રેકોર્ડ વાંચાય છે | ફિલ્ટર અથવા partition pruningથી તેમને ટાળી શકાય? |
| વાસ્તવિક સંખ્યા અંદાજથી ઘણી જુદી છે | સ્ટેટિસ્ટિક્સ આ ડેટાનું યોગ્ય પ્રતિનિધિત્વ કરે છે? |
| Join એક જ કામ વારંવાર કરે છે | ઇનપુટ મોટું છે કે ઍક્સેસની રીત અયોગ્ય છે? |
| ગ્રૂપિંગ કે સૉર્ટિંગ ડિસ્ક પર અસ્થાયી ડેટા લખે છે | મેમરી મર્યાદા બદલતાં પહેલાં ઇનપુટ ઘટાડી શકાય? |

PostgreSQLમાં EXPLAIN (ANALYZE, BUFFERS) ક્વેરી ખરેખર ચલાવે છે અને રનટાઇમ માહિતી આપે છે. ખર્ચાળ તપાસ નિયંત્રિત પર્યાવરણમાં અથવા ઉત્પાદન માટે સ્પષ્ટ નક્કી કરેલા સંસાધન બજેટ સાથે કરો. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. હાલના ડેટાબેઝમાં કામ ઘટાડો

ડૅશબોર્ડ માટે જરૂરી મહિનો અને કૉલમ જ પસંદ કરો. પ્લાન અસંબંધિત પાર્ટિશન ખરેખર ટાળે છે કે નહીં અને join સારાંશને ન જોઈએ એવો ડેટા લાવે છે કે નહીં તે જુઓ.

Index પૂરતું વાંચન બચાવે ત્યારે ઉપયોગી છે. રિપોર્ટને મોટાભાગના રેકોર્ડ જોઈએ તો sequential scan યોગ્ય હોઈ શકે. માત્ર index વપરાયો છે કે નહીં એ નહીં, પણ બનેલો પ્લાન અને માપેલો ખર્ચ જુઓ.

સૉર્ટિંગ ડિસ્ક પર જાય તો ઇનપુટ ઘટાડવાથી સમસ્યા ઉકલી શકે. દરેક ક્વેરી માટે મેમરી વધારવાથી ઘણા રિપોર્ટ સાથે ચાલે ત્યારે RAM ખૂટી શકે. વાસ્તવિક જેવા સમવર્તી ભાર હેઠળ તપાસો.

## 4. પરિણામ અગાઉથી તૈયાર કરવું કે નહીં તે નક્કી કરો

ઘણા વપરાશકર્તા સમાન કુલ માંગે અને થોડો વિલંબ સ્વીકાર્ય હોય તો કાચા ઓર્ડર વારંવાર સ્કૅન કરવાથી કામ બગડે છે. સારાંશ ટેબલ દિવસ, વેપારી અને ચલણ પ્રમાણે કુલ રાખી શકે; ડૅશબોર્ડ આ નાના પરિણામો જોડે છે.

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

ફાયદો સમાન ગણતરી દરેક વિનંતી વખતે નહીં, એક વાર કરવાથી મળે છે. Materialized view ક્વેરીનું પરિણામ સાચવવાની બીજી રીત છે, જેની પોતાની રિફ્રેશ પદ્ધતિ હોય છે.

આ બચત સાથે જવાબદારીઓ આવે છે:

- પરિણામ કેટલી વાર તાજું થશે તે નક્કી કરો અને સંબંધિત તાજગી વપરાશકર્તાને બતાવો.
- રિફંડ, મોડા ઓર્ડર અને સુધારા બે વાર ગણ્યા વિના લાગુ કરો.
- પુનઃપ્રક્રિયા સુરક્ષિત બનાવો અને સારાંશ ફરી બનાવવાની રીત રાખો.
- સરેરાશ ભેગી કરવા sum અને count રાખો; સરેરાશોની સરેરાશ ખોટી પડી શકે.

આ ડૅશબોર્ડ માટે તૈયાર સારાંશ ત્યારે જ યોગ્ય છે જ્યારે તેની તાજગી અને સુધારાના નિયમો પ્રથમ પગલાની જરૂરિયાત પૂરી કરે.

## 5. માપણ યોગ્ય ઠેરવે ત્યારે રિપોર્ટિંગ અલગ કરો

મોટા વિશ્લેષણાત્મક સ્કૅન ખર્ચાળ રહે અને ખરીદીમાં અડચણ કરે તો એ કામને અનુકૂળ analytical store તપાસો. સિંગ્કનો વિલંબ, પુનઃપ્રાપ્તિ અને બીજી સિસ્ટમ ચલાવવાનો ખર્ચ પણ ગણો.

Read replica રિપોર્ટિંગનો ભાર અલગ કરી શકે, પરંતુ એ જ ક્વેરી ત્યાં પણ ખર્ચાળ હોઈ શકે. અલગ કરવાથી ખર્ચ ક્યાં ચૂકવાય છે તે બદલાય છે; ખર્ચ જરૂરી નથી કે દૂર થાય.

દરેક ફેરફારને વિશ્વસનીય પરિણામ અને સમાન ટેસ્ટ લોડ સામે સરખાવો. પ્રતિસાદ સમય, સંસાધનો, તાજગી અને લખાણ પર અસર તપાસો.

**યાદ રાખો:** સાચું પરિણામ → માપેલો અવરોધ → ઓછું બિનજરૂરી કામ → યોગ્ય હોય તો તૈયાર સારાંશ → હજી જરૂરી હોય તો અલગ વિશ્લેષણ.

નિરીક્ષણ	તપાસવાનો પ્રશ્ન
ઘણા બિનજરૂરી રેકોર્ડ વાંચાય છે	ફિલ્ટર અથવા partition pruningથી તેમને ટાળી શકાય?
વાસ્તવિક સંખ્યા અંદાજથી ઘણી જુદી છે	સ્ટેટિસ્ટિક્સ આ ડેટાનું યોગ્ય પ્રતિનિધિત્વ કરે છે?
Join એક જ કામ વારંવાર કરે છે	ઇનપુટ મોટું છે કે ઍક્સેસની રીત અયોગ્ય છે?
ગ્રૂપિંગ કે સૉર્ટિંગ ડિસ્ક પર અસ્થાયી ડેટા લખે છે	મેમરી મર્યાદા બદલતાં પહેલાં ઇનપુટ ઘટાડી શકાય?

1. ઝડપી કરતાં પહેલાં જવાબ સાચો છે તે જુઓ

2. અમલનો ખર્ચાળ ભાગ શોધો

3. હાલના ડેટાબેઝમાં કામ ઘટાડો

4. પરિણામ અગાઉથી તૈયાર કરવું કે નહીં તે નક્કી કરો

5. માપણ યોગ્ય ઠેરવે ત્યારે રિપોર્ટિંગ અલગ કરો

સંબંધિત પ્રશ્નો