PostgreSQL ही काफ़ी है

 (gist.github.com/cpursley)
44 पॉइंट द्वारा GN⁺ 2024-02-07 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • PostgreSQL को विभिन्न क्षेत्रों में इस्तेमाल करने के तरीकों के लिंक समेटने वाला पेज
    • बैकग्राउंड jobs, message queue, GIS, audit log, access control, permission management, search, time series, graph data, external data, HTTP, API, event/replication/CDC, unit test, migration, dashboard/UI, data visualization, HTML और application, LSP(language server)

PostgreSQL is Enough

बैकग्राउंड कार्य

  • pg_cron के माध्यम से PostgreSQL में scheduled jobs को manage किया जा सकता है.

message queue

  • PostgreSQL को message queue तकनीक के रूप में चुनने के तरीकों पर जानकारी दी गई है.
  • pgmq PostgreSQL पर आधारित एक message queue system है.

GIS/मैप

  • PostGIS PostgreSQL में geospatial database features जोड़ता है.

audit log

  • pgMemento और pgaudit PostgreSQL में changes को track करते हैं और audit log को manage करते हैं.

access control

  • acl का उपयोग PostgreSQL में access control list को manage करने के लिए किया जाता है.

authentication

  • PostgreSQL का pgcrypto module और pgjwt database के भीतर authentication को handle करते हैं.

search

  • PostgreSQL की full-text search functionality से जुड़े उपयोगी links दिए गए हैं.
  • paradedb, pg_embedding, pgvector PostgreSQL में search capabilities को बेहतर बनाते हैं.

time series data

  • timescaledb PostgreSQL को extend करके time series data को manage करता है.

graph data

  • Apache AGE PostgreSQL को extend करके graph database functionality प्रदान करता है.

external data

  • wrappers PostgreSQL में external data sources को integrate करता है.

HTTP

  • pgsql-http और pg_net PostgreSQL में HTTP requests को handle करते हैं.

API

  • PostgREST, graphql-engine, postgraphile, pg_graphql PostgreSQL आधारित API server बनाते हैं.

event, replication, CDC

  • PostgreSQL का NOTIFY command और walex, peerdb, debezium, pglogical data changes को track करते हैं और replication functionality प्रदान करते हैं.

unit test

  • pgtap PostgreSQL database के unit test के लिए एक tool है.

migration

  • postgresql-migrations और bytebase PostgreSQL database migration को manage करते हैं.

dashboard / UI

  • Baserow, NocoDB, AppSmith user interface और dashboard प्रदान करते हैं.

data visualization

  • Evidence और Metabase data visualization tools हैं.

HTML और application

  • SQLpage, Omnigres, pg_render, plmustache PostgreSQL data को web applications में integrate करते हैं.

language server

  • postgres_lsp PostgreSQL के लिए language server protocol support प्रदान करता है.

क्या छूट गया?

  • कृपया comments के माध्यम से छूटी हुई सामग्री साझा करें

GN⁺ की राय

  • PostgreSQL अपने विभिन्न extensions और tools के माध्यम से यह दिखाता है कि वह सिर्फ़ एक साधारण database management system से कहीं बढ़कर एक बहुउपयोगी platform है.
  • यह लेख PostgreSQL का उपयोग करके विभिन्न application requirements को पूरा करने के तरीके प्रस्तुत करता है, जिससे developers को उपयोगी resources मिलते हैं.
  • खास तौर पर, यह उन क्षमताओं की संभावनाओं पर ज़ोर देता है जिन्हें सीधे database के भीतर handle करके system architecture को सरल बनाया जा सकता है और performance को optimize किया जा सकता है.

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

2 टिप्पणियां

 
eususu 2024-02-07

इनमें से मैं व्यक्तिगत रूप से postgREST इस्तेमाल कर रहा हूँ, और इससे संतुष्ट हूँ।
 
