आपके पास जो सिस्टम है, उसका भरपूर इस्तेमाल करें

• इस लेख में लेखक SaaS application में Postgres performance manage करने के अपने अनुभव पर चर्चा करते हैं, जहाँ database को load संभालने में कठिनाई हो रही थी.
• लेखक की टीम database के बहुत व्यस्त हो जाने पर हर बार उसे बड़े instance से बदलकर vertically scale करती रही. लेकिन वे पहले ही सबसे बड़े instance का उपयोग कर रहे थे और सिस्टम overload की स्थिति के करीब पहुँच गया था.
• दो संभावित समाधान सुझाए गए: writes को स्वतंत्र database clusters में shard करना, और monolith को कई आपस में जुड़े services (microservices) में विभाजित करना.
• दोनों समाधान capacity बढ़ा सकते हैं और fault tolerance तथा operational resilience के दिलचस्प विकल्प दे सकते हैं, लेकिन वे complexity को काफी बढ़ा देंगे.
• लेखक का तर्क है कि बढ़ी हुई complexity की असली कीमत attention है, और यही बाद के हर technical decision को अधिक जटिल बना देती है.
• लेखक सुझाव देते हैं कि complexity को बहुत बढ़ाने से पहले आमतौर पर मौजूदा सिस्टम से थोड़ा अतिरिक्त performance “निचोड़ने” का अवसर होता है, चाहे वह workload को समायोजित करके हो, performance tuning से हो, या सिस्टम को किसी तरह supplement करके.
• उनके मामले में, भारी queries को optimize करके, Postgres settings को tune करके, और कुछ महंगी read-only queries को replica DB पर offload करके, उन्होंने database का साप्ताहिक अधिकतम CPU उपयोग 90% से घटाकर 30% कर दिया.
• लेखक निष्कर्ष निकालते हैं कि complexity कभी-कभी आवश्यक और अपरिहार्य होती है, लेकिन जहाँ तक संभव हो complexity बढ़ाने को टालना और पहले मौजूदा सिस्टम से अधिकतम performance निकालना बेहतर है.

[GN⁺]

Hacker News राय

• लेख मौजूदा सिस्टम की संभावनाओं का अधिकतम उपयोग करने के महत्व पर ज़ोर देता है, और इसे बदलने या अपग्रेड करने पर विचार करने से पहले यही करने की बात कहता है।
• यह सुझाव देता है कि टीमें, भले ही सब कुछ परफेक्ट न हो, अपने पास मौजूद चीज़ों का उपयोग करें और मौजूदा संसाधनों के साथ लक्ष्यों को हासिल करने के तरीके खोजें।
• यह इस विचार पर चर्चा करता है कि application को इस तरह डिज़ाइन किया जाए कि database में join का उपयोग न करना पड़े, और सुझाव देता है कि storage सस्ता है तथा सब कुछ denormalized हो और transaction के भीतर update किया जाए।
• hot partition से बचने के लिए UUID के उपयोग का सुझाव दिया गया है, ताकि उन integers पर निर्भर रहने के बजाय horizontal scaling की जा सके जो अंततः विफल हो सकते हैं।
• एक टीम का सफल उदाहरण साझा किया गया है, जिसने hardware या complexity बढ़ाने के बजाय समस्या को हल करने का तरीका बदलकर सिस्टम performance में बड़ा सुधार किया।
• लेख एक ही बार में monolith को कई जुड़े हुए services में बाँटने के खिलाफ है, और इसके बजाय उस विभाजन की पहचान करने का सुझाव देता है जिसका सबसे बड़ा प्रभाव पड़ेगा।
• यह ORM पर बने web app में queries को optimize करने के महत्व पर ज़ोर देता है, क्योंकि अक्सर सुधार की काफी गुंजाइश होती है।
• यह microservice systems पर काम करने के mental burden और complexity के बारे में चेतावनी देता है, और संकेत देता है कि ये अक्सर downtime और भ्रम पैदा करते हैं।
• यह efficiency (हानि को कम करना और complexity से बचना) और optimization (complexity जोड़ने की कीमत पर विशेष algorithms का उपयोग) के बीच अंतर बताता है।
• यह अधिक complex infrastructure में migration को लेकर चिंता साझा करता है, और सुझाव देता है कि यह वह जादुई समाधान नहीं हो सकता जिसकी सभी उम्मीद करते हैं।
• यह simplicity को complexity पर प्राथमिकता देता है, खासकर तब जब संसाधन सीमित हों और सिस्टम बहुत मिशन-क्रिटिकल न हो।
• अंत में, लेख tenant (ग्राहक) के आधार पर sharding को scalability समस्याओं के संभावित समाधान के रूप में चर्चा करता है।