सर्च ऑटोकम्प्लीट API ऑप्टिमाइज़ेशन - 1.1 लाख डेटा पर 100ms के भीतर रिस्पॉन्स

प्रोजेक्ट परिचय

• NewCodes एक कंपनी टेक ब्लॉग क्यूरेशन सर्विस है
• Spring Boot + PostgreSQL आर्किटेक्चर
• सर्च ऑटोकम्प्लीट फीचर इम्प्लीमेंटेशन: Term-आधारित रिकमेंडेशन, जामो-विभाजित खोज, initials खोज, कंपनी पेज रिकमेंडेशन

परफॉर्मेंस समस्या की पहचान

• Term टेबल में 1.1 लाख डेटा जमा हो गया
• API रिस्पॉन्स टाइम 1000ms+ तक बढ़ गया
• लक्ष्य: 100ms के भीतर रिस्पॉन्स

पहला प्रयास: इंडेक्स जोड़ना (1000ms → 700ms)

• varchar_pattern_ops का उपयोग करके LIKE प्रीफिक्स सर्च ऑप्टिमाइज़ेशन इंडेक्स बनाया
• CONCURRENTLY ऑप्शन से सेवा बंद किए बिना इंडेक्स बनाया
• term, decomposed_term, chosung कॉलम पर अलग-अलग इंडेक्स लागू किए

दूसरा प्रयास: LOWER फ़ंक्शन इंडेक्स (700ms → 110ms)

• LOWER() फ़ंक्शन के कारण full scan समस्या की पहचान हुई
• फ़ंक्शन-आधारित इंडेक्स (Functional Index) बनाया
• LOWER(컬럼명) varchar_pattern_ops रूप में इंडेक्स को फिर से बनाया

तीसरा प्रयास: JOIN → EXISTS (110ms → 100ms)

• Corporation और Article का INNER JOIN परफॉर्मेंस bottleneck था
• EXISTS subquery में बदलकर scan range कम किया
• केवल "डेटा मौजूद है या नहीं" की जाँच के लिए ऑप्टिमाइज़ किया

चौथा प्रयास: denormalization & covering index (100ms → 90ms)

• total_frequency कॉलम जोड़कर aggregate operation हटाया
• GROUP BY, SUM operations को precomputed values से बदला
• covering index से I/O की संख्या कम की
• INCLUDE clause से term और total_frequency को इंडेक्स में शामिल किया

पाँचवाँ प्रयास: JDBC Template (90ms → 80ms)

• JPA/Hibernate overhead हटाया
• JDBC Template से सीधे query execute की
• simple read में ORM layer को छोड़ना प्रभावी रहा

Nginx Rate Limiting समस्या का समाधान

• शुरुआती सेटिंग: 1 सेकंड में 2 बार सीमा, burst 10
• 100ms debouncing के कारण request failure हुआ
• सुधार: 1 सेकंड में 10 बार अनुमति, burst 20 में बदलाव
• 444 → 429 status code में बदलाव

रिस्पॉन्स डेटा आकार कम करना

• JSON field names हटाकर array-आधारित रिस्पॉन्स में बदलाव
• type को संख्या से अलग किया गया (0: Corporation, 1: Theme, 2: Term)
• नेटवर्क ट्रांसफर समय कम हुआ

CompletableFuture parallel processing

• Corporation, Theme, Term queries को स्वतंत्र रूप से साथ में चलाया
• sequential execution की तुलना में अधिकतम रिस्पॉन्स समय जितना ही समय लगा
• ExecutorService और exception handling जोड़ी गई

अंतिम उपलब्धि

• शुरुआती 1000ms → अंतिम 80ms (डेवलपमेंट सर्वर), 40ms (प्रोडक्शन सर्वर)
• लगभग 90% से अधिक परफॉर्मेंस सुधार

मुख्य सीख

• समस्या को परिभाषित करने और दिशा तय करने का महत्व
• AI के उपयोग और डेवलपर की समीक्षा के बीच संतुलन
• पूरे आर्किटेक्चर के दृष्टिकोण से डिज़ाइन की आवश्यकता
• इंडेक्स प्रकार चुनना: single/composite/covering index
• फ़ंक्शन इस्तेमाल करते समय इंडेक्स अमान्य होने पर सावधानी
• JPA के आंतरिक कामकाज की समझ
• EXPLAIN के जरिए query execution plan का विश्लेषण

आगे के सुधार की दिशा

• Trie data structure का उपयोग
• अक्सर खोजे जाने वाले terms की caching
• CDN का उपयोग (global service के मामले में)