डिजाइन पैटर्न (या तकनीक) अनुमापकता

Question

क्या डिजाइन पैटर्न या तकनीक है आप इस्तेमाल के लिए है कि विशेष रूप से scalability की ओर तैयार कर रहे हैं?

Flyweight पैटर्न जैसे पैटर्न उच्च स्केलेबिलिटी को बढ़ावा देने या स्मृति या स्टोरेज बाधाओं के भीतर काम करते समय Factory Pattern के पैटर्न का एक विशेष संस्करण प्रतीत होता है।

आपने अन्य लोगों का क्या उपयोग किया है? (Denormalization of Databases, आदि) क्या आप पाते हैं कि उच्च उपलब्धता या स्केलेबिलिटी आपका प्राथमिक लक्ष्य होने पर नियम बदलते हैं?

संभावित स्थितियों हैं: और अधिक सीमित स्मृति, प्रसंस्करण शक्ति, और कनेक्टिविटी एक डेस्कटॉप या लैपटॉप

सीमित हार्डवेयर पर उपयोगकर्ताओं के उच्च # से (कैशिंग रणनीति, आदि)

साथ

• मोबाइल डिवाइस सामान्यीकृत डिज़ाइन के बदले दक्षता के लिए डेटाबेस स्कीमा का अनुकूलन (उदाहरण के लिए स्टोरेज के लिए शेयरपॉइंट कॉलम रैपिंग)

Answer 1

कुछ पैटर्न है कि मन में आते हैं:

• स्टेटलेस आवेदन
• ढीला युग्मन
• Asynchrony
• लेज़ी लोड हो रहा है
• कैशिंग
• समानता
• विभाजन
• रूटिंग

कुछ संसाधन:

• Scalability Best Practices: Lessons from eBay
• Availability & Consistency
• Microsoft PDC'08 Presentations
• Best Practices In Building Scalable Cloud Ready Service Based

Answer 2

एप्लिकेशन को स्थिर के रूप में स्टेटलेस बनाएं ble। एक सर्वर फार्म के अनुकूल होना आसान होगा।

Answer 3

कुछ भी मुफ्त नहीं है - यह आपके व्यावसायिक उद्देश्यों को पूरा करने के लिए स्वीकार्य समझौता क्या है नीचे आता है। मुख्य चर जा रहा है:

• लागत
• उपलब्धता
• संगति
• Survivability (जैसे, विभाजन सहिष्णुता)

एक उत्कृष्ट paper विषय पर पढ़ने के लिए।

मेरा मानना ​​है कि यह एक अच्छा मीट्रिक "लागत/उपयोगकर्ता" वक्र की जांच करने और (रेखीय प्रगति के लिए इसे बनाए रखने प्रति उपयोगकर्ता स्वीकार्य लागत संभालने की कोशिश करना होगा एक ज्ञात पैरामीटर :-)

है डिजाइन पैटर्न खेलने करना एक भूमिका है लेकिन यह अत्यधिक प्रचलित वास्तुकला है जो सबसे महत्वपूर्ण है। एक मॉड्यूल स्तर पर बहुत गहराई से हो सकता है लेकिन परिणामस्वरूप नेटवर्क स्तर की बाधाओं और स्केलेबिलिटी का सामना करना पड़ा।

दिन के अंत में, मेरा मानना ​​है कि किसी को खुद से पूछना चाहिए (खुद): विफलता प्रकार एक्स के लिए, कितने "उपयोगकर्ता" प्रभावित हो सकते हैं और कितने समय तक?

हमेशा एक एसपीओफ़ (विफलता का सिंगल प्वाइंट) होगा, लेकिन कोई एक सिस्टम इंजीनियर कर सकता है जैसे कि यह एसपीओफ़ अंत-बिंदुओं (जैसे उपयोगकर्ता) के करीब ले जाया गया है। हालांकि कई मामलों में, एसपीओफ़ आवेदन के नियंत्रण से बाहर है उदा। नेटवर्क पीओपी अनुपलब्ध।

वैसे भी, मैं इस विषय पर घंटे बिता सकता हूं ...

Answer 4

स्थिति की अमेज़न के सीटीओ डॉ वर्नर वोगल्स प्रस्तुति ए (पैटर्न-ओरिएंटेड सॉफ्टवेयर आर्किटेक्चर) किताबें ऐसे पैटर्न के लिए एक महान स्रोत हैं।

POSA 4, विशेष रूप से वितरित कंप्यूटिंग से संबंधित है, लेकिन सभी वॉल्यूम स्केलेबिलिटी पैटर्न से भरे हुए हैं।

Answer 5

मैंने स्टेटलेस एप्लिकेशन तर्क के साथ जो देखा है वह यह है कि यह डीबी पर लॉक करने जैसी कई अन्य आवश्यकताओं को प्रस्तुत करता है जो अंत में स्केलेबिलिटी के खिलाफ काम करते हैं।

आइए कहें कि एक आवेदन फार्म में तैनात आवेदन तर्क एक अनुरोध के लिए एक क्लस्टर के दो नोड्स को मार रहा है, उसी समय हमें डीबी लॉकिंग जैसी अवधारणाओं को पेश करना होगा ताकि यह सुनिश्चित किया जा सके कि केवल एक अनुरोध संसाधित हो जाएगा।

मैं अब ऐसी परिस्थितियों से निपट रहा हूं और सोच रहा था कि हर कोई इस तरह के स्टेटलेस व्यवहार से कैसे निपट रहा है।