सर्च ऑटोकम्प्लीट 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 के मामले में)

[moderator]

मैं एडमिन हूं.
अभी यह देखा जा रहा है कि कमेंट चर्चा पोस्ट की तकनीकी सामग्री से असंबंधित बातों तक उलझकर कुछ ज़्यादा गर्म हो रही है, इसलिए यह सूचना दी जा रही है.

तकनीकी चर्चा और फ़ीडबैक का हमेशा स्वागत है.
राय अलग-अलग हो सकती हैं, लेकिन कमेंट लिखते समय एक-दूसरे के प्रति बुनियादी शिष्टाचार बनाए रखें और तर्क-केंद्रित चर्चा करें, तथा व्यक्तियों या उनके करियर से अधिक इस पोस्ट की मौजूदा सामग्री पर ही चर्चा केंद्रित रहे.

कृपया साइट उपयोग विधि में दी गई कमेंट लिखने की गाइड को एक बार फिर देख लें.

• कृपया विनम्र और शालीनता से बात करें.
• कृपया लेखक को निशाना न बनाएं.

संदर्भ के लिए, फ़्लैग किए गए पोस्टों पर रिकॉर्डिंग और सिस्टम-स्तरीय कार्रवाई पहले से की जा रही है, और हम संबंधित संचालन नीतियों और सिस्टम में लगातार सुधार करते रहेंगे.
इसके अलावा, यदि संचालन के बारे में कोई राय या फ़ीडबैक हो, तो बेझिझक ईमेल से संपर्क करें.

[kunggom]

हाँ, समझ गया।

[kunggom]

मुझे लगता है कि टिप्पणियों का माहौल थोड़ा अजीब है। क्या शुरुआत में पोस्ट होने के समय की तुलना में शीर्षक या सामग्री में कुछ बदला गया है? मुझे यह नहीं लगता कि इस स्तर का लेख पोस्ट होना अपने-आप में अजीब है.

"कंपनी के टेक ब्लॉग में ऐसे लेख नहीं लिखे जाते होंगे." जैसी राय भी है, लेकिन लक्ष्य performance को परिभाषित करना और उसे हासिल करने के लिए बार-बार सुधार करना, कंपनी के टेक ब्लॉग में अक्सर आने वाला विषय है.

उदाहरण के लिए, मैंने पहले ऐसा एक लेख देखा था.

• नए service को deploy करने से पहले experiment और improvement दोहराने की कहानी

[kuthia]

मैं आपकी बात से सहमत हूँ.
लेकिन मुझे लगता है कि मौजूदा स्थिति में मुद्दा abuse करने वाले user के रवैये की आलोचना है. पोस्ट की quality कैसी है वगैरह कहना मुझे लगता है कि मुद्दे से हटकर है.
गैर-मैत्रीपूर्ण प्रतिक्रिया शायद लेखक के abuse के पिछले रिकॉर्ड की पृष्ठभूमि की वजह से है. कंटेंट कैसा है वगैरह कहना मुझे अनावश्यक अतिरिक्त बात लगता है.

[kunggom]

इसीलिए वही हिस्सा सवाल खड़ा करता है।
अगर सभी ने बल्कि "यह व्यक्ति abuser है!" जैसी प्रतिक्रिया दी होती, तो शायद मैं ऐसा कमेंट नहीं लिखता। लेकिन ज़्यादातर कमेंट मूल पोस्ट की गुणवत्ता पर बात कर रहे थे, इसलिए वही बात अजीब लगती है। अगर सच में समस्या abusing ही थी, तो फिर पोस्ट की गुणवत्ता की बात करना क्या पूरी तरह अनावश्यक अतिरिक्त टिप्पणी नहीं है?

[nemorize]

मैं सहमत हूँ.
यहाँ तक कि "मैंने इसे मई 2025 से सेना में अकेले बनाना शुरू किया था!" यह देखने पर भी, यह कोई कंपनी ब्लॉग भी नहीं है...