GN⁺ 2024-02-07
Hacker News राय

  • एप्लिकेशन स्टैक को सरल बनाने की कोशिश पर अनुभव साझा

    एक उपयोगकर्ता ने साझा किया कि वह अक्सर एप्लिकेशन स्टैक को सरल बनाने की कोशिश करता है, लेकिन जैसे-जैसे एप्लिकेशन की जटिलता बढ़ती है, अलग-अलग तकनीकी स्टैक्स की ज़रूरत समझ में आने लगती है। Postgres जैसी एक ही तकनीक में सब कुछ समेटने की कोशिश असुविधाजनक लग सकती है। फिर भी, नई लेयर जोड़ने की तुलना में मौजूदा तकनीक का विस्तार करना बेहतर हो सकता है। उदाहरण के लिए, Postgres को message queue की तरह इस्तेमाल करना, अलग message queue बनाए रखने से कहीं आसान है। Postgres डेटाबेसों में भी काफ़ी extensible है, और इसके आधार पर तकनीक बनाना बहुत दिलचस्प है.

  • ParadeDB बनाने वालों में से एक की Postgres की extensibility पर राय

    ParadeDB के निर्माताओं में से एक के अनुसार, वे Postgres extensions के ज़रिए fast search और analytics capabilities देते हैं। startup जैसे छोटे workload के लिए, जितना संभव हो उतने लंबे समय तक Postgres के भीतर काम करना तर्कसंगत है। लेकिन scale बढ़ने पर Postgres अकेले सब कुछ हल नहीं कर सकता। Postgres के भीतर अलग-अलग workload संभालने के लिए, सिस्टम को विशिष्ट आवश्यकताओं के अनुसार अलग करना और independent scalability व resilience सुनिश्चित करना ज़रूरी होता है। इस बिंदु पर हर ज़रूरत के लिए specialized solution stack चाहिए। Postgres version के stack components बनाने की दिशा में काम हो रहा है, लेकिन हर solution Postgres से आगे निकल जाता है, और उन्हें नहीं लगता कि stack के हर component के लिए Postgres-आधारित solution होगा.

  • नया प्रोजेक्ट शुरू करते समय sqlite इस्तेमाल करने के फ़ैसले पर राय

    एक उपयोगकर्ता ने तय किया है कि हर नया प्रोजेक्ट sqlite से शुरू करेगा और जब तक बिल्कुल ज़रूरी न हो, तब तक switch नहीं करेगा। अगर Postgres 90% मामलों में उपयुक्त है, तो sqlite 80% मामलों में पर्याप्त है, और इसे शुरू करना आसान है तथा performance भी अच्छी है। जब vertical scaling काम करना बंद कर देगी, तब तक जो बनाया जा चुका होगा उससे संतुष्टि होगी.

  • डेटाबेस को लेकर एक C++ विशेषज्ञ का सवाल

    डेटाबेस से परिचित न होने वाला एक C++ विशेषज्ञ डेटाबेस की आवश्यकता पर सवाल उठाता है। वह ऐसे उद्योग से आता है जहाँ custom binary file formats का बहुत उपयोग होता है, और उसे लगता है कि डेटाबेस ऊपर-ऊपर से बहुत सी समस्याएँ हल करते दिखते हैं, लेकिन वास्तव में ऐसा नहीं है। data types पर सीमाएँ, updates की समस्याएँ, अलग-अलग SQL engines के बीच compatibility issues जैसी बातें डेटाबेस के उपयोग को खराब विचार जैसा बनाती हैं। बड़े data volumes में interoperability के फ़ायदे वह समझता है, लेकिन उसके अलावा डेटाबेस की ज़रूरत पर गंभीर सवाल पूछता है.

  • PostgreSQL के अतिरिक्त फीचर्स पर राय

    यह बताते हुए कि ज़्यादातर अतिरिक्त फीचर्स MariaDB में पहले से built-in हैं, उपयोगकर्ता PostgreSQL HTTP client की motivation का एक हिस्सा उद्धृत करता है। इस विचार पर कि web service को call करने वाला trigger लिख पाना अच्छा होगा, वह कहता है कि ऐसा काम वह ख़ुद करने के बजाय किसी और पर छोड़ना पसंद करेगा.

  • advanced features इस्तेमाल करते समय code management के साथ जुड़ाव की समस्या

    एक उपयोगकर्ता Postgres का व्यापक उपयोग करता है, लेकिन हर बार advanced features इस्तेमाल करने पर version control, code review, types, tests, static analysis जैसी coding की सभी अच्छी बातों के साथ उन्हें जोड़ने में समस्या आती है। वह migrations के बारे में सवाल उठाता है.

  • मौजूदा stack से नए फीचर का prototype बनाने के फ़ायदे

    एक उपयोगकर्ता ने अनुभव साझा किया कि पहले नए फीचर का prototype बनाना, कुछ बिल्कुल नया लाने से बेहतर होता है। सावधानीपूर्वक curation के ज़रिए शुरुआती prototype को उसी stack पर production code में बदला जा सकता है। लेकिन जब सिस्टम अपनी सीमा पर पहुँचता है, तब Redis या किसी अन्य specialized tool की ज़रूरत महसूस हो सकती है। महत्वपूर्ण बात यह है कि API wrapper लिखा जाए, ताकि ज़रूरत पड़ने पर सिर्फ़ internal implementation बदली जाए और migration को अच्छी तरह test किया जाए। वह कहता है कि लोग यह देखकर चकित होंगे कि तकनीकी निर्णयों को कितनी देर तक टाला जा सकता है.

  • Postgres, Redis, S3 इस्तेमाल करने वाले उपयोगकर्ता का अनुभव

    एक उपयोगकर्ता बताता है कि वह Postgres, Redis, S3 के संयोजन का उपयोग करता है, और अब तक यह संयोजन कभी ग़लत साबित नहीं हुआ। कभी-कभी वह Postgres से Pub/Sub आज़माना चाहता है, लेकिन वैसे भी caching और sidekiq के लिए Redis चाहिए, और Redis ख़ुद भी बेहतरीन है, इसलिए वह इसकी कोशिश नहीं करता.

  • बड़े पैमाने के data analytics में Postgres की सीमाएँ

    एक उपयोगकर्ता, जिसे Postgres बहुत पसंद है, साझा करता है कि जब data scale बहुत बड़ा हो जाता है तो Postgres पर्याप्त नहीं लगता। OLTP तरह के workload संभालने में Postgres शानदार है, लेकिन अगर OLAP support ज़्यादा चाहिए तो वह StarRocks इस्तेमाल करने की सलाह देता है। data analytics के लिए Postgres से StarRocks में data लाने का अनुभव बहुत अच्छा रहा है, और StarRocks data lake पर direct queries भी support करता है.

  • Postgres की jsonb compression capability की आवश्यकता

    एक उपयोगकर्ता Mongo और PG दोनों का उपयोग करता है, लेकिन PG कहीं ज़्यादा सरल होने के कारण वह simplification के लिए Mongo छोड़ना चाहता है। उसे बस compressed jsonb column चाहिए, जहाँ updates या queries के बिना केवल insert, select, delete संभव हों। Mongo की तरह बार-बार दोहराई जाने वाली json keys पर 80-90% compression ratio बना रहे और maintenance की भी ज़रूरत न हो.