# निर्णय ढाँचा: SQL या NoSQL — सिस्टम डिज़ाइन

Source: https://www.geekswithgeeks.com/hi/system-design/sd-sql-nosql-framework

> हाइप से आगे बढ़कर हर वर्कलोड के लिए सही स्टोर चुनना।

## लेबल नहीं, आकार पूछें

'SQL या NoSQL' के बजाय पूछें: डेटा कितना संबंधित है (कई जॉइन बनाम स्व-निहित डॉक्यूमेंट)? क्या ट्रांज़ैक्शन को कई एंटिटी में फैलना है? स्कीमा स्थिर है या तेज़ी से बदल रही है? क्या स्केल एक नोड की राइट क्षमता से आगे जाएगा?

## एक त्वरित मिलान

भुगतान, इन्वेंटरी, बहु-रो ACID चाहने वाली कोई भी चीज़ → **रिलेशनल**। की से एक्सेस होने वाला यूज़र का सेशन/प्रोफ़ाइल ब्लॉब → **की-वैल्यू**। कनेक्शन का सोशल ग्राफ़ → **ग्राफ़ DB**। विशाल राइट मात्रा पर टाइम-सीरीज़ मेट्रिक्स → **वाइड-कॉलम** (Cassandra) या विशेष टाइम-सीरीज़ स्टोर।

## पॉलीग्लॉट पर्सिस्टेंस सामान्य है

बड़े सिस्टम कई स्टोर मिलाते हैं: ऑर्डर के लिए Postgres, सेशन के लिए Redis, सर्च के लिए Elasticsearch, ब्लॉब के लिए S3। एक डेटाबेस से सब कुछ करवाने के बजाय एक्सेस पैटर्न के अनुसार चुनें।