बस Postgres को हर जगह इस्तेमाल करें
(amazingcto.com)- Postgres कई backend technologies का विकल्प बन सकता है (लाखों users तक)
→ Kafka, RabbitMQ, Mongo, Redis,.. - cache के लिए Redis की जगह UNLOGGED tables में
TEXTको JSON फ़ॉर्म में इस्तेमाल करें- stored procedures से data की expiry सेट करें
- message queue (Kafka):
SKIP LOCKED - data warehouse के लिए Postgres+TimescaleDB
- Mongo की जगह
JSONBstore करें, और search तथा indexing करें pg_cronसे mail भेजने जैसी चीज़ों के लिए CRON daemon की तरह इस्तेमाल करें- geospatial queries के लिए इस्तेमाल करें
- Elastic की जगह full-text search के लिए इस्तेमाल करें
- DB के अंदर JSON बनाकर server-side code के बिना सीधे API को दें
- GraphQL adapter के साथ GraphQL भी support करता है
13 टिप्पणियां
हूं.. अगर हर ऐप में सपोर्ट होने वाली और ज़्यादा सुविधाओं की ज़रूरत नहीं है, तो मूल अवधारणा के स्तर पर postgres काफ़ी है, बात लगभग इतनी ही लगती है.
क्योंकि हर ऐप ऊपर जिस फ़्लो को बदल रहा है, उससे भी ज़्यादा सुविधाएँ इस्तेमाल कर सकता है.
अगर इंटरफ़ेस सही तरह से तय करके इस्तेमाल किया जाए, तो मुझे नहीं लगता कि यह कोई बेतुकी बात है। हालांकि cache/message queue जैसी चीज़ें Redis को सौंप देना भी ठीक है।
मैं भी हाल में ऊपर के लेख जैसी ही सोच रखता हूँ। बेशक, बड़े पैमाने की सेवाओं में जोखिम को बाँटने के लिए जितना संभव हो उतना distributed रखना बेहतर है, लेकिन छोटे पैमाने के outsourced प्रोजेक्ट्स में अलग से NoSQL इस्तेमाल किए बिना Postgres के
jsonbtype का उपयोग करना मेरे लिए कहीं ज़्यादा उपयोगी रहा है। यह RDB + NoSQL को मिलाकर इस्तेमाल करने जैसा अनुभव देता है, और छोटे प्रोजेक्ट्स में performance भी पूरी तरह पर्याप्त थी।सब कुछ एक ही चीज़ से करने जितना, सारे risk points भी एक ही जगह इकट्ठा हो जाते हैं..!
कुछ चीज़ें वाकई पहले उस दौर में RDB से की जाती थीं जब उनका कोई विकल्प नहीं था, लेकिन Redis, Kafka, Cron जैसी चीज़ों के मामले में ऐसा लगता है कि उनके मुख्य फायदे बदले नहीं जा सकते। यह बस मज़े के लिए देखने और आगे बढ़ जाने लायक एक आइडिया लगता है।
जिन्हें एक ही चीज़ से सब कुछ करना पसंद है, उनके लिए यह बिल्कुल सही लगेगा।
मैंने Geospatial की वजह से postgres इस्तेमाल किया था।
दूसरे DB की तुलना में यह लगभग 10~100 गुना तेज़ था.. geo वाले काम में तो यह वाकई दबदबे वाला था।
लेकिन जैसा कि आप सब जानते हैं, डेटा बहुत बढ़ जाने पर अगर vacuum गलत तरीके से चल जाए, तो नर्क जैसा अनुभव होता है..
ओह, इसमें कई तरकीबें हैं।
लेकिन पहली UNLOGGED और stored procedure की combination के मामले में, उसके बजाय Redis इस्तेमाल करना कहीं ज़्यादा साफ-सुथरा लगेगा, haha
यह कुछ साल पहले की बात है, लेकिन JSONB इस्तेमाल करते समय जब लोड बहुत बढ़ जाता था, तो मैंने kv पैटर्न के हिसाब से उपयुक्त विकल्प चुनकर उसे Redis में अलग करने जैसा काम किया था, और वह काफ़ी सहज अनुभव था।
काफ़ी दिलचस्प राय है।
शीर्षक थोड़ा उकसाने वाला है, लेकिन यह अपने-आप में सोचने लायक विषय लगा, इसलिए इसे ज्यों का त्यों साझा कर रहा हूँ.
क्योंकि शुरुआती MVP बनाते समय बहुत ज़्यादा components शामिल करना भी एक समस्या हो सकता है.
यह एक अच्छा कॉन्सेप्ट लगता है।
धन्यवाद।