बेशक, यह नकारना मुश्किल है कि साझा की गई बात "वैसा काम है जो स्वाभाविक रूप से किया ही जाना चाहिए",
और यह भी सही है कि इसमें "कोई अलग पहचान की बात नहीं है और यह लेखक के अभ्यास-स्तर की सामग्री" है,

लेकिन क्या GeekNews ऐसी चीज़ें साझा नहीं की जानी चाहिए, ऐसी माहौल वाली जगह थी?
क्या जिन कामों को स्वाभाविक रूप से किया जाना चाहिए, उन्हें करके मिले अनुभव साझा नहीं करने चाहिए?
क्या बिना किसी अलग पहचान वाले अनुभव साझा नहीं करने चाहिए?
क्या अभ्यास-स्तर के अनुभव साझा नहीं करने चाहिए?

[ifmkl]

ऐसा आपको लगा हो सकता है। मैंने नीचे जैसा कमेंट करने के दो कारण थे। पहला, पहले पोस्ट किया गया show gn वाला लेख abuse के कारण flagged किया गया था। एक दिन बाद उन्होंने अपने velog लेख का सारांश बनाकर नया पोस्ट डाला, लेकिन क्या उस लेख का कंटेंट वास्तव में पोस्ट होने लायक था? अगर पूछा जाए कि क्या उसमें लेखक की अपनी समस्या-चिंतन और मेहनत दिखाई दी, तो दूसरों की राय की तरह मेरा भी मानना है कि search एक ऐसा क्षेत्र है जहाँ तकनीक काफी हद तक सामान्य रूप से उपलब्ध है, और तकनीकी हिस्से की तुलना में ब्लॉग की सामग्री मुझे घुमाकर अपनी सेवा के प्रचार के विस्तार जैसी लगी, इसलिए मैंने वह बात लिखी।

[kunggom]

लगता है कि abuse flag की वजह से उनके प्रति नकारात्मक धारणा बन जाना ही सबसे बड़ा कारण है।
ब्लॉग की सामग्री अपने ही service के प्रचार का विस्तार हो, यह बात दूसरी कंपनियों के technical blogs पर भी समान रूप से लागू होती है, इसलिए सिर्फ उसी आधार पर उसे खारिज करना काफ़ी संवेदनशील मानदंड है, ऐसा मेरा मानना है।
और इस लेख में लेखक की अपनी चिंता और मेहनत दिखी या नहीं, इस सवाल पर भी, index लगाने से performance बेहतर होगी इस परिकल्पना के गलत साबित होने के बाद execution plan देखना, business logic को ध्यान में रखते हुए query या schema बदलते हुए बार-बार सुधार करना, और इस तरह target performance हासिल करना, मुझे तो काफ़ी हद तक पर्याप्त सोच-विचार और मेहनत ही लगता है।

[ifmkl]

मैंने ब्लॉग पर जाकर मूल लेख भी पढ़ा। शीर्षक और वास्तविक सामग्री के बीच थोड़ा अंतर महसूस होता है। आपने जो फीचर इम्प्लीमेंट किए हैं या सुधार की दिशा में जो काम किया है, वे पहले से मौजूद कई open source प्रोजेक्ट्स में पहले ही इम्प्लीमेंट और रिफ्लेक्ट हो चुके हिस्से हैं, और आपने जो काम किया है वह मूल रूप से अपनी सेवा में पहले बहुत साधारण रूप से इम्प्लीमेंट किए गए सर्च को अधिक उन्नत बनाने वाला हिस्सा है। लेकिन सिर्फ शीर्षक देखें तो ऐसा लगता है मानो एल्गोरिदम में बड़े पैमाने पर सुधार किया गया हो,, पिछली पोस्ट भी प्रचार के रूप में flagged हुई थी, इसलिए लगता है कि लिखते समय थोड़ा और सोच-विचार जरूरी नहीं होगा क्या।

[newcodes7]

