PRQL: पाइपलाइन-आधारित रिलेशनल क्वेरी भाषा

 (github.com/PRQL)
4 पॉइंट द्वारा GN⁺ 2023-07-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PRQL डेटा को transform करने के लिए एक आधुनिक भाषा है, जिसका लक्ष्य SQL की तरह पढ़ने में आसान, स्पष्ट और declarative SQL वैकल्पिक भाषा बनना है
  • Query logical pipeline के रूप में बनी होती है, जहाँ transformation steps पिछले result को आगे लेकर चलती हैं, और variables व functions जैसी abstractions को support करती है
  • SQL इस्तेमाल करने वाले सभी databases के साथ उपयोग के लिए PRQL को SQL में compile किया जाता है
  • भाषा के उदाहरण from, filter, derive, group, aggregate, sort, take जैसे transformations का उपयोग करते हैं, और filter SQL के WHERE और HAVING की भूमिका को replace करता है
  • Syntax features में स्पष्ट date notation, coalesce, दूसरे variables को reference करने वाले variables, Python जैसी F-string, SQL को escape hatch के रूप में इस्तेमाल करने वाली S-string, descending sort notation, और range expressions शामिल हैं
  • Browser में प्रयोग के लिए PRQL Playground, भाषा documentation PRQL Book, और SQL comparison व examples देने वाली prql-lang.org उपलब्ध हैं
  • जून 2026 तक, इसे supported integrations या supported language bindings के जरिए इस्तेमाल किया जा सकता है, लेकिन कुछ bugs और missing features बाकी हैं, और non-technical teams के लिए deployment readiness का दायरा अभी काफी सरल queries तक सीमित है
  • Development focus नए resolver पर काम, priority bugs को हल करना, standard SQL queries के अधिकांश हिस्से के लिए उपयोग योग्य बनने हेतु बाकी feature gaps को बंद करना, और modules व multi-file projects के लिए experimental support जोड़ना है
  • Integration points के रूप में VS Code extension, Jupyter integration, QStudio integration, Jupyter magic, pyprql Docs, prqlc-js उपलब्ध हैं
  • Repository Rust में लिखे compiler prqlc और web content area web से बनी है; prqlc PRQL को SQL में compile करता है और CLI व कई language bindings शामिल करता है

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

