एका इंडेक्स नसलेल्या कॉलममुळे आमचा डेटाबेस कसा कोलमडला
एका साध्या इंडेक्सच्या अभावामुळे ८ ms चा API ८ सेकंदांच्या भयावह स्थितीत बदलला.
आम्ही एका मोठ्या रिलीजपूर्वी लोड टेस्ट केली. लोकल डेव्हलपमेंटमध्ये १०० rows व्यवस्थित हाताळले जात होते. स्टेजिंगमध्ये आम्ही १.५ दशलक्ष (1.5 million) rows वर ५०० युजर्स सिम्युलेट केले.
सर्व काही कोलमडले.
- API रिस्पॉन्स टाइम ४५ ms वरून ८,००० ms पर्यंत वाढला.
- डेटाबेस CPU १००% वर पोहोचला.
- कनेक्शन पूल्स (Connection pools) संपले.
- रिक्वेस्ट्स टाइम आउट झाल्या.
याचे कारण user_id आणि status द्वारे ऑर्डर हिस्ट्री शोधणारी एक साधी क्वेरी होती.
PostgreSQL वर EXPLAIN ANALYZE चालवल्यास 'Sequential Scan' दिसून आला. user_id वर इंडेक्स नसल्यामुळे, इंजिनने प्रत्येक रिक्वेस्टसाठी सर्व १.५ दशलक्ष rows वाचले.
१०० कॉनकरंट रिक्वेस्ट्स असताना डेटाबेसने एकाच वेळी १५० दशलक्ष rows स्कॅन केले.
हे दुरुस्त करण्यासाठी फक्त पाच मिनिटे लागली. आम्ही CREATE INDEX CONCURRENTLY वापरून (user_id, status, created_at DESC) वर एक कंपोझिट इंडेक्स तयार केला, जेणेकरून टेबल ऑनलाइन राहील.
निकाल:
- क्वेरी वेळ ८,१५० ms वरून ०.१४ ms पर्यंत खाली आला.
- API लॅटन्सी (latency) ८ सेकंदांवरून १२ ms पर्यंत कमी झाली.
- CPU वापर १००% वरून ८% च्या खाली आला.
शिकायला मिळालेले धडे:
- लोकल टेस्ट्स दिशाभूल करणाऱ्या असू शकतात; १०० rows हे लाखो rows साठी पुरेसे नाहीत.
- फॉरेन कीज (Foreign keys) ला इंडेक्स करा—बहुतेक ORMs हे टाळतात.
EXPLAIN ANALYZEचालवा; डेटाबेस स्वतः समस्या दाखवतो.- अधिक हार्डवेअर खरेदी करण्यापूर्वी क्वेरीज ऑप्टिमाइझ करा.
आधी सर्व्हर्स स्केल करू नका. क्वेरीज स्केल करा.