अगर आपको ऐसा महसूस हुआ, तो उसके लिए क्षमा चाहता हूँ। मेरा मानना है कि हर व्यक्ति शीर्षक देखकर अलग तरह की सामग्री की अपेक्षा करता है। फिर भी, यह सही है कि मुझे ऐसा शीर्षक लिखना चाहिए जो अपेक्षित सामग्री को यथासंभव स्पष्ट और समान रूप से दर्शाए। मैं आगे इसका ध्यान रखूँगा.

साथ ही, कृपया इसे पिछले लेख से अलग करके देखें। पिछले लेख में मैंने दो निष्क्रिय खातों का उपयोग करके upvote करने की कोशिश की थी, जिसके कारण उसे flagged किया गया। यह पूरी तरह मेरी गलती थी, और मैं बताना चाहता हूँ कि यह लेख की सामग्री की समस्या नहीं थी।

[click]

मुझे यह जानने की जिज्ञासा है कि क्या आपने lower() index की जगह GIN index इस्तेमाल करने पर विचार किया था। वैसे भी आपने jdbctemplate से raw SQL इस्तेमाल किया है, तो ऐसे में FTS कैसा रहेगा?

CompletableFuture.supplyAsync() का इस्तेमाल करने वाला asynchronous तरीका भी, अगर अलग से ExecutorService निर्दिष्ट न किया जाए, तो forkjoinpool के commonpool का उपयोग करता है, इसलिए
request thread की जगह इस्तेमाल होने वाला commonpool भर जाने की हद तक अगर concurrent users बढ़ जाएँ (cpu 코어 - 1개), तो यह संभाल नहीं पाएगा।
इस हिस्से को reactive तरीके में बदलना या JVM version बढ़ाकर virtual threads अपनाना शायद अधिक साफ-सुथरा समाधान होगा।

[newcodes7]

नमस्ते! सबसे पहले, फीडबैक कमेंट छोड़ने के लिए आपका सच में बहुत धन्यवाद।

हमने तय किया कि इस मामले में GIN index की ज़रूरत नहीं है! मौजूदा search autocomplete recommendation API में सिर्फ term ही चाहिए। यह जानना ज़रूरी नहीं है कि वह term किन article में शामिल है।
वहीं दूसरी ओर, search API में हम GIN index से मिलते-जुलते index का उपयोग कर रहे हैं। Postgres के extension paradeDB का इस्तेमाल करके BM25 index का उपयोग करते हैं।
पोस्टिंग में यह विस्तार से नहीं आया है, लेकिन फिलहाल हम अलग से ExecutorService निर्दिष्ट करके उपयोग कर रहे हैं। हालांकि, जैसा आपने कहा, reactive तरीका या virtual threads पर भी आगे चलकर विचार करेंगे!!

[winterjung]

अच्छा लगा पढ़कर। शुरुआत में लगा था कि शायद यह सिर्फ index लगाने पर लिखा गया लेख होगा, लेकिन आप वहीं नहीं रुके और अलग-अलग तरीकों को आज़माकर उन्हें साझा भी किया, यह बहुत अच्छा लगा। आगे चलकर, जैसा आपने कहा, trie को इस्तेमाल करके देखना भी अच्छा रहेगा, या फिर जिन trending terms की हाल की search ज़्यादा हुई है उन्हें थोड़ा अधिक weight देना जैसी दिशा में भी सुधार किया जा सकता है!
एक बात की जिज्ञासा है: आपने term और decomposed term दोनों को or condition से query किया है, लेकिन क्या decomposed term upper superset होने की वजह से सिर्फ इसी field को query करना काफी नहीं होगा? मेरा ऐसा सोचना है क्योंकि अगर query “neng” हो, तो वह “nieong” में decompose हो जाएगी, इसलिए “Naver” भी search हो जाना चाहिए। और अगर actual term “neng” ही हो, तब भी वैसे ही search हो जाएगा।

[newcodes7]

