بڑے ٹیبل پر سست مجموعی کوئریز کو کیسے بہتر کریں؟

Question

IT Interview Practice · Accepted Answer

سست aggregate بہتر کرنے سے پہلے معلوم کریں کہ **نتیجے کا مطلب کیا ہے اور کون سی کارروائی وقت لے رہی ہے**۔ Aggregate قطاروں کو خلاصے میں جوڑتا ہے، مثلاً تاجر کے لحاظ سے آمدنی۔ لاگت پڑھے اور جوڑے جانے والے ڈیٹا پر منحصر ہے۔

گزشتہ ماہ کی آمدنی دکھانے والا dashboard سوچیں۔ اسی مثال سے طے کریں کہ query بہتر کرنی ہے، تیار خلاصہ رکھنا ہے یا reporting کہیں اور منتقل کرنی ہے۔

## 1. تیز کرنے سے پہلے جواب درست کریں

واضح کریں کہ آمدنی ادا شدہ آرڈر ہیں یا بنائے گئے آرڈر، refunds کیسے شمار ہوتے ہیں اور کون سی کرنسیاں شامل ہیں۔ Dashboard کی مطلوبہ تازگی بھی پوچھیں۔ یہ فیصلے query اور ممکنہ بہتری دونوں بدلتے ہیں۔

عام غلطی ایک payment کو آرڈر کی کئی items سے join کرکے payment کی رقم جمع کرنا ہے:

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

اعداد مثال ہیں۔ Query نے payment کو کئی بار شمار کیا، لہٰذا تیز کرنے سے غلط مجموعہ جلد ملے گا۔ کارکردگی جانچنے سے پہلے مطلوبہ کاروباری سطح پر aggregate کریں یا join بدلیں۔

## 2. اجرا کا مہنگا حصہ تلاش کریں

Execution plan نتیجہ نکالنے والی کارروائیاں دکھاتا ہے۔ صرف ایک اور index کی ضرورت فرض کرنے کے بجائے مہنگے مراحل اور ان کا input حجم دیکھیں۔

| مشاہدہ | تحقیق کا سوال |
| --- | --- |
| بہت سی غیر متعلق قطاریں پڑھی جاتی ہیں | کیا filters یا partition pruning انہیں نکال سکتے ہیں؟ |
| اصل تعداد اندازے سے بہت مختلف ہے | کیا statistics اس ڈیٹا کی نمائندگی کرتی ہیں؟ |
| Join کام بار بار کرتا ہے | کیا input بہت بڑا یا رسائی کا راستہ نامناسب ہے؟ |
| Grouping یا sorting عارضی ڈیٹا disk پر لکھتی ہے | memory حد بدلنے سے پہلے input کم ہو سکتا ہے؟ |

PostgreSQL میں EXPLAIN (ANALYZE, BUFFERS) query چلاتا اور حقیقی اجرا کی معلومات دیتا ہے۔ مہنگی تحقیق کنٹرول شدہ ماحول یا سوچے سمجھے production وسائل کے بجٹ میں کریں۔ [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html)۔

## 3. موجودہ database میں کام کم کریں

Dashboard کے لیے مطلوبہ ماہ اور columns چنیں۔ دیکھیں کہ plan واقعی غیر متعلق partitions چھوڑتا ہے اور joins خلاصے کے لیے غیر ضروری ڈیٹا تو نہیں لاتے۔

Index تب مفید ہے جب کافی پڑھائی بچائے۔ اگر رپورٹ کو زیادہ تر قطاریں چاہییں تو sequential scan درست ہو سکتا ہے۔ نتیجے کے plan اور ناپی لاگت کو پرکھیں، صرف index کے استعمال کو نہیں۔

اگر sorting disk تک جاتی ہے تو input کم کرنا حل ہو سکتا ہے۔ ہر query کی memory بڑھانے سے کئی رپورٹس ساتھ چلنے پر RAM ختم ہو سکتی ہے۔ نمائندہ concurrent load پر آزمائیں۔

## 4. طے کریں کہ نتیجہ پہلے تیار کیا جائے یا نہیں

اگر بہت سے صارف ایک ہی مجموعہ مانگتے ہیں اور کچھ تاخیر قبول ہے تو خام آرڈر بار بار پڑھنا ضائع کام ہے۔ Summary table دن، تاجر اور کرنسی کے لحاظ سے totals رکھ سکتی ہے؛ dashboard چھوٹے نتائج جوڑتا ہے۔

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

فائدہ مشترک حساب ہر درخواست کے بجائے ایک بار کرنے سے آتا ہے۔ Materialized view بھی query نتیجہ محفوظ کرتی ہے، اپنی refresh ترتیب کے ساتھ۔

اس بچت کے ساتھ ذمہ داریاں آتی ہیں:

- Refresh کی شرح طے کریں اور صارف کو ڈیٹا کی تازگی دکھائیں۔
- Refunds، دیر سے آرڈر اور اصلاحات دوہری گنتی کے بغیر لگائیں۔
- دوبارہ processing محفوظ بنائیں اور summaries دوبارہ بنانے کا راستہ رکھیں۔
- اوسط ملاتے وقت sum اور count محفوظ کریں؛ اوسطوں کی اوسط غلط ہو سکتی ہے۔

اس dashboard میں تیار summaries تبھی مناسب ہیں جب تازگی اور اصلاحات پہلے مرحلے کی شرط پوری کریں۔

## 5. پیمائش جواز دے تو reporting الگ کریں

اگر وسیع analytical scans مہنگے رہتے اور خریداری متاثر کرتے ہیں تو موزوں analytical store پر غور کریں۔ Synchronization تاخیر، recovery اور دوسرے نظام کی عملی لاگت شامل کریں۔

Read replica رپورٹ کا load الگ کر سکتی ہے، مگر وہی query وہاں بھی مہنگی ہو سکتی ہے۔ علیحدگی لاگت کی جگہ بدلتی ہے، لازماً ختم نہیں کرتی۔

ہر تبدیلی کو معتبر نتیجے اور یکساں test load سے ملائیں۔ Response time، وسائل، تازگی اور writes پر اثر دیکھیں۔

**یاد رکھیں:** درست نتیجہ → ناپی رکاوٹ → کم غیر ضروری کام → مناسب ہو تو تیار summaries → ضرورت باقی ہو تو الگ analytics۔

مشاہدہ	تحقیق کا سوال
بہت سی غیر متعلق قطاریں پڑھی جاتی ہیں	کیا filters یا partition pruning انہیں نکال سکتے ہیں؟
اصل تعداد اندازے سے بہت مختلف ہے	کیا statistics اس ڈیٹا کی نمائندگی کرتی ہیں؟
Join کام بار بار کرتا ہے	کیا input بہت بڑا یا رسائی کا راستہ نامناسب ہے؟
Grouping یا sorting عارضی ڈیٹا disk پر لکھتی ہے	memory حد بدلنے سے پہلے input کم ہو سکتا ہے؟

1. تیز کرنے سے پہلے جواب درست کریں

2. اجرا کا مہنگا حصہ تلاش کریں

3. موجودہ database میں کام کم کریں

4. طے کریں کہ نتیجہ پہلے تیار کیا جائے یا نہیں

5. پیمائش جواز دے تو reporting الگ کریں

متعلقہ سوالات