स्मॉलटाक/समुद्रतट में डेटा दृढ़ता

Question

मैं हाल ही में स्मॉलटाक और समुद्रतट से परिचित होने में कुछ समय बिता रहा हूं। मैं जावा ईई दुनिया से आ रहा हूं और जैसा कि आप कल्पना कर सकते हैं कि कुछ छोटे-छोटे अवधारणाओं के आस-पास मेरे दिमाग को चुनौती देना चुनौतीपूर्ण रहा है। :)

फिलहाल मैं समझ कैसे डेटा हठ सबसे आम तौर पर स्मालटाक दुनिया में कार्यान्वित किया जाता है कोशिश कर रहा हूँ। जावा प्रोग्रामर के रूप में मेरे लिए धारणा आरडीएमएस (यानी MySQL) और ओआरएम (यानी हाइबरनेट) का उपयोग करना है। मैं समझता हूं कि स्मॉलटाक (कम से कम हाइबरनेट का उपयोग करके) का मामला नहीं है। मैं आवश्यक रूप से उस विधि की तलाश नहीं कर रहा हूं जो जावा ईई में किए गए तरीके से सबसे नज़दीकी से नक्शा रखता है।

यह सबसे सामान्य छवि, एक वस्तु की दुकान या RDMS में डेटा को बचाने के लिए है? क्या यह आरडीएमएस का उपयोग करने के लिए स्मॉलटाक ऐप्स के लिए भी सामान्य है?

मैं समझता हूँ कि वहाँ कोई एक आकार फिट-सब यहाँ दृष्टिकोण और सही हठ रणनीति आवेदन (कितना डेटा, संगामिति, आदि) की जरूरतों पर निर्भर करेगा है। एक अच्छा दृष्टिकोण क्या है जो सरल लेकिन स्केल भी शुरू कर सकता है?

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

आशा है कि मैंने यह टीएलडीआर नहीं बनाया है। अंतर्दृष्टि के लिए बहुत धन्यवाद, आप छोटे-छोटे लोगों ने मेरे पिछले प्रश्नों में प्रदान किया है। यह सराहना की है।

Answer 1

जस्टिन,

चिंता मत करो, स्मालटाक इस क्षेत्र में इतने अलग रूप अन्य भाषाओं नहीं है, यह सिर्फ छवि आधारित दृढ़ता विकल्प कहते हैं।

वहाँ हे स्मालटाक, GLORP और उसके Pharo बंदरगाह DBXtalk के लिए हाइबरनेट की तरह/आर मानचित्रकारों कर रहे हैं सबसे लोकप्रिय लोगों में इन दिनों कर रहे हैं निश्चित रूप से। यदि आप हाइबरनेट जानते हैं तो इन्हें आपके लिए बहुत सहज महसूस करना चाहिए।

फिर ओमोड समाधान जैसे जेमस्टोन या मैग्मा डीबी या वीओएसएस और कई अन्य हैं जो आपको सभी ओ/आर-मैपिंग समस्याओं को पीछे छोड़ देते हैं। इनमें से अधिकांश स्मॉलटाक ऑब्जेक्ट्स को संग्रहीत करने के लिए काफी सीमित हैं, रंबी और अन्य भाषाओं में पुल प्रदान करने में जेमस्टोन अपवाद है।

वहाँ भी CouchDB, कैसेंड्रा, माल या दूसरों की तरह आधुनिक NoSQL डेटाबेस में स्मालटाक वस्तुओं को स्टोर करने के उपकरण हैं। यहां की चाल सिर्फ छोटे-छोटे ऑब्जेक्ट मानों का JSON स्ट्रीम और थोड़ा HTTP-अनुरोध करने का रूपांतरण है।

अंत में वहाँ अपना पूरा स्मालटाक छवि सहेजने का विकल्प है। मैं कहूंगा कि आप इसे उत्पादन वातावरण में कर सकते हैं, लेकिन यह कई लोगों के लिए इसे मानक या पसंदीदा तरीका नहीं है। आप इसे विकास में बहुत कुछ करते हैं, क्योंकि आप आसानी से एक छवि को सहेज सकते हैं और अगली बार अपने ऑब्जेक्ट को फिर से शुरू कर सकते हैं जब आप सहेजे गए थे।

तो बेस लाइन यह है: आपके द्वारा पता जाने वाले सभी स्टोरेज विकल्प स्मॉलटाक में भी उपलब्ध हैं, साथ ही एक अतिरिक्त।

जोआचिम

Answer 2

मुझे लगता है कि यह मूल रूप से कितना बड़ा अपने डीबी होने जा रहा है और लोड की किस तरह यह निपटने की जाएगी पर निर्भर करता है।

मेरे मामले में, मैंने कभी भी सभी ऐप्स डिस्क क्रमबद्धता के साथ छवि दृढ़ता का उपयोग किया है। अनिवार्य रूप से, आप अनुरोध पर ईंधन का उपयोग करके अपनी वस्तुओं को क्रमबद्ध करें।मेरे मामले में, मैं हर बार डेटा का एक महत्वपूर्ण टुकड़ा निपटाता हूं, साथ ही एक नियमित प्रक्रिया जो हर 24 घंटों में उन्हें क्रमबद्ध करती है। छवि स्वचालित रूप से हर 24 घंटों में भी सहेजी जाती है।

इस दृष्टिकोण का उपयोग करके मैंने लिखा सबसे बड़ा एप्लिकेशन 10 श्रमिकों की एक छोटी कंपनी और लगभग 50 फ्रीलांसरों की सभी व्यावसायिक प्रक्रियाओं को संभालने का काम कर रहा है जो हर साल डेढ़ साल तक इसका इस्तेमाल कर रहे हैं। वर्कलोड बहुत "बड़ी" है, इस बात को ध्यान में रखते हुए कि एप्लिकेशन हर समय बड़ी फाइलों से संबंधित है, लेकिन ऐप स्थिर और तेज़ रहा है। एक नए सर्वर पर स्विच करना और फारो छवि को अपडेट करना परियोजना को वापस मॉन्टिसेलो से प्राप्त करना और नवीनतम धारावाहिक "डेटाबेस" को पूरा करना उतना ही आसान था।

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

तो, यदि आपका ऐप काफी कम मात्रा में डेटा संभालता है, तो मैं या तो मेरा सरल दृष्टिकोण या SandstoneDB सुझाता हूं। यदि आपका ऐप बड़ी मात्रा में लेन-देन और डेटा से संबंधित है, तो मैं रत्न पर जाऊंगा।

बस मेरे दो सेंट।

Answer 3

रामन लियोन स्थिति, मूल रणनीतियों और उनके व्यापारिक रूप से in his blog post का वर्णन करता है।

मैं अपने सरल छवि आधारित दृढ़ता ढांचे के साथ शुरू करूंगा, जो मैं ported और फ़ारो 1.3 में उपयोग करता हूं। मारियानो मार्टिनेज पेक ने हाल ही में इसे ईंधन (एक ही लिंक) का उपयोग करने के लिए अनुकूलित किया। यह बहुत आसान है, नौकरी करता है, और मुझे अपनी छवि में खेलने के लिए और अधिक आत्मविश्वास देता है, यह जानकर कि अगर मैं इसे स्थायी रूप से नुकसान पहुंचाता हूं, तो मेरा पूरा डेटा सुरक्षित है। मैं बस डेटा फ़ोल्डर्स को नए छवि फ़ोल्डर में कॉपी करता हूं, अपने पैकेज लोड करता हूं, और मेरी सभी ऑब्जेक्ट नई छवि में जिंदा हैं।