जैसा आपने कहा, सिर्फ decomposed term से query करना भी पर्याप्त है। इसके बाद term वास्तव में एक अनावश्यक शर्त थी, लेकिन लगता है कि मैं यह बात ध्यान में नहीं रख पाया था। आपकी वजह से इसे ठीक कर दिया। धन्यवाद!

[newcodes7]

इस लेख और पिछले लेख के संबंध में मैं माफ़ी मांगना चाहता हूँ.
दो इस्तेमाल न होने वाले अकाउंट्स से upvote करना मेरी गलती थी और यह एक मूर्खतापूर्ण काम था.

मैंने लंबे समय तक मेहनत से बनाए गए प्रोजेक्ट को लोगों की नज़र में थोड़ा और लाने की इच्छा में गलत व्यवहार किया.
लेकिन ऐसा कारण होने पर भी नियम उल्लंघन को सही नहीं ठहराया जा सकता, यह भी सच है.
मेरे द्वारा लापरवाही से किए गए upvote की वजह से किसी और की पोस्ट की रैंक नीचे गई होगी, और इससे साइट की व्यवस्था भी बिगड़ी होगी.

इसके अलावा, flagged होने के ठीक अगले दिन एक नई पोस्ट डालना भी काफ़ी गलतफ़हमी पैदा कर सकता था.
सच कहूँ तो, साइट उपयोग पर अलग से कोई प्रतिबंध नहीं था, इसलिए मुझे लगा कि क्या मैं तुरंत पोस्ट कर सकता हूँ. यह मेरी छोटी सोच थी.
अब सोचता हूँ तो, प्रतिबंध हो या न हो, मुझे संयम रखना चाहिए था.
अगर उल्टी स्थिति में सोचूँ, तो जिस जगह को मैं पसंद करता हूँ वहाँ कोई और यही काम करता, तो मुझे भी वह अच्छा नहीं लगता.

मैंने अब तक डेवलपमेंट शुरू करने के बाद से बिना शर्त यह मानकर चलाया था कि 'शेयर' करना हमेशा अच्छा होता है, और उसी तरह व्यवहार भी किया.
लेकिन इस घटना के बाद मुझे महसूस हुआ कि साझा करने की भी अपनी सही जगह होती है, और उसका सही समय भी होता है.
और यह भी महसूस हुआ कि अगर मैं किसी ऐसी जगह में नया आया हूँ जिससे कोई और लगाव और रुचि रखता है, तो सबसे पहले मुझे सामने वाले का पूरा सम्मान करना चाहिए.
इसीलिए मुझे पहले उपयोग नियम पढ़ने चाहिए थे, साइट का माहौल समझना चाहिए था, और उसके विरुद्ध कोई व्यवहार नहीं करना चाहिए था.

मैं अपनी गलती स्वीकार करता हूँ, और इस तरह अपना स्पष्टीकरण दे रहा हूँ.
अगली बार से मैं और अधिक परिपक्व तरीके से इसका उपयोग करूँगा.

[roxie]

:+1:

[skageektp]

मुझे लगता है कि GeekNews देखने आने वाले लोग जो देखना चाहते हैं, उसके लिहाज़ से यह थोड़ा अटपटा-सा लग सकता है, है ना?

[kunggom]

मुझे सच में समझ नहीं आता कि इसमें इतना बढ़ा-चढ़ाकर कहने जैसा क्या है।
रिकॉर्ड की संख्या न तो 10 लाख है, न 1 करोड़; शीर्षक से ही साफ है कि पैमाना बस 1 लाख से थोड़ा ज़्यादा है। ऐसे में बुनियादी बातों पर ठीक से काम करने की बजाय किसी बहुत बड़ी optimization की उम्मीद करना ही थोड़ा अजीब नहीं है? आखिर लोग किस तरह की इतनी बड़ी चीज़ की उम्मीद कर रहे थे, यह जानने की जिज्ञासा है।
DB जब ठीक से optimized भी नहीं था, तब बुनियादी चीज़ों को एक-एक करके ठीक करते हुए लिखी गई पोस्ट को क्या सिर्फ उसी वजह से इतना baiting जैसा समझा जाना चाहिए, यह मुझे समझ नहीं आता। मेरी राय में, "जो सबसे बेहतरीन नहीं है, उसे यहाँ पोस्ट करना ही गलत है" जैसी बहिष्कारी हवा नुकसानदेह है।

