2010-12-30 10 views
8

मैं एक वेब एप्लिकेशन पर काम कर रहा हूं, जो ऐतिहासिक रूप से एक PHP/MySQL स्टैक पर बनाया गया था।क्या राज्यव्यापी वेब सर्वर का उपयोग करना समझ में आता है?

आवेदन के उन प्रमुख संचालनों में से एक को भारी गणना करना पड़ा जो पूरे डीबी तालिका की हर पंक्ति पर पुनरावृत्ति की आवश्यकता थी। कहने की जरूरत नहीं है कि यह एक गंभीर बाधा थी। तो जावा में पूरी प्रक्रिया को फिर से लिखने के लिए एक निर्णय लिया गया था।

इससे हमें दो लाभ मिले। एक यह था कि जावा, एक भाषा के रूप में, एक PHP प्रक्रिया से बहुत तेज था। दूसरा यह था कि हम जावा एप्लिकेशन सर्वर मेमोरी में पूरे डेटा सेट को बनाए रख सकते थे। तो अब हम स्मृति में गणना-भारी संचालन कर सकते हैं, और सबकुछ बहुत तेज होता है।

यह थोड़ी देर के लिए काम करता था, जब तक हमें एहसास हुआ कि हमें स्केल करने की आवश्यकता है, इसलिए अब हमें और अधिक वेब सर्वर की आवश्यकता है।

समस्या है - वर्तमान डिजाइन द्वारा, वे सभी को एक ही स्थिति को बनाए रखना चाहिए। वे सभी डीबी से पूछताछ करते हैं, डेटा को संसाधित करते हैं, और इसे स्मृति में बनाए रखते हैं। लेकिन जब आपको यह डेटा बदलने की आवश्यकता होती है तो क्या होता है? सभी सर्वर स्थिरता कैसे बनाए रखते हैं?

यह वास्तुकला मुझे दोषपूर्ण लगती है। स्मृति में सभी डेटा रखने से प्रदर्शन लाभ स्पष्ट है, लेकिन यह गंभीरता से स्केलेबिलिटी को प्रभावित करता है।

यहां से विकल्प क्या हैं? इन-मेमोरी, की-वैल्यू, डेटा स्टोर पर स्विच करें? क्या हमें पूरी तरह से वेब सर्वर के अंदर होल्डिंग स्टेटस छोड़ देना चाहिए?

उत्तर

4

अब :-)

हाँ Erlang करने के लिए स्विच, कि एक मजाक है, लेकिन सच्चाई का अनाज है। मुद्दा यह है कि: मूल रूप से आपका राज्य बाहरी, साझा भंडार में था: डीबी।अब आपके पास एक आंतरिक गैर-साझा भंडार में पूर्व (आंशिक रूप से) सटीक है: जावा रैम ऑब्जेक्ट्स। स्पष्ट तरीका यह है कि यह अभी भी सटीक है लेकिन बाहरी साझा भंडार में, तेज़ी से बेहतर है।

एक आसान जवाब memcached है।

एक और अपने स्वयं के 'calc सर्वर' है, जो दोनों गणना कार्य और (आंशिक) परिणाम केंद्रीकृत निर्माण करना है। वेब फ्रंटएंड प्रक्रियाएं केवल इस सर्वर तक पहुंचती हैं। Erlang में यह करने का प्राकृतिक तरीका होगा। अन्य भाषाओं में, आप इसे और अधिक काम कर सकते हैं। प्रेरणा के लिए ज़ीरोएमक्यू की जांच करें, भले ही आप इसे अंत में उपयोग न करें (लेकिन यह एक अच्छा अच्छा कार्यान्वयन है)।

+0

+1। – duffymo

1

यह क्लच हो सकता है, लेकिन डेटा हमेशा आपके द्वारा रखी गई जगह को भरने के लिए फैलता है। आपका डेटा आज स्मृति में फिट हो सकता है लेकिन मैं आपको गारंटी देता हूं कि यह भविष्य में कुछ समय में नहीं होगा। यह कितना दूर है कि समय-सीमा आपको बेहतर वास्तुकला का पता लगाना है। आपके आवेदन की स्थिति केवल इस बड़ी समस्या का एक लक्षण है।

क्या हर कोई पूरे डेटासेट पर अलग-अलग गणना करता है? क्या यह कुछ ऐसा है जो आप बैच में रातोंरात कर सकते हैं और दिन के दौरान लोगों तक पहुंच सकते हैं? यह कितना समय संवेदनशील है?

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

