2011-03-11 8 views
9

मैं अपेक्षाकृत सरल वेब एप्लिकेशन विकसित करना शुरू कर रहा हूं जो विभिन्न स्रोतों से डेटा खींच लेगा और इसे सामान्यीकृत करेगा। उपयोगकर्ता सीधे साइट पर डेटा भी दर्ज कर सकता है। मैं सफल होने पर स्केल मारने की उम्मीद करता हूं। क्या स्केलेबल या वितरित प्रौद्योगिकियों का उपयोग करने के लिए समय में डालने लायक है या बस एक लैंप स्टैक से शुरू करें? फ्रेमवर्क या नहीं? कोई भी विचार, सुझाव, या टिप्पणियां मददगार होंगी।अब या बाद में स्केल करें?

विचार के मेरे अस्पष्ट वर्णन को अनदेखा करें, मैं आगे बढ़ने के बाद साझा करना पसंद करूंगा।

उत्तर

6

क्या अब समय में स्केलेबल या वितरित तकनीकों का उपयोग करने के लिए लायक है या बस एक लैंप स्टैक से शुरू करना उचित है?

एक लैंप स्टैक स्केलेबल है। अपाचे कई सारे विकल्प प्रदान करता है।

फ्रेमवर्क या नहीं?

हमेशा उच्चतम संचालित ढांचे का उपयोग करें जो आप पा सकते हैं। जितना संभव हो उतना छोटा कोड लिखें। जितनी जल्दी हो सके लोगों के सामने कुछ प्राप्त करें।

महत्वपूर्ण बातों पर फ़ोकस करें: काम करने के लिए कुछ प्राप्त करें।

यदि आपके पास कुछ काम नहीं है, तो स्केलेबिलिटी कोई फर्क नहीं पड़ता, है ना?

फिर अनुकूलन पर पढ़ें। http://c2.com/cgi/wiki?RulesOfOptimization बहुत उपयोगी है।

नियम 1. मत करो।

नियम 2. अभी तक नहीं।

नियम 3. अनुकूलन से पहले प्रोफ़ाइल।

जब तक आपके पास कोई काम करने वाला एप्लिकेशन न हो, आपको नहीं पता कि विशिष्ट - चीज़ आपकी स्केलेबिलिटी को सीमित करती है।

मान लीजिए। का आकलन करें।

इसका मतलब है कि लोग वास्तव में उपयोग करते हैं। स्केल बाद में आता है।

+0

हां है, यदि माप और प्रोफाइलिंग की आवश्यकता है, तो बाद में स्केलिंग पूरी समझ में आता है। अन्यथा आप किसके खिलाफ उपाय करेंगे? – Rimian

8

बाद में। मुझे याद नहीं है कि यह किसने कहा था (शायद एसओ का जेफ एटवुड हो सकता है) लेकिन यह सच हो जाता है: आपकी पहली समस्या अन्य लोगों को आपके काम की देखभाल करने के लिए मिल रही है। जब वे करते हैं तो पैमाने के बारे में चिंता करें।

निश्चित रूप से अपनी स्वयं की स्वच्छता के लिए एक अच्छी तरह से संरचित ढांचे के साथ जाना। यहां तक ​​कि यदि यह हजारों उपयोगकर्ताओं के साथ समाप्त नहीं होता है, तो आप समय-समय पर सुविधाओं को जोड़ना चाहेंगे। अच्छी संरचना के बिना एक विस्तार कोडबेस को बनाए रखना जल्दी ही काफी भयानक हो जाता है (वहां किया गया, क्लाइंट खो गया)।

बीटीडब्ल्यू, यदि आप अपना खुद का ढांचा लिखने के लिए लुभाने वाले हैं, तो ध्यान रखें कि यह बहुत काम का है। मेरी कंपनी के पास एक घर है जिसमें हमें बहुत गर्व है, लेकिन इसे परिपक्व होने में 3-4 साल लग गए हैं।

+0

परियोजनाओं है कि मैं क्योंकि वे कीमती समय खो दिया असफल विफल रही देखा की एक परेशान राशि है द्वारा बनाया गया था स्केलिंग पर, और इसके कारण उन्होंने भी वितरित नहीं किया। –

+0

हाँ, यह कठोर वास्तविकता –

3

बिल्कुल बाद में ऐसा करें। स्केलिंग दर्द एक अच्छा समस्या है, इसका मतलब है कि आपके प्रोजेक्ट जैसे लोग हार्डवेयर पर दबाव डालने के लिए पर्याप्त हैं।