[crawler]

वहाँ बुनियादी बातों पर टिके रहने के बजाय किसी भव्य optimization की उम्मीद करना ही थोड़ा अजीब नहीं है?

इंसान उतना ही देखता है जितना वह जानता है।
समझाना आसान हो, इसलिए मैं अभी bulletin board बनाने का उदाहरण सोच रहा हूँ।

शुरुआती developers को पहले portfolio के तौर पर अक्सर bulletin board बनाना सुझाया जाता था।

सीधे तरीके से सोचें तो यह आसान है।
पोस्ट डालें, और वह list में दिख जाए तो काम खत्म। अगर बहुत ही सरल बनाना हो, तो शायद backend DB की भी ज़रूरत न पड़े।

लेकिन इंसान उतना ही देखता है जितना वह जानता है।
अगर bulletin board को गंभीरता से बनाया जाए, तो DB से शुरू करके comment feature, login, और login को आगे बढ़ाएँ तो OAuth authentication या JWT, सिर्फ writing feature में भी image और video attachment, post formatting support, और XSS से शुरू होने वाली security तक बात जाती है।

एक ही text को पढ़कर भी, पढ़ने वाले की background knowledge के अनुसार उसके मन में बनने वाली तस्वीर बहुत अलग हो सकती है।

मुझे समझ में आता है कि kunggom ने title देखकर किस तरह के autocomplete की कल्पना की होगी।

लेकिन हर पाठक अलग जीवन जीकर आया है, और आखिरकार पाठकों ने जो functionality कल्पना की होगी, वह एक-दूसरे से काफी अलग होगी।

मुझे यह भी समझ में आता है कि आप किस इरादे से comment लिख रहे हैं।
मैं भी उस राय से सहमत हूँ, लेकिन मुझे विश्वास है कि आप जानते होंगे कि यह बात अभी यह लेख लिखने वाले की स्थिति से बहुत मेल नहीं खाती।

[kunggom]

"अभी यह बात इस पोस्ट लिखने वाले व्यक्ति की स्थिति से बहुत मेल नहीं खाती" वाले हिस्से के बारे में क्या आप थोड़ा और विस्तार से समझा सकते हैं?
मूल पोस्ट के अनुसार, यह प्रोजेक्ट एक personal project है, और न तो इसका बहुत ज़्यादा ट्रैफिक है, न ही यह कोई ऐसी service है जिसे revenue कमाना है — ऐसा स्पष्ट रूप से लिखा गया है। इसलिए अगर इसमें कोई बहुत भारी-भरकम optimization डाला जाता, तो उसका कारण व्यावहारिक ज़रूरत से ज़्यादा व्यक्तिगत जिज्ञासा वगैरह ही माना जा सकता है। इसलिए मुझे यह अजीब नहीं लगता कि उस स्तर का technical effort इसमें नहीं लगाया गया। इसी वजह से कुछ लोगों की प्रतिक्रिया का इतना तीखा नकारात्मक होना मेरी समझ में नहीं आ रहा। और शीर्षक में उद्धृत किए गए आँकड़े भी ऐसे नहीं हैं कि वे मुख्य लेख की सामग्री से मेल ही न खाते हों।

[crawler]

मुझे नहीं लगता कि kunggom उस स्तर के बैकग्राउंड नॉलेज के बिना डेवलपर हैं कि वे मेरे बताए बोर्ड वाले उदाहरण को भी समझ न सकें.

