Postgres का उपयोग करने के तरीके

 (github.com/Olshansk)
8 पॉइंट द्वारा GN⁺ 2024-12-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह रिपॉज़िटरी “Keep It Simple Stupid, just use postgres” दिशा के तहत, Postgres को विभिन्न उपयोगों में काम में लेने वाले टूल और उदाहरणों को एकत्र कर दिखाती है
  • यह सूची Amazing CTO के Postgres for Everything लेख और @cpursley के GitHub gist से प्रेरित है, और Postgres पर नए टूल व उपयोग के तरीके लगातार सामने आने की वजह से इसे बनाए रखा जाता है
  • इसका दायरा cron jobs, embeddable Postgres, message queues, analytics, GIS, audit logs, access control, search, time series, NoSQL, graph, HTTP, API, CDC, caching, testing, migration, performance tuning, monitoring, extension, UI, CLI, visualization, package management, security, और financial ledger तक फैला है
  • हर आइटम को Postgres extensions, libraries, API platforms, लेखों और tools के लिंक-केंद्रित रूप में व्यवस्थित किया गया है, और कुछ DuckDB, pgvector, PostGIS, PgBouncer, GraphQL, CDC जैसी विशिष्ट तकनीकों से जुड़े हैं
  • जो उपयोगकर्ता किसी खास code snippet, tool, या project को उदाहरण के रूप में जोड़ना चाहते हैं, उन्हें लिंक के साथ PR खोलना होगा और नया pull request template इस्तेमाल करना होगा

रिपॉज़िटरी का उद्देश्य और रखरखाव का तरीका

  • Postgres for Everything रिपॉज़िटरी का लक्ष्य यह दिखाना है कि Postgres को कई तरह के उपयोगों में कैसे इस्तेमाल किया जा सकता है
  • यह रिपॉज़िटरी निम्नलिखित स्रोतों से प्रेरित है
  • Postgres पर नए tools या नए उपयोग के तरीके लगातार आते रहते हैं, इसलिए इसे उन्हें ट्रैक करने की जगह के रूप में बनाए रखा जाता है
  • यदि आपके पास अन्य उदाहरण हैं, तो आप PR जमा कर सकते हैं
  • यदि आप code snippets, tools, या projects दिखाना चाहते हैं, तो लिंक के साथ PR खोलें और pull request template का उपयोग करें

पढ़ने की सामग्री और उदाहरण लेख

कार्य निष्पादन, embedding, queue

  • Cron Jobs

  • Embeddable Postgres

    • PGLite: browser, Node.js, Bun, और Deno में चलने योग्य 10MB से छोटे WASM Postgres build को TypeScript library के रूप में पैकेज करता है
    • pgmicro: SQLite-compatible storage engine पर आधारित in-process PostgreSQL का पुनर्प्रयोग

  • Message Queues

    • tembo-io/pgmq
    • SKIP LOCKED
    • sequinstream/sequin: Postgres rows और changes को Kafka, SQS जैसे streaming platforms और queues में भेजने वाला CDC tool
    • janbjorge/pgqueuer: PostgreSQL का उपयोग करने वाली Python job queue library
    • smartpricing/queen: independent FIFO partitions, Kafka-style consumer groups, और exactly-once delivery देने वाली PostgreSQL-आधारित message queue

analytics, maps, audit, permissions

सर्च, टाइम सीरीज़, कॉलमनर, NoSQL, ग्राफ

  • Full Text Search

    • Postgres Full Text Search: संबंधित लिंक का संग्रह
    • pg_search: BM25 का उपयोग करने वाला Postgres फुल-टेक्स्ट सर्च
    • plpgsql_bm25: PL/pgSQL में इम्प्लीमेंट किया गया BM25 सर्च

  • Vector Search

    • pgvector/pgvector
    • tensorchord/VectorChord: PostgreSQL के लिए वेक्टर similarity search एक्सटेंशन, जिसका लक्ष्य scalability, high performance और disk efficiency है
    • timescale/pgai: pgvector-आधारित एक्सटेंशन, जो Postgres के अंदर RAG, semantic search और AI application development को सपोर्ट करता है
    • timescale/pgvectorscale: pgvector को पूरक करने वाला DiskANN vector index implementation

  • Hybrid Search

    • plpgsql_bm25rrf.sql: BM25 और pgvector को Reciprocal Rank Fusion के साथ जोड़ने वाला hybrid search

  • Time Series

  • Column Oriented

    • paradedb/paradedb: search और analytics के लिए Postgres
    • pg_duckdb: Postgres के अंदर DuckDB column storage

  • NoSQL

    • JSON Types: PostgreSQL में JSON के लिए native support
    • Using JSONB in PostgreSQL: PostgreSQL में JSON data को store और index करने के तरीके

  • Graph Data

    • Apache Age: PostgreSQL के लिए graph database, जो relational database में graph data processing और analytics capabilities प्रदान करता है

