सिर्फ SQL में लागू किया गया Advent of Code 2024

 (databasearchitects.blogspot.com)
2 पॉइंट द्वारा GN⁺ 2025-01-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Advent of Code 2024 की सभी समस्याएँ सिर्फ SQL से हल की जा सकती थीं, और मुख्य बात यह है कि SQL सामान्य puzzle solving से अलग तरह की सोच अपनाने को मजबूर करता है
  • छोटे पैमाने के field traversal में input parsing से लेकर recursive query आधारित search और aggregation तक SQL के भीतर अपेक्षाकृत स्वाभाविक रूप से किया जा सकता है
  • Day 16 जैसी समस्याओं में, जहाँ state बहुत बढ़ जाती है, वहाँ अभिव्यक्ति से ज़्यादा evaluation cost समस्या थी, और वास्तविक input पर यह इतनी अक्षम हो गई कि 200GB से अधिक memory की जरूरत पड़ी
  • Day 23 की maximum clique समस्या Bron-Kerbosch algorithm के साथ अच्छी तरह मेल खाती है, लेकिन कई sets को संभालने वाली इसकी संरचना recursive SQL के single-set passing model से टकराती है
  • SQL में complex algorithms लिखना संभव है, लेकिन recursive execution के दौरान state updates और अधिक समृद्ध state manipulation होने पर database के भीतर execution अधिक व्यावहारिक होगा

सिर्फ SQL से Advent of Code 2024 हल करना

  • Advent of Code 2024 को सिर्फ SQL से हल किया गया, और सभी समस्याएँ केवल SQL के माध्यम से सुलझाई जा सकीं
  • पूरा समाधान GitHub repository में सार्वजनिक है
  • इसने समस्याओं को अलग तरीके से सोचने पर मजबूर किया, और कई मामलों में SQL उम्मीद से ज़्यादा आरामदायक tool साबित हुआ

Day 11: छोटे traversal problems में अच्छी तरह फिट होने वाला SQL

  • Day 11 का पूरा समाधान, puzzle input सहित, एक ही SQL में बना है
  • input processing में string को चरणबद्ध तरीके से table structure में बदला जाता है
    • puzzle input को string के रूप में रखा जाता है
    • input को अलग-अलग lines में विभाजित किया जाता है
    • हर character को coordinates और value में बदलकर 2D array जैसी table बनाई जाती है
  • algorithm वाला हिस्सा अपेक्षाकृत छोटा रहता है
    • recursive query से field को traverse किया जाता है
    • traversal result से puzzle का answer निकाला जाता है
  • ऐसे छोटे पैमाने के traversal में SQL काफी अच्छी तरह काम करता है

Day 16: recursive SQL में state को बनाए रखने की लागत

  • Day 16 में Day 11 की तरह field traversal किया जाता है और हर visited point के लिए minimum traversal distance निकाली जाती है
  • इसे SQL में व्यक्त करना आसान है, लेकिन evaluation process काफी wasteful है
  • वास्तविक puzzle input में field बड़ा होने पर recursive query बहुत सारे states बनाकर उन्हें बनाए रखती है
    • वास्तव में जरूरत सिर्फ recursive query की last iteration result की होती है
    • फिर भी अधिकांश calculated tuples को सुरक्षित रखा जाता है
  • इसी वजह से इस query को चलाने के लिए 200GB से अधिक memory की जरूरत पड़ती है
  • recursive execution के दौरान iteration semantic का उपयोग करने से अत्यधिक memory usage कम किया जा सकता है
    • Umbra यह कर सकता है
    • Postgres और DuckDB इसे support नहीं करते
    • इसलिए इस feature का उपयोग समाधान में नहीं किया गया

Day 23: कई sets की मांग करने वाले algorithm की सीमाएँ

  • Day 23 sparse graph में maximum clique खोजने की समस्या थी
  • इस समस्या को Bron-Kerbosch algorithm से उचित रूप से हल किया जा सकता है
  • लेकिन यह algorithm कई sets को बनाए रखना चाहता है, जबकि recursive SQL केवल एक single set को pass करता है
  • implementation संभव था, लेकिन SQL expression काफी जटिल हो गया और परिणामस्वरूप code भी साफ-सुथरे रूप में नहीं रहा