मुझे लगता है कि अभी हमारी राय का फर्क Abusing users को लेकर समझ के अंतर से आ रहा है, इसलिए मैं आखिरी बार अपनी बात कह रहा हूँ.

मैं जिस चीज़ की उम्मीद कर रहा था, वह semantic search थी.
semantic search आज के AI उछाल के दौर में कोई बिल्कुल अवास्तविक विषय नहीं है, और मुझे भरोसा है कि आप जानते होंगे कि इसे कोई व्यक्ति अकेले भी पर्याप्त रूप से implement कर सकता है.

शुरू से ही जब हम कोई title क्लिक करते हैं, तो हम उसे लिखने वाले की पृष्ठभूमि समझकर क्लिक नहीं करते, लेकिन मेरा मतलब यह है कि भले ही वह बहुत भारी traffic वाला या revenue कमाने वाला service न हो, तब भी इसे पर्याप्त रूप से implement किया जा सकता है.

और मैं अभी सिर्फ title के बारे में बात कर रहा हूँ.

मूल पोस्ट के अनुसार वह project ~

मैं उस image के बारे में बात कर रहा हूँ जो title देखकर मेरे मन में बनी थी, और यह हिस्सा अभी हमारी बातचीत में ज़रूरी नहीं है.

अभी यह post लिखने वाले की स्थिति
अब मुझे लगता है कि kunggom इस post लिखने वाले को किस नज़र से देखते हैं. लगता है आप उन्हें एक beginner developer मानते हैं, ऐसा डेवलपर जिसे वह कुछ भी लिखे तो समझ लिया जाना चाहिए.

जैसा मैंने कल कहा था, अगर वह flagged नहीं हुआ होता तो मैं भी उससे सहमत होता, लेकिन जिस क्षण उसने अपने लिखे post की recommendation में हेरफेर किया, उस बिंदु के बाद यह बात बेमानी हो जाती है.

और अगर आपको सच में लगता है कि abusing में पकड़ा गया व्यक्ति अगले दिन फिर से post लिखे, यही समस्या है

आपने ऊपर ऐसा कहा था.
अगर flagged होने के बाद भी उसे post लिखने की आज़ादी है, तो उसकी आलोचना करने की आज़ादी भी है.
जैसा आपने खुद कहा, अगर आपको लगता है कि अभी comments में flagged हुए व्यक्ति से थोड़ा अधिक सख्ती से बात करना समस्या है, तो comments में यह बात उठाने के बजाय संचालन टीम को सुझाव दें.

[kunggom]

आप कह रहे हैं कि आपने ऐसे प्रकार की service के optimization अनुभव को साझा करने की उम्मीद की थी, जो embedding वगैरह का उपयोग करके, भले इनपुट बिल्कुल बेढंगा हो, फिर भी सही search candidates सुझा दे।
अगर ऐसी बात थी, तो मुझे लगता है कि ऐसी उम्मीद शायद "search term recommendation" जैसे शीर्षक से करनी चाहिए थी, लेकिन आप किस तरह की चीज़ की अपेक्षा कर रहे थे, यह मैं समझता हूँ।

abusing के प्रति आलोचनात्मक रुख मैं समझता हूँ, लेकिन आख़िरी वाक्य ने चुपचाप बहस का केंद्र technical immaturity से community rules के उल्लंघन की समस्या की ओर मोड़ दिया, और वह कुछ ऐसा लगा जैसे "मैं तुम्हारी अपनी logic और claim से तुम्हें rebut करूँगा" वाला एक अधकचरा ताइक्वोंडो-सा प्रयास हो; यह थोड़ा निराशाजनक लगा।
बेहतर होता कि आप शुरू से ही सिर्फ abusing की ही आलोचना करते; तब बात ज़्यादा persuasive होती। अगर सचमुच ऐसा किया गया होता, तो भले ही वह लेख वास्तव में latest DBMS में vector embedding optimization जैसी वही चीज़ समेटे होता, जिसकी आप मूल रूप से उम्मीद करने का दावा कर रहे थे, या फिर उसमें "विनम्र शीर्षक" इस्तेमाल किया गया होता, तब भी लेखक के हालिया abusing history को लेकर शत्रुतापूर्ण प्रतिक्रिया आती, और उस हिस्से पर मुझे कोई आपत्ति नहीं है। क्योंकि वह technical content से बहुत अधिक संबंधित बात नहीं है।

