Redis array: लंबे विकास सफर की एक छोटी कहानी

 (antirez.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Redis के नए Array data type पर काम जनवरी की शुरुआत में शुरू हुआ और लगभग 4 महीने बाद PR के रूप में आया; पहले महीने में इसकी आवश्यकता, C structs, sparse representation, ring buffer, और ARINSERT के लिए array cursor semantics को शामिल करते हुए specification लिखी गई
  • शुरुआती design को Opus के साथ परिष्कृत किया गया, और GPT 5.3 रिलीज़ के बाद Codex के साथ design और development आगे बढ़ाया गया; AI के साथ feedback process में लगातार trade-offs और over-engineered हिस्सों की समीक्षा की गई
  • implementation को इस तरह बदला गया कि ARSET myarray 293842948324 foo जैसे बड़े index set भी बहुत बड़ी allocation के बिना काम करें; internal data structure स्थिति के अनुसार super directory, sliced dense directory, और actual array slice के रूप में बदलता है
  • हर slice डिफ़ॉल्ट रूप से 4096 elements रखता है, और ARSCAN व ARPOP पूरे range के size के बजाय वास्तव में मौजूद elements की संख्या के अनुपात में समय लेते हुए array को scan कर सकते हैं
  • Markdown files को Redis array में रखने का use case ARGREP implementation तक पहुँचा, regular expression support के लिए TRE को चुना गया, और use cases Redis PR #15162 में व्यवस्थित किए गए हैं

इम्प्लीमेंटेशन और समीक्षा

  • दूसरे महीने से automatic programming approach के साथ implementation शुरू किया गया और generated code की लगातार समीक्षा की गई
  • implementation के काम करने के बाद भी sparsearray.c और t_array.c सहित code को एक-एक पंक्ति पढ़कर जाँचा गया
  • AI की वजह से tests बहुत थे, लेकिन केवल ऊपर-ऊपर सही चलने वाला code सबसे अच्छा हो, यह ज़रूरी नहीं; इसलिए छोटे inefficiencies और design errors को ढूँढ़कर ठीक किया गया
  • कई modules को manual और AI-assisted तरीकों से फिर से लिखा गया, और तीसरे महीने में अलग-अलग तरीकों से stress testing की गई
  • उच्च-गुणवत्ता system programming में अब भी इंसानों की पूरी भागीदारी ज़रूरी है, लेकिन AI 32-bit support जोड़ने और tests जैसे थकाऊ कामों में, साथ ही complex algorithms में साफ़ bugs पकड़ने में, एक safety net की तरह काम करता है
  • शुरुआती बड़े specification दस्तावेज़ ने बाद के काम में केंद्रीय भूमिका निभाई, और code की हर पंक्ति की समीक्षा करके mismatch को ठीक करने में भी यह महत्वपूर्ण रहा

उपयोग के मामले और regular expressions

  • use cases को model करते समय Markdown files को Redis array में रखना शुरू किया गया, और निष्कर्ष निकला कि files array data type के साथ अच्छी तरह मेल खाती हैं
  • agent work के लिए ज़रूरी Markdown file-आधारित central knowledge base बनाने की ज़रूरत ने ARGREP implementation तक पहुँचाया
  • regular expression support के लिए TRE को चुना गया, क्योंकि Redis में regular expressions इस्तेमाल करते समय time या space के लिहाज़ से pathological patterns नहीं होने चाहिए
  • TRE foo|bar|zap जैसे उपयोगी pattern matching में बहुत अक्षम था, इसलिए GPT की मदद से इसे optimize किया गया, कुछ संभावित security issues ठीक किए गए, और tests भी बढ़ाए गए
  • use cases Redis PR #15162 में विस्तार से व्यवस्थित हैं, और इससे यह निष्कर्ष निकला कि Redis में ऐसा data type होना चाहिए जिसमें numeric index अर्थ का हिस्सा बने
  • उम्मीद है कि Array PR जल्द स्वीकार किया जाएगा और नए use cases के फायदे मिलेंगे; साथ ही feedback भी आमंत्रित है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की राय

  • साफ़ कर दें, यह काम Redis के मूल लेखक या उनमें से एक ने किया है
    वह कोई “औसत डेवलपर” नहीं हैं, और LLM इस्तेमाल करने के बाद भी इसमें 4 महीने लगे
    इसलिए इसे इस बात की मंजूरी की मुहर की तरह नहीं लेना चाहिए कि अब सभी डेवलपर्स को Claude Code, Codex, या दूसरे AI coding tools पर पूरी तरह शिफ्ट हो जाने का आदेश दिया जा सकता है
    खासकर आम startup CEO को यह बात देखनी चाहिए

    • यह इस बात का काफ़ी मज़बूत सबूत लगता है कि अनुभवी डेवलपर अगर coding agents को कुशलता से इस्तेमाल करें, तो उनकी विशेषज्ञता और बढ़ सकती है
    • “वह औसत डेवलपर नहीं हैं और LLM के साथ भी 4 महीने लगे” वाला हिस्सा मूल लेख में थोड़ा अलग है
      मूल में कहा गया था: “LLM से पहले भी implementation शायद 4 महीनों में हो सकता था। फर्क यह था कि उसी समय में मैं बहुत ज़्यादा काम कर सका।”
      यानी शुरुआती अवधि वैसे भी 4 महीने ही थी, और LLM की वजह से उसी समय में ज़्यादा काम हुआ
    • वह औसत नहीं हैं, लेकिन उनका काम भी निश्चित ही औसत काम नहीं है
      औसत development work ज़्यादा plumbing work और CRUD के करीब होता है

  • अभी मैं यह तरीका इस्तेमाल कर रहा हूँ
    पहले AI की मदद से high-level design document Markdown में लिखवाता हूँ। फिर उसी मॉडल से, लेकिन context हटाकर, या किसी दूसरे मॉडल से उसकी आलोचना करवाता हूँ ताकि bugs, omissions, और gaps मिल सकें। बाद में देखने पर वह हमेशा कुछ न कुछ साफ़ दिखने वाली चीज़ें पकड़ लेता है
    फिर उन findings का summary बनवाकर पहले AI को paste करता हूँ और उसकी राय पूछता हूँ। agreed changes बनाकर लागू करता हूँ, और यह adversarial round-robin तब तक चलता रहता है जब तक कोई भी model कोई meaningful suggestion न दे सके
    उसके बाद AI से plan बनवाता हूँ, और उस plan को भी कई AI के बीच adversarial तरीके से घुमाता हूँ। आखिर में एक काफ़ी solid plan निकलकर आता है
    फिर end-to-end test case plan वगैरह की तरफ़ बढ़ता हूँ। सिस्टम के आकार के हिसाब से, पहले दिन, पहले हफ़्ते, या पहले महीने के अंत तक coding के लिए तैयारी हो जाती है
    जब code बन जाता है, तो उस code, spec, और plan को दूसरे AI में डालकर bugs, omissions, और gaps ढूँढने को कहता हूँ। यानी implementation करने वाले मुख्य AI को लगातार दूसरे AI से verify करवाता हूँ
    बेशक, code खुद भी पढ़ना पड़ता है। क्योंकि मैंने AI को production-quality detail polish मिस करते देखा है

    • AI discourse में कहा जाता है कि हमने एक बिल्कुल नया unsupervised development paradigm खोल दिया है, लेकिन सच कहें तो यह लगभग उसी तरह है जैसे Google 10 साल से code बनाता आया है। बस फर्क इतना है कि अलग trust level वाले इंसानों की जगह AI इस्तेमाल हो रहा है
      मैं यह बात तंज़ में नहीं कह रहा। मेरा workflow भी मूल रूप से ऐसा ही है, और Google का मज़ाक उड़ाना भी उद्देश्य नहीं है। मतलब सिर्फ़ इतना है कि इसमें कुछ नया नहीं है
      AI effective workflows और ineffective workflows, दोनों को बहुत तेज़ कर देता है। इसकी वजह से क्या असरदार है और क्या नहीं, यह बहुत कम समय में, लगभग real time में सामने आ जाता है
    • जानना दिलचस्प होगा कि यह तरीका खुद code लिखने की तुलना में कितना तेज़ या धीमा है
    • इस तरह का spec-driven development AWS Kiro का मुख्य differentiator था: https://kiro.dev/docs/specs/
      आपने कहा कि दूसरे agents भी इस्तेमाल किए गए; जानना चाहूँगा कि कम तराशे हुए हिस्सों को दूसरे agents से polish करवाने वाले code review में आपको असर दिखा या नहीं। मेरे साथी इस पर काफ़ी भरोसा करते हैं, लेकिन मुझे अब भी शक है कि human reviewer के बिना इसका मूल्य कितना है
      “दूसरे AI से पूछो” वाला तरीका शायद applied computer science में thesis-antithesis-synthesis जैसा ज़्यादा फिट बैठता हो: https://en.wikipedia.org/wiki/Dialectic#Criticisms

  • चाहे इसे antirez ने लिखा हो, इतने feature set और इतने कम PR explanation के साथ 22,000 lines code review करना एक दुःस्वप्न जैसा लगता है
    इससे समझ आता है कि Postgres जैसे बड़े open source प्रोजेक्ट mailing list पर क्यों विकसित होते हैं। बीच के design decisions पर community से चर्चा करना, संबंधित features को अलग-अलग patch में बाँटना, धीरे-धीरे review करना, और releases के बीच अंतर रखना—यही तरीका है

    • code कुल मिलाकर comments सहित 5,000 lines का है
      sparse array 2,000 lines
      t_array command और upper-layer implementation 2,000 lines
      AOF/RDB code लगभग 500 lines
      बाकी tests, JSON command descriptions, और deps के नीचे TRE library है
    • Postgres और Redis प्रकृति, इतिहास, contribution style, और dev team—हर दृष्टि से बहुत अलग प्रोजेक्ट हैं
      असल में Redis की ज़्यादातर मुख्य features लेखक ने लगभग अकेले ही बनाई हैं
      और reviewers इस काम को अच्छी तरह जानते भी हैं और उन्हें ठीक से भुगतान भी मिलता है

  • top-tier AI के साथ मेरा अनुभव भी लगभग ऐसा ही रहा है। यह मानव बुद्धि और रचनात्मकता का विकल्प बनने से बहुत दूर है, लेकिन collaborator के रूप में बेहद उपयोगी है

    • मैं अक्सर कहता हूँ कि AI वही rubber duck programming duck है जिसकी मुझे हमेशा चाह थी
    • कुछ प्रोजेक्ट ऐसे हैं जिनमें मैं लगभग code देखे बिना development करता हूँ। concepts, algorithms, और ideas मेरे पास रहते हैं; मैं सवाल और hints देता हूँ; और खासकर product direction का मालिक मैं होता हूँ
      लेकिन Redis अभी वहाँ नहीं पहुँचा है। जिस दिन server software में यह संभव हो जाएगा, उस दिन आज का development तरीका खत्म हो जाएगा
      features, fixes, और अनुभव का accumulation अब भी मूल्यवान रहेगा, इसलिए projects और repositories बने रहेंगे, लेकिन programmer की भूमिका बहुत हद तक वैसी हो जाएगी जैसी Linus ने kernel में निभाई है
      DeepSeek v4 inference engine जैसे कुछ प्रोजेक्ट्स में यह तरीका पहले से अपनाया जा रहा है

  • array/regex रोमांचक लगते हैं, और LLM से अपनी क्षमता बढ़ाने का अनुभव भी बहुत दिलचस्प है। कई लोग अलग-अलग projects में चुपचाप ऐसे ही प्रयोग कर रहे हैं
    सिर्फ़ vibe coding और उसके खिलाफ़ प्रतिक्रिया से इस तरह के काम करने के तरीके की ठीक से व्याख्या नहीं होती

    • मैं agents के इस इस्तेमाल को बिल्कुल भी vibe coding नहीं मानता। इसमें बहुत गहरी भागीदारी है, और हर चीज़ verify, confirm, और review की जाती है
    • “vibe coding” की समस्या यह है कि यह term गढ़ने वाले व्यक्ति ने इसकी बहुत specific definition दी थी। यानी code देखे बिना, सिर्फ़ “feel” के आधार पर software बनाना
      लेकिन जल्द ही लोग AI-assisted coding के लगभग हर रूप के लिए यह शब्द इस्तेमाल करने लगे, और उसका मूल अर्थ तेज़ी से मिट गया

  • संक्षेप में कहें तो अब Redis पर भरोसा नहीं किया जा सकता
    LLM-रहित fork कौन बनाएगा?

  • बताए गए कुछ use cases क्या ZSET से भी नहीं किए जा सकते? performance वाली बात समझता हूँ, लेकिन जैसे array चुनिंदा रूप से sparse representation इस्तेमाल करता है, वैसे dense values के लिए ZSET storage format को चुनिंदा रूप से optimize किया जाता तो शायद नई API surface के बिना भी यह हो सकता था
    regex component दिलचस्प है, लेकिन जैसा यहाँ भी कहा गया है, यह array data structure से orthogonal feature लगता है। यानी इसे दूसरी structures में भी इस्तेमाल किया जा सकता है। क्या यह Lua scripting के लिए ज़्यादा उपयुक्त नहीं होता? अगर Lua performance समस्या है, तो शायद OP को abstract करने का कोई तरीका हो सकता है ताकि उसे उन commands के ऊपर compose किया जा सके जो value ranges लौटाती हैं
    मैं मानता हूँ कि Antirez इस क्षेत्र के विशेषज्ञ हैं, लेकिन इस नए feature set के कुछ हिस्से मुझे LLM-driven development में अक्सर दिखने वाले हल जैसे लगते हैं: मौजूदा features को सुधारने की बजाय नए features बनाना, जबकि वे दूसरे features के साथ मिलकर बेहतर काम कर सकते थे, और इस तरह functionality को ज़रूरत से ज़्यादा जटिल बना देना

    • दुर्भाग्य से ऐसा नहीं है। sorted sets इस spectrum के लगभग दूसरी छोर पर हैं। semantics के लिहाज़ से वे साफ़-सुथरे हैं, लेकिन skip list और array के संयोजन की वजह से बहुत wasteful हैं
      और अगर internal representation array नहीं है, तो range queries और ring buffers उतने efficient और compact तरीके से काम नहीं कर सकते जितना यहाँ चाहिए
      सिद्धांततः आप किसी भी चीज़ से कुछ भी कर सकते हैं, लेकिन हर API क्या कर सकती है, इसे अलग रखना पड़ता है ताकि use cases के अनुसार सबसे अच्छा internal implementation दिया जा सके

  • antirez से एक सवाल है। क्या आपने अंतिम code के लिए लगभग one-shot generation का प्रयोग करके देखा? क्या GEPA से वहाँ तक पहुँचना संभव है, या prompting/steering के तरीकों से कुछ सीखने लायक बात है जिससे मनचाहा result निकले?
    या फिर निष्कर्ष यह है कि model providers को training data साफ़ करना चाहिए

  • लगता है Salvatore Automatic Programming/Coding शब्द को लोकप्रिय बनाना चाहते हैं। (https://antirez.com/news/159)

    • https://en.wikipedia.org/wiki/Automatic_programming computer science में पहले से मान्य term है, जो किसी भी ऐसे mechanism को दर्शाती है जिसमें उच्च abstraction स्तर के वर्णन से code अपने-आप generate होता है
      बेशक LLM इस मायने में बहुत असामान्य हैं कि वे non-deterministic हैं और उनकी range चौंका देने वाली तरह से व्यापक है, लेकिन इससे यह term उन पर लागू होना बंद नहीं हो जाती
    • मैं भी धीरे-धीरे उसी चीज़ का वर्णन करने के लिए कम शब्द इस्तेमाल करने लगा हूँ। समय के साथ हम “उस” तरह का काम ज़्यादा बार करने लगेंगे
      फिर भी, term को auto-code तक छोटा कर देना मददगार हो सकता है

  • बहुत कुशल डेवलपर्स आजकल AI के साथ कैसे interact कर रहे हैं, यह देखना हमेशा दिलचस्प होता है
    @antirez: प्रोजेक्ट के बाद के चरण में, दिखने में अलग लगने वाली regex functionality जोड़ना थोड़ा अजीब लगा। क्या आप उस निर्णय के आधार को थोड़ा और समझा सकते हैं?

    • जब मुझे समझ आया कि arrays text files के लिए बहुत अच्छी तरह फिट बैठती हैं, तो मैंने पाया कि जितने भी use cases दिमाग में आ रहे थे, वे आखिरकार file में grep की ज़रूरत पर आकर रुक जाते थे
      तब मैंने सोचा कि files में AROP के बराबर क्या होगा, और जवाब था ARGREP
      इसके बाद, use case के हिसाब से सबसे अच्छा tool इस्तेमाल किया जा सके, इसलिए मैंने fast exact match और regex match दोनों डाले
      फिर मुझे पता चला कि OR से जुड़े कई strings के लिए, अगर regex को अच्छी तरह optimize किया जाए तो वह और तेज़ हो सकता है, इसलिए मैंने TRE को थोड़ा specialize किया