Jinsi Safu Isiyo na Index Ilivyoharibu Database Yetu
Index moja iliyokosekana iligeuza API ya ms 8 kuwa jinamizi la sekunde 8.
Tulifanya jaribio la mzigo (load test) kabla ya toleo kubwa. Maendeleo ya ndani (local development) yalishughulikia mistari 100 vizuri. Katika staging, tulijaribu watumiaji 500 dhidi ya mistari milioni 1.5.
Kila kitu kilivunjika.
- Muda wa majibu ya API ulipanda kutoka ms 45 hadi ms 8,000.
- CPU ya database ilifikia 100%.
- Connection pools zilimalizika.
- Maombi yalipata timeout.
Sababu ilikuwa ni query rahisi iliyokuwa inatafuta historia ya oda kwa user_id na status.
Kuendesha EXPLAIN ANALYZE kwenye PostgreSQL kulionyesha Sequential Scan. Bila index kwenye user_id, injini ilisoma mistari yote milioni 1.5 kwa kila ombi.
Kwa maombi 100 yanayofanyika kwa wakati mmoja, database iliskani mistari milioni 150 kwa mpigo.
Suluhisho lilichukua dakika tano. Tulitengeneza composite index kwenye (user_id, status, created_at DESC) kwa kutumia CREATE INDEX CONCURRENTLY ili jedwali libaki likiwa hewani.
Matokeo:
- Muda wa query ulishuka kutoka ms 8,150 hadi ms 0.14.
- Latency ya API ilishuka kutoka sekunde 8 hadi ms 12.
- Matumizi ya CPU yalishuka kutoka 100% hadi chini ya 8%.
Mafunzo tuliyopata:
- Majaribio ya ndani yanadanganya; mistari 100 si kielelezo cha milioni moja.
- Weka index kwenye foreign keys—ORMs nyingi hupuuzia hili.
- Tumia
EXPLAIN ANALYZE; database huonyesha tatizo. - Boresha queries kabla ya kununua hardware zaidi.
Usipanue seva kwanza. Panua queries.