आखिरी कंपनी जिस पर मैंने काम किया था, PHP के साथ काफी छोटा और केकेपीएचपी के पहले संस्करणों में शुरू हुआ जो बाहर आया (जब यह अभी भी बीटा में था)। कुछ कोड गंदे थे, व्यवस्थापक उपकरण एक गड़बड़ (कोड-वार) था, और यकीन है कि यह शुरुआत से बेहतर किया जा सकता था। लेकिन क्या आपको पता है? उन्होंने अपने प्रतिस्पर्धियों के सामने दरवाजा निकाला, और बेहद सफल हो गया।

जब मैं बोर्ड वे अपने वर्तमान संभावित क्षमता की सीमा को हिट करने शुरू कर रहे थे पर आया, और कि जब वे CDN के, lighttpd कैशिंग तकनीक, और अन्य तरीकों कोड को साफ और बनाने के लिए पर देख शुरू करने का फैसला है भारी भार के तहत चीजें चिकनी चलती हैं। मैं अब उनके लिए काम नहीं करता हूं लेकिन यह मूल रूप से जिस चीज पर था, उससे परे एक वास्तुकला को बढ़ाने में यह एक अच्छा अनुभव था।

मैं आपको अभी बता सकता हूं कि अगर उन्होंने सामग्री बेचने और वेबसाइट को लाइव करने से पहले स्केलेबिलिटी और ऑप्टिमाइज़ेशन करने की कोशिश की थी - वे अब आकार में कभी नहीं बढ़ेंगे। कंपनी www.beatport.com है यदि आप रुचि रखते हैं कि मैं किसके बारे में बात कर रहा हूं (फिर से पुन: प्रयास करने के लिए, मैं उन्हें विज्ञापन देने की कोशिश नहीं कर रहा हूं क्योंकि अब मैं उनके साथ संबद्ध नहीं हूं, लेकिन यह एक अच्छा मामला है अध्ययन और लोगों को यह समझना आसान है कि जब मैं अपनी वेबसाइट देखता हूं तो मैं किस बारे में बात कर रहा हूं)।

व्यक्तिगत रूप से, रूबी और रेल (और अलगाव को समझने के लिए) के साथ काम करने के बाद, और बीटपोर्ट पर PHP के साथ अनुभव करने के बाद - मैं आश्वस्त रूप से कह सकता हूं कि मैं कभी भी PHP कोड के साथ काम नहीं करना चाहता हूं = पी

0

मैं पहले के उत्तरदाताओं से सहमत हूं - इसे उपयोगी बनाएं, इसे काम करें और लोगों को पहले इसका उपयोग करने के लिए प्रेरित करें। मैं यह भी मानता हूं कि आपको जितना संभव हो उतना रोल करने के बजाए शेल्फ घटक (जिनमें से कई हैं) को चुनना चाहिए। साथ ही, सुनिश्चित करें कि आप अपने बुनियादी ढांचे के लिए घटक चुनते हैं जिन्हें आप स्केलेबल के रूप में जानते हैं ताकि आप अपने आवेदन के प्रमुख हिस्सों को दोबारा लिखने के बिना वहां जा सकें।

Berkeley DB के लिए उत्पाद प्रबंधक के रूप में, मैंने डेवलपर्स के गिनती मामलों को देखा है जिन्होंने "ओह, हम इसे एक फ्लैट फ़ाइल में लिखेंगे" या "मैं अपना खुद का सरल बी-पेड़ फ़ंक्शन लिख सकता हूं" या " डाटाबेस एक्सवाईजेड 'काफी अच्छा' है, मुझे बाद में समवर्ती या स्केलेबिलिटी के बारे में चिंता करने की ज़रूरत नहीं है "। उस दृष्टिकोण के साथ समस्या यह है कि ए) आप पहिया का पुन: आविष्कार कर रहे हैं (और जो दूसरों ने पहले से ही कठिन तरीके से सीखा है) और बी) आप इस तथ्य को अनदेखा कर रहे हैं कि आपको किसी बिंदु पर स्केलेबिलिटी से निपटना होगा और एक 'अच्छा पर्याप्त' समाधान के साथ जा रहा है।

आपके कार्यान्वयन में शुभकामनाएँ।

1

"अब या बाद में स्केल" पूछने के लिए मजेदार? और इसे "रेल पर रूबी" लेबल करें। वास्तव में, पर रूबी डेविड हाइनेमेयर हांससन, जो अपनी पुस्तक में एक पूरे अध्याय लेबल "बाद में स्केल" :)) http://gettingreal.37signals.com/ch04_Scale_Later.php

संबंधित मुद्दे