मैं जिस बात का विरोध करता हूँ, वह यह है कि वह रूप आखिर "technical immaturity" की ओर इशारा करने के रूप में क्यों प्रकट हो रहा है। अगर abusing अस्वीकार्य व्यवहार है, तो स्वाभाविक रूप से उसे content से अलग भी निंदा मिलनी चाहिए। फिर उसमें content की आलोचना शामिल करने की ज़रूरत क्या है? लेकिन यहाँ लगे comments में लगभग सभी में यह nuance है कि content technical रूप से immature है। crawler-nim ने भी मुझे "शुरुआती developer का bulletin board बनाना" जैसी उपमा देते हुए कहा था कि "जितना जानते ho, उतना दिखता है"। तब क्या यह शक नहीं होना चाहिए कि abusing असल में secondary, बाद में जोड़ी गई समस्या है?

अगर comments की बात मानें, तो यदि मूल लेख सचमुच वैसा ही होता जैसा crawler-nim उम्मीद कर रहे थे, तब भी आप abusing मात्र के आधार पर उसकी आलोचना करते। या फिर क्या ऐसा है कि abusing किया गया हो, लेकिन अगर आपको लेख का content पसंद आ जाए, तो "सख्ती से" बोलने की स्वतंत्रता इस्तेमाल करने की ज़रूरत नहीं रहती?
इसीलिए मैं फिर पूछ रहा हूँ। अगर आप सचमुच मूल लेखक की abusing की वजह से उसकी आलोचना कर रहे हैं, तो abusing के बजाय content पर केंद्रित comments लिखने का कोई कारण था क्या?

[kunggom]

क्या इस बात के लिए कोई आधार है कि मैंने "दूसरों की बोलने की आज़ादी में बाधा" डाली? यह बात मुझे कुछ समझ नहीं आ रही। ऐसा तो नहीं है कि मेरे पास इस जगह का कोई मॉडरेशन अधिकार है, जिससे मैं दूसरों को पोस्ट या टिप्पणी लिखने से रोक सकूँ। वास्तव में, आपने भी इतनी लंबी टिप्पणी आराम से लिखी है।
अगर सिर्फ किसी और की राय के विरोध में टिप्पणी लिखना ही किसी की बोलने की आज़ादी रोकना है, तो फिर crawler-nim को भी अभी मेरी अभिव्यक्ति की स्वतंत्रता का उल्लंघन करने वाला माना जाना चाहिए। अगर ऐसा नहीं है, तो तार्किक रूप से यह दोहरा मापदंड नहीं होगा क्या?

और जैसा कि crawler-nim ने भी माना, अंततः abuse है या नहीं, यह निर्णय के मानदंड में बिल्कुल महत्वपूर्ण नहीं था।
क्या यह "जैसा मैंने कल कहा था, अगर flagged नहीं किया गया होता तो मैं भी उससे सहमत होता, लेकिन जिस क्षण लिखी गई पोस्ट पर recommendation manipulation की गई, उसके बाद यह बात निरर्थक हो जाती है।" इस बात से विरोधाभासी नहीं है?
अभी ऐसा लग रहा है कि लगातार मुद्दा और दावा बदल रहे हैं, इसलिए अच्छा होगा कि आप इसे किसी एक बात पर स्थिर रखें।

[kunggom]