बाहरी डेटा, HTTP, API, GraphQL, CDC

कैशिंग, टेस्टिंग, एप्लिकेशन, माइग्रेशन

परफ़ॉर्मेंस, मॉनिटरिंग, स्केलिंग, UI

  • Performance Tuning

  • Monitoring

    • StatsMgr: WAL, SLRU, checkpointing आदि के लिए statistics management का समर्थन
    • pgMonitor: Prometheus, Grafana, SQL Exporter और pgMonitor extension के साथ metrics को visualize करने वाला monitoring solution

  • Testing

    • regresql: PostgreSQL को सपोर्ट करने वाला SQL query regression testing tool

  • Scaling & Storage

    • Snowflake-Labs/pg_lake: Postgres को standalone lakehouse system के रूप में इस्तेमाल करता है, और S3 जैसे object storage में मौजूद Iceberg tables के लिए transactions और queries को सपोर्ट करता है
    • pgdogdev/pgdog: PostgreSQL sharding को सपोर्ट करने वाला transaction pooler और logical replication manager
    • pgbouncer/pgbouncer: PostgreSQL के लिए lightweight connection pooler
    • orioledb.com: on-disk और in-memory engines के फ़ायदों को जोड़ने वाला PostgreSQL extension

  • User Interfaces & Dashboards

    • Baserow
    • NocoDB
    • AppSmith
    • mathesar-foundation/mathesar: spreadsheet-जैसा interface, जिससे अलग-अलग तकनीकी स्तर के यूज़र Postgres data को देख, एडिट, query और collaborate कर सकते हैं

डेवलपर टूल्स, visualization, package, security, finance

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