recursive SQL में और क्या चाहिए

  • complex algorithms को भी SQL में लिखा जा सकता है, और कई बार SQL code उम्मीद से अधिक पढ़ने-लिखने में आसान था
  • यदि recursive SQL में state update mechanism हो, तो यह अधिक efficient और उपयोग में आसान हो सकता है
  • recursion में अधिक complex control flow को support करने के लिए trampoline mechanism पर शोध चल रहा है, और यह approach भी उपयोगी है
  • इसके साथ अधिक complex state manipulation mechanisms को भी देखने की जरूरत है
  • थोड़ी-सी अतिरिक्त functionality के साथ SQL database के भीतर सीधे complex algorithms चलाने के लिए एक मजबूत विकल्प बन सकता है

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

1 टिप्पणियां

 
GN⁺ 2025-01-03
Hacker News की राय

  • ऐसा कर पाना सच में सिर्फ किसी असाधारण व्यक्ति के बस की बात है। यह शुद्ध कला है, और programming दुनिया में ऐसी चीजें पर्याप्त नहीं हैं

    • Thomas दुनिया के सर्वश्रेष्ठ database systems researchers में से एक हैं, और वाकई कमाल के व्यक्ति हैं

  • इस शीर्षक को देखकर मेरी प्रतिक्रिया वैसी ही थी जैसी Taco Bell के नए मेन्यू को देखकर होती है। इच्छा, शर्म और मानवीय रचनात्मकता के प्रति प्रशंसा का एक अजीब मिश्रण

    • मैंने databases के साथ काफी काम किया है और तरह-तरह की चीजें देखी हैं, लेकिन अगर आपको पता है कि आप क्या कर रहे हैं तो यह उतना बुरा नहीं है जितना लगता है। ज़्यादातर relational database management systems recursive common table expressions को support करते हैं, तो यह थोड़े सैडिस्टिक syntax में Prolog लिखने जैसा लगता है
      Advent of Code जैसी समस्याओं में शायद input parsing सबसे कठिन हिस्सा होगा
    • इस लेख के GitHub repository में मौजूद solutions भी Taco Bell के नए chicken nuggets जितने ही चौंकाने वाले हैं
    • Taco Bell में जो चीज़ बर्दाश्त करना मुश्किल है, वह नकली nacho cheese है। hard taco में आने वाला साधारण grated cheese भले सबसे अच्छा न हो, फिर भी ठीक है, लेकिन Velveeta वाली चीज़ को जबरन निगलने के लिए काफी आत्म-संयम चाहिए
      शायद tablet interface में गहराई से देखने पर ingredients पता चल जाएं, लेकिन अभी तो यह किस्मत का खेल लगता है। गंभीरता से कहें तो https://www.amazon.com/Joe-Celkos-SQL-Smarties-Programming-d... SQL craftsmanship की चरम सीमा सीखने के लिए शानदार पाठ है
    • समझ नहीं आता कि कोई मानवीय रचनात्मकता पर शर्म और इच्छा से क्यों प्रतिक्रिया देगा। यह आपकी तरफ की समस्या है या Taco Bell की कोई खास समस्या, यह भी स्पष्ट नहीं है
      लगता है HN पूरा ही मानवीय रचनात्मकता के बारे में है, और पता नहीं क्या उसे भी Taco Bell मेन्यू देखने वाली भावना से ही लेना चाहिए

  • अच्छा बनाया गया है। शुरुआत में यह पागलपन जैसा दिखता है, लेकिन मुझे लगता है कि बड़ा SQL complexity को संभालने के सबसे अच्छे तरीकों में से एक है
    complexity इसलिए है क्योंकि समस्या खुद complex है। SQL standard है, concise है, बहुत तेज़ है, वास्तव में testable है, और logical language है। हर कोई इसे तुरंत maintain नहीं कर सकता, लेकिन Java में बहुत सारी lines और functions लिखने पर भी यही बात लागू होती है
    SQL की गहराई भी अच्छी है। 40 से अधिक वर्षों से इसने data world को संभाला है, इसलिए लोगों का niche features मांगना स्वाभाविक है। Oracle का model clause मेरी पसंदीदा features में से एक है, क्योंकि इससे multidimensional arrays implement किए जा सकते हैं, और मेरे एक दोस्त ने इससे Conway’s Game of Life को उम्मीद से कहीं कम lines में implement किया था

    • intern के समय मुझे एक math PhD द्वारा लिखी गई stored procedure की performance optimize करने का “मज़ेदार” काम मिला था। print करने पर वह 6 pages से ज्यादा थी, चलने में 30 minutes से अधिक लगते थे, billing system में इस्तेमाल होती थी, और tests भी नहीं थे
      आखिर में उसे native code में दोबारा लिखकर 1 second से कम कर दिया, और ज़्यादातर काम यह साबित करने में था कि वही result मिलता है, साथ ही test cases लिखने और document करने में ताकि अगले व्यक्ति को वही तकलीफ न झेलनी पड़े। उसके बाद से मैं आम तौर पर बहुत सारी business logic SQL में डालने से बचता हूं
    • SQL में दक्ष लोग पर्याप्त संख्या में हों, और सच में तभी, बड़ा SQL complexity को संभालने का अच्छा तरीका हो सकता है। खराब SQL लिखना बहुत आसान है, और सैकड़ों procedures, views और functions में फैली हजारों lines की खराब SQL को सुलझाना मुश्किल है
    • मैं समझता हूं कि बड़ा SQL complexity को संभालने में अच्छा लग सकता है, लेकिन बड़ी SQL queries debug करना बहुत opaque हो सकता है। pl/pgsql जैसी चीजें मदद करती हैं, लेकिन फिर वह धीरे-धीरे सामान्य programming language जैसी बनने लगती है
    • शुरुआत में यह पागलपन जैसा दिखता है, और आगे सोचने पर भी complexity को SQL में रखना अब भी पागलपन जैसा ही लगता है
      व्यक्तिगत रूप से मेरा मानना है कि complex चीजों को manual और automatic दोनों तरीकों से आसानी से test किया जा सकना चाहिए। SQL में manual testing आसान है, लेकिन automatic testing programming language code की तुलना में ज्यादा कठिन है। spaghetti code के ढेर को कम घना करके हिस्सों में तो निपटा सकते हैं, लेकिन उलझी हुई SQL spaghetti से कैसे निपटें, यह समझना मुश्किल है
      मैं इस बात से भी पूरी तरह सहमत नहीं हूं कि lines जितनी ज्यादा होंगी, bug risk उतना बढ़ेगा। क्योंकि हर line बराबर नहीं होती। 400-character की एक SQL line में समस्या आंख से ढूंढना 400 lines के Java code से ज्यादा कठिन होने की संभावना है, और मैं यह Java को कई वजहों से नापसंद करने के बावजूद कह रहा हूं

  • अगर आपको इस तरह की विलासी चुनौती पसंद है, तो मैंने इस साल Advent of Code Google Sheets में किया
    मैं सिर्फ day 6 तक गया, और हर दिन दोनों stars भी नहीं लिए। मुझे काफी यकीन है कि day 7 का solution सही है, लेकिन लंबे input पर per-cell character limit से टकरा गया
    आनंद लें। बस mobile पर न खोलना बेहतर है। कुछ sheets app को crash कर देती हैं
    https://docs.google.com/spreadsheets/d/10FY-89y19tnRM_EAAnCd...

    • अभी phone पर हूं इसलिए खोल नहीं सकता, लेकिन जानना चाहूंगा कि क्या इसमें Google Apps Script इस्तेमाल किया गया है। अगर हां, तो वह अतिरिक्त ताकत पाने का तरीका हो सकता है

  • अपने करियर में किसी भी दूसरी तरह के code से ज़्यादा SQL लिखा है। पिछले 5 सालों में कम लिखा, इसलिए शायद बहुत कुछ भूल गया होऊंगा, लेकिन पहले सच में इसका मज़ा लेता था
    जब आप दोहराव वाले तरीके से सोचना बंद करके set operations में सोचना शुरू करते हैं, तो यह काफ़ी स्वाभाविक और शक्तिशाली हो जाता है

    • साल दर साल मैं ज़्यादा ज़िम्मेदारी relational database management system पर डालता जा रहा हूं। अब ज़्यादातर चीज़ों को ETL, SQL, schema के नज़रिए से देखता हूं। technology को business में लागू करने से जुड़ी लगभग हर बातचीत इन्हीं शब्दों में कही जा सकती थी
      अगर schema अच्छी तरह बना हो और business stakeholders के नज़रिए से मेल खाता हो, तो SQL query से define किया गया business logic काफ़ी सहज हो सकता है
      code, framework, ORM, “best practices”, patterns वगैरह आखिरकार ध्यान भटकाने वाली चीज़ें हैं। data को database में डालने और निकालने के लाखों तरीके हैं, और bits को इधर-उधर ले जाना अपने-आप में कम value वाला काम है। बहुत से बढ़ा-चढ़ाकर बनाए गए software solutions ऐसे हैं जिनकी जगह एक साधारण merge statement या CSV import काम कर जाता
      SQL को लेकर बहुत-सी गलतफहमियां और नकारात्मक भावनाएं इसलिए पैदा होती हैं क्योंकि लोगों को गंदे schemas से निपटना पड़ता है। भाषा खुद सच में domain-specific है। अगर पहली जगह पर ऐसी queries लिखने की ज़रूरत ही न पड़े, तो भयानक nested queries और उनसे होने वाली SQL syntax की पीड़ा पर इतनी शिकायत न होती। tuples और relations को business जिस तरह आम तौर पर बात करता है उसके अनुरूप बना दें, तो समय के साथ इन चीज़ों से कम लड़ना पड़ता है। कई बार schema को शुरुआत से refactor नहीं कर सकते, लेकिन खराब schema के आसपास replicas या views रखकर उन्हें नए development और refactoring का target बनाया जा सकता है
    • SQL को बहुत इस्तेमाल करने के बाद एक कदम पीछे हटकर सोचें तो इसकी सुंदरता दिखती है। ऐसा लगता है, “रुको, अभी जो किया वह तो बस pure logic था। library dependency resolution नहीं, concurrency issues नहीं, mutability issues नहीं, बस logic था”
      बेशक SQL में खामियां हैं, और testability जैसी गंभीर खामियां भी हैं। फिर भी आखिर में अच्छा लगेगा अगर सारी programming ऐसी ही हो। अंदर कैसे करना है यह computer तय करे, और इंसान logic पर ध्यान दे
      एक कदम और आगे जाने के लिए Prolog को सरसरी तौर पर पढ़ने की कोशिश की, लेकिन अभी तक सफल नहीं हुआ। मकसद यह भी था कि SQL में बहुत ज़्यादा फंसा न रहूं, इसलिए उसका कुछ हिस्सा भूलने की कोशिश करूं। शायद SQL और Prolog के बीच कहीं programming का भविष्य हो
    • अच्छा होता अगर सिर्फ set operations में सोचा जा सकता, लेकिन असल में तेज़ queries लिखने और कौन-से indexes चाहिए यह जानने के लिए अब भी imperative और iterative thinking करनी पड़ती है
      अगर केवल set operations के नज़रिए से सोचें, तो 5 milliseconds के बजाय 5 minutes लेने वाली query बनना आसान है। दिमाग़ में प्रक्रिया लगभग हमेशा दोहराती रहती है: “किस table से शुरू करना है, कौन-सी rows किस order में देखनी हैं, किससे और किन conditions पर join करना है, aggregate कैसे करना है।” यह set operations से ज़्यादा loops और aggregation के mental model जैसा लगने लगता है
    • अच्छे database schema design के theory, practice और technical aspects—तीनों में महारत हासिल करना ही यह देखने की सबसे असली परीक्षा है कि किसी ने system design समझा है या नहीं
      बहुत लोग हर तरह की बेकार जगहों पर छलांग लगा देते हैं, लेकिन software engineering का बड़ा हिस्सा सही data को सही format में डालने और उसे भरोसेमंद तरीके से move करने का काम है
      हाल ही में एक जटिल distributed codebase को बड़े पैमाने पर refactor किया, और असल “काम” के तौर पर गिनने लायक लगभग सिर्फ schema redesign था। बाकी बहुत समय की coding थी, लेकिन सच में वह implementation के ज़्यादा करीब थी
      SQL के अलावा schema define करने के तरीके हैं, लेकिन असली systems engineering सीखने के लिए SQL एक perfect तरीका है
    • SQL तब जाकर सही से समझ में आया जब original paper पढ़ा और इसे sets के नज़रिए से समझाया गया

  • SQL बहुत ज़्यादा इस्तेमाल करता हूं, और stream processing application के business logic का काफ़ी हिस्सा SQL में implement कर रहा हूं। खासकर data को computation तक ले जाने के बजाय computation को data के पास लाने का तरीका सच में पसंद है
    लेकिन अक्सर ऐसे developers भी मिलते हैं जिन्हें यह idea पसंद नहीं है। वे भारी input/output cost उठाकर सारा data backend में ले जाना चाहते हैं, फिर computation को “real” programming language में express करना चाहते हैं
    SQL की concept अच्छी है, लेकिन SQL भाषा को समस्या मानता हूं। इसमें बहुत awkward हिस्से हैं, और करीब 40 साल तक competition न रहा हो तो यह अजीब भी नहीं है। दिमाग़ में program model ठीक है, लेकिन elegance देखने के लिए syntax से आगे जाकर उस program को देखना पड़ता है जिसका आप सच में इस्तेमाल कर रहे हैं
    मेरे हिसाब से ज़रूरत एक ठीक-ठाक programming language की है, जो मौजूदा databases (Postgres, MSSQL) को target करके बनाई गई हो और SQL dialects में compile होती हो। candidates दिखते हैं, लेकिन वे या तो PreQL जैसे किसी खास दायरे में बंधे हैं जो data mutation allow नहीं करता, या किसी दूसरे database से coupled हैं
    खुद बनाने का मन होता है, लेकिन काम बहुत ज़्यादा है, adoption तक बहुत लंबा रास्ता है, success की कोई guarantee नहीं, और कोई revenue model भी दिमाग़ में नहीं आता
    popular backend languages बड़ी कंपनियों ने बनाई हैं, लेकिन SQL में coding करना तब तक कमतर माना जाता रहेगा जब तक बेहतर language नहीं आती, और बेहतर language तब तक नहीं आएगी जब तक यह ज़्यादा popular नहीं होता—ऐसा लगता है कि यह catch-22 में फंसा है

    • SQL में बहुत-सी बातें बिलकुल सही हैं, लेकिन किनारों पर कुछ हिस्से खुरदरे हैं
      common table expressions और window functions ने बड़ा फर्क डाला, और खासकर window functions दिमाग़ थोड़ा घुमा देते हैं लेकिन मुश्किल कामों को थोड़ा आसान बना देते हैं
      BigQuery इस्तेमाल कर रहा हूं; यह structs और arrays support करता है, और हाल ही में arrays को group करना संभव हुआ है, लेकिन अभी equality check जैसी चीज़ें नहीं हैं
      BigQuery धीरे-धीरे aggregate user-defined functions, ANY TYPE parameters का इस्तेमाल करने वाले polymorphic user-defined functions जैसी syntactic sugar जोड़ रहा है। इससे reusable logic को साफ़ functions में ज़्यादा डालने का मौका मिलता है, लेकिन निजी तौर पर चाहता हूं कि temporary functions common table expressions की तरह declare और scoped हों, ताकि DBT जैसे उन tools के साथ बेहतर integrate हों जो सब कुछ एक statement में रखना चाहते हैं
      productivity सबसे ज़्यादा बढ़ाने वाला एक feature चुनना हो तो वह होगा JOIN USING में null behavior specify करने की सुविधा। join में foo.bar IS NOT DISTINCT FROM bar.bar को खुलकर लिखना intuitive नहीं है और बदसूरत लगता है। USING (bar RESPECT NULLS) जैसा कुछ हो तो बहुत बेहतर लगेगा
    • ठीक-ठीक कहना मुश्किल है, लेकिन लगता है बहुत लोग इसे दो operating modes की तरह देखते हैं। solution जितना ज़्यादा monolithic, enterprise जैसा और dedicated database management system के करीब होता है, उतना ज़्यादा tendency होती है कि indexes और triggers से आगे की complex चीज़ें भी database side पर रखी जाएं
      इसके उलट, microservices-style architecture में, जहां छोटी services अपनी-अपनी database own करती हैं और उनमें से सिर्फ आधी relational databases होती हैं, लोग database के अंदर complex code कम रखना चाहते हैं। वजह यह है कि वे अक्सर single instance या cluster से इधर-उधर move करते हैं, और आम तौर पर केवल relatively simple data dumps ले जाते हैं या Theseus के जहाज़ की तरह नए replicas जोड़ते रहते हैं
    • PRQL शानदार है। एक और मिलता-जुलता competitor है, लेकिन उसका नाम अभी याद नहीं आ रहा

  • इसे पूरी तरह SQL में कर पाना वाकई प्रभावशाली है, लेकिन असली cracked engineer energy की निशानी तो 10 साल से चलती आ रही Blogspot साइट लगती है
    ठीक-ठीक समझाना मुश्किल है, लेकिन इसमें “niche field के माहिर” वाला एहसास बहुत मजबूत है। लेखकों को न भी जानते हों, तो भी “database architects” नाम की Blogspot साइट 10 साल तक बनाए रखने वाले कुछ लोगों को सही community में शायद परिचय की जरूरत नहीं पड़ेगी

  • संदर्भ के लिए, मैंने कुछ दिनों तक EdgeQL में Advent of Code आज़माया, और यह काफी दिलचस्प अनुभव था
    मैंने कुछ ट्वीट किए थे, और लगता है इसे ब्लॉग पोस्ट के रूप में लिखना चाहिए
    https://x.com/1st1/status/1864069589245858083
    SQL से तुलना: https://x.com/1st1/status/1864412869108092997

  • पूरी तरह भयावह। फिर भी बढ़िया किया

  • जिन्हें पता नहीं, उनके लिए बता दूं कि लेखक दुनिया के सबसे बेहतरीन database researchers में से एक हैं

    • Thomas Neumann ने बस Thomas Neumann जैसा काम किया है