1 टिप्पणियां

 
GN⁺ 2023-07-27
Hacker News की राय

  • वेबसाइट https://prql-lang.org/ के उदाहरण PRQL का सबसे बड़ा फायदा लगते हैं, खासकर जनरेट होने वाला SQL साफ और सहज है, मानो किसी ने सीधे हाथ से लिखा हो
    10~15 साल पहले Mongo, Riak, Influx जैसे नए डेटाबेस बनाए जाते थे और ऐप डेवलपर्स को नए प्रोजेक्ट में उन्हें अपनाने के लिए मनाया जाता था, लेकिन आजकल EdgeDB, TimescaleDB, PRQL जैसे Postgres पर add-on या query preprocessor जोड़ने वाले conservative विकल्प बढ़ गए हैं, इसलिए इन्हें अपनाना कहीं आसान है
    Edge की schema और migration सुविधाएं भी अच्छी हैं, लेकिन PRQL syntax ज्यादा सहज है। TypeScript की map/filter chain, Rust iterators, Ruby enumerable, Java stream, .NET LINQ, और कई भाषाओं के Rx की तरह application code में पहले से ही data transformation pipelines बहुत हैं, इसलिए concept बेहद परिचित लगता है। PRQL से अच्छा SQL निकालकर save करना, बाद में check करना, execution plan देखना, और जहां जरूरत हो वहां index जोड़ पाना शानदार है

    • काफी अच्छा दिखता है, लेकिन SQL से बस बहुत मामूली अलग लगता है। अगर Ruby “Python में transpile होने वाला ज्यादा friendly syntax” होती, तो लगता है लोग जो पहले सीखे होते वही इस्तेमाल करते और दूसरा सीखने की खास जरूरत नहीं समझते
      उदाहरण SQL को मनमाने ढंग से ज्यादा verbose दिखाते हैं। कई लाइनों में बंटे SELECT ... FROM ... ORDER BY ... LIMIT ... की तुलना में from employees / select {id, first_name, age} / sort age / take 10 बेहतर दिखता है, लेकिन असली SQL भी select id, first_name, age from employees order by age limit 10 की तरह लिखा जा सकता है, और braces न होने के बदले order by और sort का फर्क ही है, यानी यह करीब-करीब एक-दो अक्षरों का फर्क है
    • ठीक से समझ नहीं आ रहा। उदाहरण SQL की तुलना में काफी कम readable लगते हैं, और यह क्यों इस्तेमाल करना चाहिए समझ नहीं आता
      query sections का order बदल पाना वह चीज है जिसके बारे में सभी SQL से शिकायत करते हैं, लेकिन उसके बदले कई तरह के brackets, colons और दूसरी syntax बिना वजह आ जाती है, और ऐसा भी नहीं लगता कि यह SQL से कुछ खास ऐसा कर पाता है जो SQL पहले से नहीं कर सकता। जानना चाहता हूं कि इसका appeal point क्या है

  • हाल ही में ClickHouse में PRQL support merge किया गया: https://github.com/ClickHouse/ClickHouse/pull/50686
    अभी यह प्रयोग जैसा ही है, और यह सच में usable या useful होगा या नहीं, पक्का नहीं है। Rust से जुड़ी थोड़ी चिंता भी है: https://github.com/ClickHouse/ClickHouse/issues/52053#issuecomment-1643805521

    • बढ़िया। तो क्या इसका मतलब है कि इसे clickhouse-local में भी इस्तेमाल किया जा सकेगा?

  • उम्मीद है PRQL बहुत बढ़े और Postgres की first-class supported language बन जाए। relational algebra सुंदर है, लेकिन SQL दशकों पहले replace हो जाना चाहिए था—एक ढीला-ढाला first-pass design है
    Codd को भी SQL से शिकायत थी। उन्होंने जो invent किया वह कमाल था, लेकिन उसके बाद से हमने programming language design के बारे में बहुत कुछ सीखा है

    • लोग relational algebra और SQL को अक्सर इसलिए जोड़ते हैं क्योंकि उन्होंने दोनों साथ में सीखे होते हैं। लेकिन SQL relational language के रूप में बहुत खराब है, और relation के unordered set होने के core concept को ORDER BY से तोड़ने जैसी कई जगहों पर भटक जाता है
      यह समस्या subquery में wrap करने पर relation की ordering गायब हो जाने जैसे तरीके से सामने आती है, जो काफी unexpected है। PRQL का data model relational model से बहुत मिलता-जुलता है, और बड़ा फर्क यह है कि relation को tuple array के रूप में define किया गया है, इसलिए उसका order होता है। उम्मीद है PRQL “relational language Mk II” के रूप में जाना जाएगा
    • आप जो चाहते थे उससे बिल्कुल वही नहीं है, लेकिन DuckDB में PRQL extension [1] और Postgres extension [2] दोनों हैं, इसलिए लगता है वहां Postgres database को PRQL से query किया जा सकता है
      DBeaver plugin [3] भी है, हालांकि documentation और usability simplification की और जरूरत है, लेकिन इससे भी Postgres को PRQL से query कर पाने की संभावना है। अंत में pyprql [4] का इस्तेमाल करके Jupyter notebook में Postgres query किया जा सकता है
      [1]: https://github.com/ywelsch/duckdb-prql
      [2]: https://duckdb.org/docs/extensions/postgres_scanner.html
      [3]: https://github.com/PRQL/prql/issues/1643
      [4]: https://github.com/PRQL/pyprql
      संदर्भ के लिए, मैं PRQL contributor हूं
    • relational algebra अब भी शानदार है। उस सुंदर idea को यकीन न होने लायक गड़बड़ बनाने वाली चीज SQL है
    • 20 साल पहले teenage में पहली बार SQL सीखा था, और याद है कि तब भी भाषा अजीब और सचमुच उलटी लगती थी
      उस समय लगा था कि शायद मैं इतना नहीं जानता कि समझ सकूं कि ऐसा क्यों होना चाहिए, लेकिन अब जानता हूं कि इसकी कोई वजह नहीं है। SQL natural language जैसा बन गया है, इसलिए बात का मतलब न भी बने तो आप argue नहीं कर सकते, बस बोलना पड़ता है। लेकिन SQL natural language नहीं है और इसे बेहतर बनाया जा सकता है
    • क्या retrieve करना है यह चुनने के बाद ही source चुनने का तरीका मुझे कभी पसंद नहीं आया। यहां syntax format कहीं ज्यादा intuitive है

  • अगर SQL को लेकर मुख्य शिकायत यह है कि SELECT, FROM, WHERE का क्रम बदला नहीं जा सकता, तो 70 के दशक में डिज़ाइन की गई भाषा के हिसाब से यह काफ़ी ठीक है
    इसके उलट PRQL की syntax में काफ़ी मनमाना शोर लगता है। समझ नहीं आता कि join side:left p=positions (p.id==employees.employee_id) को LEFT JOIN positions AS p ON p.id = employees.employee_id से बेहतर क्यों माना जाए

    • SQL की असली समस्या यह है कि यह लिखने के बहुत सख्त तरीके में बंद है, और वह मेरे सोचने के flow से मेल नहीं खाता
      PRQL की तरह ऊपर से नीचे, जहाँ हर step पिछले step का transformation होता है, कहीं ज़्यादा समझ में आता है। SQL के लिए reference manual चाहिए, जबकि PRQL में ऐसा लगता है जैसे query से जो करवाना है वही सीधे लिख रहे हों। हालांकि PRQL की join syntax बहुत खराब है, और explicit left join जैसे keywords बनाए रखने चाहिए थे; aliases और join column shorthand भी बेहतर बनाए जा सकते थे
    • SQL को लेकर मेरी वास्तविक शिकायतें दो थीं, बाकी सब काफ़ी ठीक था
      पहली, उसी select के अंदर पहले चुने गए column को बाद में इस्तेमाल नहीं कर सकते। gnarly_calculation AS some_value के बाद some_value * 2 AS some_value_doubled जैसा नहीं लिख सकते, subquery में wrap करना पड़ता है। दूसरी, कुछ खास columns को छोड़कर बाकी सभी columns specify नहीं कर सकते। जब intermediate calculation को subquery से ऊपर लाना पड़े लेकिन final output में उसकी ज़रूरत न हो, तो * EXCEPT some_value जैसा नहीं कह सकते; सारे desired output columns गिनाने पड़ते हैं
    • शायद इसलिए कि मैं R और tidyverse paradigm से परिचित हूँ, कुल मिलाकर यह paradigm और syntax काफ़ी readable लगती है
      चुना गया example ऐसा हो सकता है जहाँ parentheses और commas काफ़ी मदद करते हों, लेकिन पूरी भाषा के context में यह इतना बुरा नहीं है। : लगातार keyword argument की तरह इस्तेमाल होता है, और = शायद alias के लिए इस्तेमाल होता है
    • क्योंकि अब join का type join operation का argument बन जाता है, और statement का पहला शब्द join है, इसलिए actual operation क्या है यह ज़्यादा स्पष्ट हो जाता है
      सामान्य function call के example में भी foo(bar) “bar to foo()” से बेहतर है
    • SQL की समस्या C-style variable declaration जैसी ही है। code को ज़ोर से पढ़ें तो यह विकल्पों से थोड़ा बेहतर लगता है, लेकिन व्यवहार में readability और parsing/processing में समस्या पैदा करता है

  • PRQL 0.9 कुछ घंटे पहले ही release हुआ है, तो timing अच्छी है। release notes यहाँ देख सकते हैं: https://github.com/PRQL/prql/releases/tag/0.9.0
    tuple syntax को [] से {} में बदलने वाला काफ़ी बड़ा breaking change है। शुरू में ये list जैसे दिखते थे, लेकिन समय के साथ समझ आया कि असल में ये tuple हैं। release notes के मुताबिक [] को खाली छोड़ने से जल्द ही array support शुरू किया जा सकता है। संदर्भ के लिए, मैं PRQL contributor हूँ

  • PRQL की सीमा यह है कि design के हिसाब से यह सिर्फ SELECT support करता है। data insert/update/delete करना हो तो फिर SQL पर लौटना पड़ता है
    टीम का data scientist PRQL में query दे सकता है, लेकिन उसे actual data pipeline में डालना हो तो SQL में translate करना पड़ेगा। कम से कम नई temporary table में insert करने जितनी सीमित functionality भी support हो तो अच्छा होगा। उदाहरण के लिए from tracks / filter artist == "Bob Marley" / save bob_marley_tmp जैसा form

    • मुझे नहीं लगता कि PRQL data changes support नहीं कर सकता। pipeline के अंत में आने वाले insert/update/delete operators रखे जा सकते हैं, और table name को argument बनाया जा सकता है
      UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' जैसे SQL को PRQL में from counters / filter startswith(name, 'prefix.') / derive { new_value = value + 1 } / select { name, new_value } / update counters की तरह लिखा जा सकता है
    • सही है, यहीं मेरी रुचि खत्म हो गई

  • यहाँ यह लेख छूट नहीं सकता: “I don't want to learn your garbage query language” [1]
    [1] https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-garbage-query-language.html

    • मुझे यह लेख बहुत पसंद है, और PRQL website पर भी इसे link किया गया है
      PRQL का लक्ष्य ऐसा बेहतरीन language बनना है जिसे integrate करना और जिसके ऊपर build करना आसान हो। हम N databases के लिए N languages नहीं बनाना चाहते। PRQL हमेशा open source रहेगा और कोई commercial product नहीं बनाएगा, इसलिए मुझे लगता है कि यह database-specific या product-specific languages की तुलना में कहीं ज़्यादा feasible है। मैं PRQL developer हूँ
    • सबसे अच्छा counterargument: https://www.scattered-thoughts.net/writing/against-sql/

  • पिछला Show HN: https://news.ycombinator.com/item?id=31897430
    “Show HN: PRQL 0.2 – a better SQL” को maximilianroos ने 27 जून 2022 को post किया था और उसे 378 points, 161 comments मिले थे
    जिस मूल post में पहली बार प्रस्ताव रखा गया था: https://news.ycombinator.com/item?id=30060784
    “PRQL – A proposal for a better SQL” को maximilianroos ने 24 जनवरी 2022 को post किया था और उसे 650 points, 295 comments मिले थे

  • Microsoft की KQL याद आती है: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

    • KQL शानदार है, इसलिए जब भी SQL लिखता हूँ तो इसकी कमी महसूस होती है
    • Azure इस्तेमाल करते हुए यही एकमात्र खुशी मिलती है

  • syntax उतनी महत्वपूर्ण नहीं है; असली बात यह है कि optimizer क्या करता है
    आज SQL की कई समस्याएँ पुराने बोझ जैसी दिखती हैं। पुराने engines modern syntax को ठीक से संभाल नहीं पाते थे, इसलिए बहुत से लोग पढ़ने में मुश्किल, जटिल और गहराई तक nested queries लिखने के आदी हो गए। उदाहरण के लिए, common table expressions (CTE) को देखते ही तुरंत materialize कर दिया जाता था, इसलिए SELECT FROM (SELECT FROM (SELECT FROM A JOIN (SELECT ) B ON A.x=B.x))) जैसी पुरानी शैली हर जगह दिखती थी
    engines में CTE handling बेहतर होने की वजह से WITH A AS (...), WITH B AS (...), WITH C AS (SELECT y FROM A) SELECT result FROM C WHERE ... जैसी समझने योग्य और composable queries लिखना लगातार आसान होता जा रहा है। modern window functions, SELECT * EXCEPT, और ज्यादा जटिल TOP X FOLLOWING जैसी capabilities जुड़ें तो SQL और सरल हो सकता है
    ऐसे माहौल में PRQL जैसे अलग syntax रूपों में छोटे सुधार बहुत बड़ा लाभ देते हैं, ऐसा मुझे नहीं लगता। इसे imperative जैसा दिखने वाली pipeline के रूप में फिर से लिखा जा सकता है, लेकिन optimizer उसके कुछ हिस्सों को हटा भी सकता है। यह सही है कि SQL में कुछ चीजें और बेहतर होनी चाहिए, लेकिन सतही/सिंटैक्स संबंधी अंतर के लिए कोई दमदार आधार मैंने अभी तक नहीं देखा है