मेरे विचार से, समुदाय के विषय से पर्याप्त रूप से संबंधित और AI slop न होने वाली किसी पोस्ट के बारे में सामूहिक रूप से यह कहना — या ऐसा दिखना — कि "यह लेख हमारे समुदाय के स्तर के लायक नहीं, यह स्तरहीन है", शायद vote manipulation से भी अधिक समुदाय की वृद्धि और उसके बने रहने के लिए हानिकारक हो सकता है। क्योंकि इससे उस समुदाय की बाहरी छवि बहिष्कारी दिखाई दे सकती है, और उसके कारण संभावित नए उपयोगकर्ताओं का आना काफी हद तक बाधित हो सकता है.

बेशक, इसका मतलब यह नहीं है कि आलोचना ही न की जाए। लेकिन कम से कम मुझे लगता है कि ऐसा माहौल थोड़ा अजीब है। क्योंकि समान रूप से बस यही निराशा दिखी कि लेख वैसा नहीं था जैसा वे अपेक्षा कर रहे थे, जबकि रचनात्मक लगने वाला विश्लेषण और feedback बहुत कम थे.

और यदि आपको सचमुच लगता है कि जिन लोगों को वास्तव में abusing करते पकड़ा गया, उनका अगले ही दिन फिर से पोस्ट लिखना समस्या है, तो इस अवसर पर संचालन टीम को औपचारिक रूप से संबंधित नियम जोड़ने का सुझाव देना कैसा रहेगा? मेरी जानकारी में पहले से कुछ हद तक प्रतिबंध मौजूद हैं, लेकिन लगता है कि आपको वे अपर्याप्त लगते हैं.

[bandcrownie]

ऐसा लगता है कि आपने भी 육룡의시대, 웹삼국무쌍전 जैसी दूसरी साइटों की galleries में अक्सर अपना प्रचार किया है.
जब आप अपने अधूरे काम को बस ट्रायल के लिए आगे रखते हैं और बाद में उस प्रोजेक्ट को आसानी से छोड़ देते हैं, तो यह समझना मुश्किल है कि यह पोस्ट उससे अलग कैसे है.. फिर दूसरों के लिए इतने सख्त मापदंड क्यों लागू करते हैं?

क्या DC बच्चों के खेलने की जगह है इसलिए वहाँ मनमानी करना ठीक है, और GeekNews वह जगह है जिससे आपको लगाव है, इसलिए अगर कोई और उसे गंदा करे तो आप बर्दाश्त नहीं कर पाते?

मैं यह कोई खास तार्किक बात कहने के लिए नहीं कह रहा, बस आपका दोहरा रवैया इतना नया लगा कि कह दिया, इसलिए मेरे जवाब का खंडन करने वाले आप सही हैं. Abusing फाइटिंग है.

[ifmkl]

मुझे तो उल्टा यह समझ नहीं आ रहा। क्या आप इसे ऐसे देख रहे हैं कि इसे लोगों ने सामूहिक और संगठित तरीके से आलोचना करने के लिए पोस्ट किया है? आपकी बात ही बल्कि ऐसी लगती है जैसे हर व्यक्ति जो अपनी राय रख सकता है, उसे आप नकारात्मक नज़र से देख रहे हों। आगे भी अगर development log जैसी पोस्टें (printf से स्टार ड्रॉइंग सुधारने के लिए लक्ष्य तय किया, सुधार किया, और फिर for loop इस्तेमाल किया!) आएँ, तो उम्मीद है आप उन्हें भी इसी गर्मजोशी से देखेंगे।

[tensun]

सर्च autocomplete API को जैसे किसी optimized service की तरह शीर्षक दिया गया है, लेकिन सामग्री तो बस साधारण DB search optimization ही है.
अगर यह commercial use के लिए है, तो Oracle optimization से ही यह काफी हद तक संभव है, और autocomplete के लिए पहले से कई services मौजूद हैं. इसमें किसी differentiator की भी बात नहीं है, और सामग्री भी लेखक के निजी अभ्यास स्तर की लगती है.
इसे पढ़ना थोड़ा असहज लगता है.