1 टिप्पणियां

 
GN⁺ 2024-12-09
Hacker News की राय

  • जब टीम 100 से ज़्यादा engineers तक बढ़ती है, तो एक ही Postgres DB को हर चीज़ के लिए इस्तेमाल न करना बेहतर होता है
    आखिरकार ऐसी स्थिति से बचना मुश्किल है जहाँ database ही API बन जाता है
    अगर आपके पास ऐसी technical leadership है जो logical और physical boundaries को अच्छी तरह बाँट सके और हर unit को अपना Postgres देते हुए scale कर सके, तो “Postgres for everything” भी एक मज़बूत विकल्प है
    लेकिन ऐसे मुश्किल काम को अंजाम देने वाले CTO सोच से भी कम मिले हैं

    • बहुत जल्दी से planning करने की ज़रूरत नहीं है
      ज़्यादातर कंपनियाँ 100 से ज़्यादा engineers तक पहुँचती ही नहीं, इसलिए पहले ship करें और ऐसी चिंता बहुत बाद में भी की जा सकती है
      असल में users 2 भी नहीं हैं और सिर्फ 1 overworked engineer है, लेकिन server 40 रखे गए हैं और architecture ऐसा है जैसे लाखों engineers और अरबों visitors आने वाले हों—ऐसी कंपनियों को देखकर लगता है कि overengineering ज़िंदगी को और कठिन बना देती है
    • “सफल” शब्द को quotes में डालने की ज़रूरत नहीं है
      इन लोगों ने सच में product launch किया है
      कई databases में migrate करना और user information को sync करना क्रमिक milestones हैं, हर पल ज़रूरी precondition नहीं
    • क्या “database API बन जाता है” असल में Postgres for everything का मुख्य बिंदु नहीं है?
    • Database-as-the-API काफ़ी दूर तक scale कर सकता है
      खासकर तब, जब हर customer को single-tenant shard बेचा जाता हो और नतीजतन हर customer को अलग database मिलता हो
      जब product अभी domain और बिकने वाले features तक नहीं जानता, तब पहले से logical software boundaries खींच देना काफ़ी जोखिम भरा होता है
    • अगर stored procedures और views से abstraction ठीक से की गई हो, तो database को API की तरह इस्तेमाल करने का तरीका भी अच्छी तरह काम करता है
      यह GraphQL से expose की गई 100 services से कहीं कम fragile हो सकता है

  • मुझे Postgres बहुत पसंद है, लेकिन team के बाहर के लोगों के लिए database से generate की गई API को सीधे expose करना नहीं करना चाहिए
    ऐसा करने पर data को store करने का तरीका बदलने की क्षमता बहुत सीमित हो जाती है
    मैंने पहले इस विषय पर लिखा था, और अब भी मेरी राय ज़्यादा नहीं बदली है
    ऐसी tight coupling कोई नहीं चाहेगा: https://wundergraph.com/blog/six-year-graphql-recap#generate...

    • tight coupling में असल समस्या क्या है, यह जानने की जिज्ञासा है
      क्या मतलब यह है कि बाद में database column नाम बदलने पर भी API न बदलनी पड़े, इसलिए format A को format B में translate करने के लिए एक पूरी अतिरिक्त layer जोड़नी होगी?
    • क्या बीच की layer के रूप में views का इस्तेमाल नहीं किया जा सकता?

  • हाल ही में यह जानकर झुंझलाहट हुई कि Postgres indexes skip scan को support नहीं करते
    string में null character \u0000 भी नहीं डाला जा सकता
    शानदार DB है, लेकिन जगह-जगह अजीब gaps हैं
    https://wiki.postgresql.org/wiki/Loose_indexscan
    https://stackoverflow.com/questions/28813409/are-null-bytes-...

    • यह जानने की जिज्ञासा है कि string के अंदर null character डालने का कोई उचित उपयोग क्या हो सकता है
      पहली प्रतिक्रिया तो यही है कि null वाले strings को स्वाभाविक रूप से reject कर देना चाहिए
    • अगर null character चाहिए, तो blob से परिचय कराना चाहूँगा
    • सही है, अभी skip index scan के लिए user-defined SQL की ज़रूरत होती है
      यह भी थोड़ा खटकता है कि cache-जैसे उपयोग के लिए first-class feature नहीं है
      unlogged tables काफ़ी उपयोगी हैं और temporary tables भी अच्छे हैं, लेकिन कुल मिलाकर यह झंझटभरा, असहज और वास्तविक ज़रूरत से अलग महसूस होता है

  • PGQueuer PostgreSQL पर बना Python के लिए एक lightweight job queue है
    efficient और safe job processing के लिए यह SKIP LOCKED का इस्तेमाल करता है, और simplicity के साथ performance बनाए रखने के लिए minimal design अपनाता है
    अगर आप पहले से Postgres इस्तेमाल कर रहे हैं और बिना अतिरिक्त infrastructure के Python-friendly तरीके से background jobs manage करना चाहते हैं, तो इसे देखना ठीक रहेगा: GitHub - https://github.com/janbjorge/pgqueuer

    • Python के लिए एक और शुरुआती विकल्प https://github.com/TkTech/chancy भी है
      यह उलटी दिशा में dashboard, workflow, और mixed-mode workers जैसी सुविधाएँ शामिल करने की कोशिश करता है
      documentation के similar projects section को देखें तो Postgres-आधारित job queues काफ़ी मिलते हैं
    • मुझे हमेशा यह दावा संदिग्ध लगा है कि SKIP LOCKED सच में इतना efficient है
      अगर बहुत छोटे jobs और लंबे jobs मिले-जुले हों, तो एक लंबे job के खत्म होने तक सैकड़ों या हज़ारों छोटे jobs चल सकते हैं
      उस स्थिति में लंबे job वाली rows locked रहती हैं और job table में उन्हें सैकड़ों बार skip किया जाता है
      एक साथ लंबे समय तक चलने वाले jobs जितने ज़्यादा होंगे, locked rows को बार-बार skip करने की बर्बादी उतनी बढ़ेगी, इसलिए कम load पर तो यह ठीक हो सकता है, लेकिन अलग “running” table में move करने वाला ढाँचा ज़्यादा efficient हो सकता है
    • dedicated job queue system की तुलना में इसका फ़ायदा क्या है, यह जानना चाहता हूँ

  • कुछ projects में MariaDB/MySQL से बँधा होने के कारण मैंने हाल में PostgreSQL से तुलना की, और पाया कि JSON, system-versioned temporary tables, और columnar/vector stores जैसी कई expanded features वहाँ भी मौजूद थीं
    LISTEN/NOTIFY जैसी सुविधाएँ कम दिखीं, लेकिन कुल मिलाकर यह देखकर हैरानी हुई कि वे काफ़ी आगे तक पहुँच चुके हैं
    फिर भी, बहुत-सी legacy apps में शायद इन सुविधाओं का लगभग कोई इस्तेमाल नहीं होगा

  • यह प्रचार भी जोड़ दिया जाए तो अच्छा होगा: https://github.com/jankovicsandras/plpgsql_bm25
    यह उन वातावरणों आदि के लिए PL/pgSQL-आधारित ओपन सोर्स BM25 search है जहाँ Rust extension इस्तेमाल नहीं किए जा सकते, और pgvector तथा Reciprocal Rank Fusion का उपयोग करने वाली hybrid search भी सपोर्ट करता है

  • सुबह “Amazing CTO की इस पोस्ट से प्रेरणा मिली” यह पंक्ति देखी, और यह पता चलना कि मेरी पोस्ट का संदर्भ दिया गया है, बहुत अच्छा लगा
    https://www.amazingcto.com/postgres-for-everything/

    • “Elastic की जगह Postgres से full-text search इस्तेमाल करो” यह सुझाव खास पसंद नहीं आया
      Postgres full-text search बहुत सीमित है और user-friendly भी नहीं है

  • अगर कई सुविधाओं तक पहुँचने के लिए एक ही API हो, तो उसके कई फायदे दिखते हैं
    उदाहरण के लिए, message queue के साथ integration करने की बजाय सिर्फ INSERT करना पड़े, तो friction काफी कम हो जाता है
    vector search भी बिल्कुल समझ में आता है
    जब एक ही चीज़ से सब हो सकता है, तो दो database रखने की वजह नहीं बनती
    लेकिन Postgres से HTML generate करना थोड़ा सवाल खड़ा करता है
    मैंने खुद नहीं किया है, पर इसे user interface बनाने का व्यावहारिक तरीका मानना मुश्किल लगता है

    • https://apex.oracle.com/ को देख सकते हैं, जो यही तरीका इस्तेमाल करता है

  • सोच रहा हूँ कि self-hosted Postgres database के लिए कोई अच्छा resource है क्या
    मैं कई personal projects के लिए DB server खुद चलाना चाहता हूँ, इसलिए backup, optimization, Docker इस्तेमाल करना चाहिए या नहीं, जैसी tips और best practices अच्छे से जानना चाहता हूँ

    • इस YouTube channel पर कई वीडियो हैं जो बताते हैं कि एक सामान्य Linux machine पर Postgres कैसे install करें, configure करें, और उसे high availability के साथ कैसे चलाएँ
      यह सोच से ज़्यादा आसान है
      https://youtube.com/playlist?list=PLBrWqg4Ny6vVwwrxjgEtJgdre...
    • खुद host करते समय मैं इसकी सादगी की वजह से SQLite की तरफ झुकता हूँ
      in-place upgrade, Litestream के ज़रिए आसान backup जैसी चीज़ें सरल हैं
      Postgres major version upgrade ही self-host न करने की मुख्य वजह है, लेकिन शायद इस पर फिर से सोचना चाहिए
    • अगर अभी शुरुआत कर रहे हैं, तो backup के लिए pg_dump अच्छा और सरल है
      tuning के लिए postgresqlco.nf बेहतरीन है
      https://postgresqlco.nf/tuning-guide
    • शायद यह वही जवाब नहीं है जिसे आप ढूँढ़ रहे थे, लेकिन मिलते-जुलते कारणों से मैंने हाल में एक service देखी थी
      मैं छोटे MVP projects लगातार deploy करना चाहता था, लेकिन Render पर हर project के लिए अलग DB service का खर्च नहीं उठाना चाहता था
      https://www.thenile.dev/pricing शायद unlimited databases सपोर्ट करता है
    • अगर on-premises है, तो container इस्तेमाल करें, लेकिन data folder को mounted volume पर रखना बेहतर है
      cloud या Kubernetes में तो managed DB इस्तेमाल करना ही बेहतर है, और मेरी समझ में Kubernetes पर DB खुद सेट करना filesystem की वजह से मुश्किल होता है

  • graph data के लिए Apache Age integrate करने में मैंने लगभग 2 हफ्ते लगा दिए, फिर समझ आया कि project ठहरा हुआ है और हालत खराब है
    ऐसी सूचियों पर आँख बंद करके भरोसा नहीं करना चाहिए
    अब DGraph से बेहतर नतीजों की उम्मीद है, लेकिन graph databases का ecosystem भी कुछ अस्थिर सा लगता है

    • जानना चाहता हूँ कि graph database किन use cases में सचमुच अच्छी तरह fit बैठता है
      शायद कुछ होंगे, लेकिन तुरंत ध्यान में नहीं आते, जबकि ऐसे मामले देखे हैं जहाँ graph DB को वहाँ इस्तेमाल किया गया जहाँ वह सही fit नहीं था
    • Dgraph में कौन-कौन से pitfalls हैं, यह जानने की उत्सुकता है
      Neo4j की जगह इसे न चुनने की वजह क्या होगी?
      जिन graph DB projects में मैं शामिल रहा हूँ, उनमें सभी ने Neo4j ही इस्तेमाल किया; अगर कोई अच्छा alternative है तो जानना चाहूँगा
    • Apache Age के साथ भी यही स्थिति थी
      अगर आप थोड़ा और विस्तार से बता सकें तो अच्छा होगा
    • मैं भी यही कहने आया था
      आखिरी बार जब देखा था, Apache Age Neo4j से बहुत पीछे था
      तकनीकी रूप से यह मौजूद है और सूची में जगह पाने लायक भी है, लेकिन serious workloads के लिए इसकी सिफारिश नहीं करूँगा