કેવી રીતે એક અનઇન્ડેક્સડ કોલમે અમારા ડેટાબેઝને ઠપ્પ કરી દીધો
એક ખૂટતા ઇન્ડેક્સને કારણે 8 ms ની API 8 સેકન્ડના кошાળમાં ફેરવાઈ ગઈ.
અમે એક મોટા રિલીઝ પહેલા લોડ ટેસ્ટ (load test) કર્યો. લોકલ ડેવલપમેન્ટમાં 100 રો (rows) સારી રીતે સંભાળાઈ ગયા હતા. સ્ટેજિંગમાં અમે 1.5 મિલિયન રો પર 500 યુઝર્સનું સિમ્યુલેશન કર્યું.
બધું જ ખોરવાઈ ગયું.
- API રિસ્પોન્સ ટાઈમ 45 ms થી વધીને 8,000 ms થઈ ગયો.
- ડેટાબેઝ CPU 100 % પર પહોંચી ગયો.
- કનેક્શન પૂલ્સ (Connection pools) ખાલી થઈ ગયા.
- રિક્વેસ્ટ ટાઈમ આઉટ થઈ ગઈ.
આનું કારણ એક સાદી ક્વેરી હતી જે user_id અને status દ્વારા ઓર્ડર હિસ્ટ્રી મેળવતી હતી.
PostgreSQL પર EXPLAIN ANALYZE ચલાવવાથી 'Sequential Scan' જોવા મળ્યું. user_id પર ઇન્ડેક્સ ન હોવાને કારણે, એન્જિન દરેક રિક્વેસ્ટ માટે તમામ 1.5 મિલિયન રો વાંચતું હતું.
100 કન્કરન્ટ (concurrent) રિક્વેસ્ટ વખતે ડેટાબેઝે એકસાથે 150 મિલિયન રો સ્કેન કર્યા.
આનો ઉકેલ લાવવામાં પાંચ મિનિટ લાગી. અમે ટેબલ ઓનલાઇન રહે તે માટે CREATE INDEX CONCURRENTLY નો ઉપયોગ કરીને (user_id, status, created_at DESC) પર એક કોમ્પોઝિટ ઇન્ડેક્સ (composite index) બનાવ્યો.
પરિણામો:
- ક્વેરી ટાઈમ 8,150 ms થી ઘટીને 0.14 ms થઈ ગયો.
- API લેટન્સી (latency) 8 સેકન્ડથી ઘટીને 12 ms થઈ ગઈ.
- CPU વપરાશ 100 % થી ઘટીને 8 % થી નીચે આવી ગયો.
શીખવા મળેલા પાઠ:
- લોકલ ટેસ્ટ ભ્રમિત કરી શકે છે; 100 રો એ મિલિયન રોનું પ્રતિનિધિત્વ કરી શકતા નથી.
- ફોરેન કી (foreign keys) ને ઇન્ડેક્સ કરો—મોટાભાગના ORMs આ બાબતને અવગણે છે.
EXPLAIN ANALYZEચલાવો; ડેટાબેઝ પોતે જ સમસ્યા દર્શાવશે.- વધુ હાર્ડવેર ખરીદતા પહેલા ક્વેરીઝને ઓપ્ટિમાઇઝ કરો.
પહેલા સર્વર્સ સ્કેલ ન કરો. ક્વેરીઝ સ્કેલ કરો.