+0

मैं पूरी तरह आपसे सहमत हूँ। हम * उस बिंदु तक पहुंच जाएंगे जहां इस डेटा को स्मृति में रखना एक समस्या होगी। इस स्थिति के लिए कौन से समाधान मौजूद हैं? क्या एक के-वी डाटा स्टोर एक विकल्प है? सभी वेब सर्वरों के लिए एक बार स्टोर करें? या इसके अलावा, यदि कच्चे डेटा को बैकएंड पर भारी डीबी में संग्रहीत किया जाता है, तो आप मेटा-डेटा कहां स्टोर करते हैं जिसे आसानी से एक्सेस किया जाना चाहिए? –

+0

मुझे आपकी मदद करने के लिए आपके डेटा या गणना की प्रकृति के बारे में पर्याप्त जानकारी नहीं है। – n8wrl

1

मैं आपसे सहमत हूं - यह त्रुटिपूर्ण लगता है, लेकिन मुझे निश्चित रूप से जानने के लिए और अधिक जानकारी चाहिए।

आप एक बड़े डेटा सेट और भारी गणना का जिक्र करते हैं, लेकिन जब आप गणना की जाती हैं, तो डेटा के अपडेट होने के बारे में आप बात नहीं करते हैं, चाहे वह दिन का मूल्य या संपूर्ण डेटा सेट इत्यादि हो। एक बैच नौकरी की तरह बहुत कुछ दैनिक ऑफलाइन किया जा सकता है।

यदि ऐसा है, तो मुझे यकीन नहीं है कि वेब इसमें कहां से जुड़ता है। क्या आपके वेब उपयोगकर्ता क्रंचिंग के बाद बस कस्टम प्रश्न कर रहे हैं? क्या डेटा केवल पढ़ने के लिए या उपयोगकर्ताओं के लिए पढ़ा जाता है? या वे फ्लाई पर लगातार डेटा बदल रहे हैं?

मुझे आश्चर्य है कि आपके द्वारा चुनी गई दृढ़ता तकनीक चीजों को प्रभावित करती है? शायद आपकी समस्या के लिए कोई नोएसक्यूएल विकल्प बेहतर हो सकता है - जैसे वितरित मोंगोडीबी क्लस्टर।

+0

आम तौर पर, मेटा-डेटा को स्टोर करना उचित है जहां भारी गणना तेजी से चलती है? सत्य के अनाज के लिए –

1

यह एक डेटा इंजन सवाल यह है, मुझे विश्वास है, के रूप में ज्यादा के रूप में यह एक वेब सर्वर-वितरण सवाल है। आपका (केंद्रीय) डेटाबेस इंजन गणना क्यों नहीं कर सकता (जल्दी से पर्याप्त)?

आप precalculated मूल्यों जो बासी के रूप में चिह्नित किये जाते हैं जब अंतर्निहित डेटा बदल रहे हैं, एक recalc की आवश्यकता होती है संग्रहीत कर सकती है। डेटा बदलने पर रिकॉल करने की ज़रूरत नहीं है। आपको केवल यह प्रबंधित करने की आवश्यकता है कि परिवर्तन कब और कैसे होता है क्योंकि यह डेटा के उपभोक्ताओं को प्रभावित करेगा।

+0

डेटाबेस में केवल कच्चा डेटा है। यह कच्चे डेटा से प्राप्त मेटा-डेटा को पकड़ने के लिए नहीं बनाया गया है। –

+1

मुझे नहीं लगता कि डेटा "मेटाडेटा" के आधार पर गणना कॉल करना उचित है। वह शब्द गुमराह हो सकता है। मेटाडेटा डेटा के बारे में डेटा है, डेटा से प्राप्त डेटा नहीं। किसी भी मामले में, डेटा इंजन आईएमओ प्रश्न को हल करने के लिए उचित और सरल जगह है। डेटा इंजन में कम्प्यूटेशनल क्षमता है और डेटाबेस संरचना एक्स्टेंसिबल है। विकल्प एक जटिल योजना है जहां डेटा के ग्राहक उपभोक्ता एक परिवर्तन-प्रकाशन सेवा की सदस्यता लेते हैं, ताकि वे कोर डेटासेट की स्थानीय वितरित प्रतियों को रीफ्रेश कर सकें। – Tim

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

  • कोई संबंधित समस्या नहीं^_^