Jinsi Safu Isiyo na Index Ilivyozima Database Yetu
Index moja iliyokosekana iligeuza API ya 8 ms kuwa jinamizi la sekunde 8.
Tulifanya jaribio la mzigo (load test) kabla ya toleo kubwa. Maendeleo ya ndani (local development) yalifanya kazi vizuri kwa rekodi 100. Kisha tulijaribu kuiga watumiaji 500 dhidi ya mistari (rows) milioni 1.5 katika data yenye ukubwa wa uzalishaji (production-sized data).
Matokeo yalikuwa mabaya:
- Muda wa majibu ya API ulipanda kutoka 45 ms hadi 8,000 ms.
- CPU ya database ilifikia 100 %.
- Connection pools zilimalizika, na kusababisha makosa ya timeout.
Tulikagua logi ya maswali ya polepole (slow-query log) na kukuta endpoint inayochukua historia ya oda kwa kutumia user ID na status.
Kuendesha EXPLAIN ANALYZE kwenye PostgreSQL kulionyesha Sequential Scan. Injini ilisoma mistari yote milioni 1.5 kwa kila ombi kwa sababu hakukuwa na index kwenye user_id.
Kwa maombi 100 ya wakati mmoja (concurrent requests), iliskani mistari milioni 150 kwa mpigo.
Suluhisho lilichukua dakika tano.
Badala ya index rahisi kwenye user_id, tulitengeneza composite index kwenye (user_id, status, created_at DESC). Hiyo iliiruhusu database:
- Kuchuja kwa
user_id. - Kuchuja kwa
status. - Kurudisha mistari mipya mara moja.
- Kuruka hatua za ziada za kupanga (sorting).
Tulitumia CREATE INDEX CONCURRENTLY ili jedwali (table) libaki likiwa wazi (unlocked) wakati wa operesheni hiyo.
Baada ya suluhisho:
- Muda wa swali (query time) ulishuka kutoka 8,150 ms hadi 0.14 ms.
- Latency ya API ilishuka kutoka sekunde 8 hadi 12 ms.
- Matumizi ya CPU yalishuka kutoka 100 % hadi chini ya 8 %.
Mafunzo tuliyopata:
- Majaribio ya ndani (local testing) yanadanganya; mistari 100 haiwakilishi milioni moja.
- Weka index kwenye foreign keys zako—ORMs nyingi hupuuza hili.
- Endesha
EXPLAIN ANALYZEkabla ya kununua vifaa (hardware) zaidi. - Sanifu index kulingana na maswali (queries) unayoyatumia hasa.
Usiongeze uwezo wa seva (scale servers) kwanza. Ongeza uwezo wa maswali (scale queries).
