एसक्यूएल बनाम नोएसक्यूएल एक इन्वेंट्री प्रबंधन प्रणाली के लिए

Question

मैं जावा आधारित वेब एप्लिकेशन विकसित कर रहा हूं। प्राथमिक उद्देश्य चैनल नामक कई वेबसाइटों पर बेचे जाने वाले उत्पादों के लिए सूची रखना है। हम इन सभी चैनलों के लिए प्रबंधक के रूप में कार्य करेंगे। हमें क्या चाहिए:

1. प्रत्येक चैनल के लिए सूची अद्यतन प्रबंधित करने के लिए पंक्तियां।
2. सूची तालिका जिसमें प्रत्येक चैनल पर आवंटन का सही स्नैपशॉट है।
3. कैश में सत्र आईडी और अन्य तेज़ पहुंच डेटा रखना।
4. विक्रेता अद्यतन एप को रखने के लिए डैशबोर्ड (एक्सएमपीपी) जैसे फेसबुक प्रदान करना।

समाधान मैं देख रहा हूँ postgres (एक समकालिक प्रतिकृति मोड में अब तक हमारे डाटाबेस), कैसेंड्रा, Redis, CouchDB और MongoDB तरह NoSQL समाधान कर रहे हैं।

मेरे कमी कर रहे हैं:

1. सूची अद्यतन नहीं खोया जा सकता है।
2. जॉब कतार क्रम में निष्पादित किया जाना चाहिए और अधिमानतः कभी खोया नहीं जाना चाहिए।
3. आसान/तेज़ विकास और भविष्य के रखरखाव।

मैं किसी भी सुझाव के लिए खुला हूं। अग्रिम में धन्यवाद।

Answer 1

इस एप्लिकेशन के लिए NoSQL सही नहीं है।

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

कोई कारण नहीं है कि आप दोनों का उपयोग नहीं कर सकते - संबंधपरक डेटाबेस में संबंधपरक डेटा रखें, और कुंजी/मूल्य भंडार में गैर-संबंधपरक डेटा रखें।

Answer 2

अपने बाधाओं को संबोधित करते:

1. अधिकांश NoSQL समाधान आप स्थिरता बनाम प्रदर्शन का एक विन्यास तालमेल दे। उदाहरण के लिए, मोंगो डीबी में, आप तय कर सकते हैं कि एक लिखना कितना टिकाऊ होना चाहिए। यदि आप चाहते हैं, तो आप अपने सभी प्रतिकृति सेट सर्वर पर fsync'ed होने के लिए लिख सकते हैं। दूसरी चरम पर, आप कमांड भेजना चुन सकते हैं और सर्वर की प्रतिक्रिया का इंतजार भी नहीं कर सकते हैं।

2. क्रम में नौकरी कतार निष्पादित करना एक आवेदन कोड मुद्दा प्रतीत होता है। मैं कहूंगा कि अधिकांश अनुप्रयोगों के लिए डीबी में एक टाइमस्टैम्प और order by प्रकार की क्वेरी करना चाहिए। यदि आपके पास एकाधिक एप्लिकेशन सर्वर हैं और आपकी कतारों को सही होने की आवश्यकता है, तो आपको truly distributed algorithm का उपयोग करना होगा जो ऑर्डर प्रदान करता है, लेकिन यह एक सामान्य आवश्यकता नहीं है, और यह वास्तव में बहुत मुश्किल है।

3. हम कुछ समय से मोंगोडीबी का उपयोग कर रहे हैं, और मुझे विश्वास है कि यह आपके ऐप विकास की गति को वास्तविक बढ़ावा देता है। रखरखाव में कोई बड़ा अंतर नहीं है, डेटा बनाए रखना एक दर्द है। स्कीमा नहीं होने से आपको लचीलापन (आलसी माइग्रेशन) जोड़ा जाता है, लेकिन यह अधिक विस्तृत है और कुछ देखभाल की आवश्यकता है।

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

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

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

Answer 3

1. प्रत्येक चैनल के लिए सूची अद्यतन प्रबंधित करने के लिए पंक्तियां।

यह आवश्यक रूप से डेटाबेस समस्या नहीं है। आप से बेहतर (उदा। RabbitMQ)

1. इन्वेंटरी तालिका जो प्रत्येक चैनल पर आवंटन की सही स्नैपशॉट है होना एक संदेश प्रणाली को देख सकता है।
2. कैश में सत्र आईडी और अन्य तेज़ पहुंच डेटा रखना।

सत्र डेटा शायद और अधिक (, आदि जैसे memcached, redis) कार्य के लिए उपयुक्त एक अलग डेटाबेस में रखा जाना चाहिए कोई एक आकार फिट सभी डीबी

है
1. विक्रेता को अद्यतन एप को रखने के लिए डैशबोर्ड (एक्सएमपीपी) जैसे फेसबुक प्रदान करना।

मेरी बाधाएं हैं: 1. सूची अद्यतन खो नहीं जा सकते हैं।

1. यह सुविधा आपके आवेदन के द्वारा प्रदान किया जाना चाहिए:

इस सवाल का जवाब देने 3 तरीके हैं। डेटाबेस गारंटी दे सकता है कि एक खराब रिकॉर्ड खारिज कर दिया गया है और वापस लुढ़का है, लेकिन गारंटी नहीं है कि प्रत्येक क्वेरी दर्ज की जाएगी। ऐप को यह समझने के लिए पर्याप्त स्मार्ट होना होगा कि कोई त्रुटि कब होती है और पुनः प्रयास करें।

कुछ डीबी स्टोर मेमोरी में रिकॉर्ड करते हैं और फिर मेमोरी को डिस्क पर फ्लश करते हैं, इससे बिजली की विफलता के मामले में डेटा हानि हो सकती है। (जैसे मोंगो जब तक आप जर्नलिंग सक्षम डिफ़ॉल्ट रूप से इस तरह से काम करता है। CouchDB हमेशा रिकॉर्ड (यहां तक ​​कि एक हटाना एक झंडा रिकॉर्ड के साथ जोड़ दिया तो डेटा हानि बेहद मुश्किल है है) करने के लिए संलग्न कर देता है)

कुछ डीबीएस अत्यंत होने के लिए तैयार कर रहे हैं भरोसेमंद, यहां तक ​​कि भूकंप, तूफान या अन्य प्राकृतिक आपदाओं पर हमला करते हैं, वे टिकाऊ रहते हैं। इनमें कैसंद्रा, हबेस, रीक, हाडोप, आदि शामिल हैं

किस प्रकार की स्थायित्व आप का जिक्र कर रहे हैं?

1. नौकरी कतार क्रम में निष्पादित किया जाना चाहिए और अच्छा होगा यदि कभी नहीं खो दिया है।

अधिकांश नोएसक्यूएल समाधान समानांतर में चलना पसंद करते हैं। तो आपके पास यहां दो विकल्प हैं। 1. उपयोग एक डीबी कि प्रत्येक क्वेरी के लिए पूरे तालिका ताले (धीमा) 2. निर्माण अपने अनुप्रयोग होशियार या evented (क्लाइंट साइड अनुक्रमिक कतार) होने के लिए

1. आसान/फास्ट विकास और भविष्य के रखरखाव।

आम तौर पर, आप पाएंगे कि एसक्यूएल पहली बार में तेजी से विकसित करने के लिए है, लेकिन परिवर्तन NoSQL थोड़ा और योजना बनाने की आवश्यकता हो सकती है लागू करने के लिए कठिन हो सकता है, लेकिन तदर्थ प्रश्न या स्कीमा परिवर्तन करना आसान है।

सवाल आप शायद अपने आप से पूछना करने की जरूरत है और अधिक की तरह:

1. "मैं तीव्र प्रश्नों या गहरे विश्लेषण है कि एक नक्शा/कम की आवश्यकता होगी बेहतर के लिए अनुकूल है?"

2. "मैं अपने परिवर्तन मेरी स्कीमा अक्सर?

3. करने की आवश्यकता होगी" मेरे डेटा अत्यधिक रिलेशनल है? किस तरह से? "

4. " "

5. " मैं इस तरह के भू-स्थानिक अनुक्रमण, पूर्ण पाठ खोज के रूप में विशेष सुविधा की आवश्यकता होगी करता है मेरी पीछे विक्रेता चुना डीबी मेरी मदद करने के लिए जब मैं इसे जरूरत के लिए पर्याप्त अनुभव है?, आदि? "

6. " रीयलटाइम के करीब मुझे अपने डेटा की आवश्यकता होगी? अगर मुझे 1sec बाद तक मेरे प्रश्नों में नवीनतम रिकॉर्ड दिखाई नहीं दे रहे हैं तो क्या इससे चोट लगी है? विलंबता का स्तर क्या स्वीकार्य है? "

7. " क्या मैं वास्तव में करने के मामले में की आवश्यकता है असफल ओवर "

8. " मेरे डेटा कितना बड़ा है? क्या यह स्मृति में फिट होगा? क्या यह एक कंप्यूटर पर फिट होगा? क्या प्रत्येक व्यक्तिगत रिकॉर्ड बड़ा या छोटा है?

9. "मेरा डेटा कितनी बार बदल जाएगा? क्या यह एक संग्रह है?"

आप एक से अधिक ग्राहकों के लिए जा रहे हैं (चैनलों?) अपने स्वयं के सूची स्कीमा के साथ प्रत्येक, एक दस्तावेज के आधार डीबी यह लाभ हो सकता है। मुझे याद है कि एक बार मैंने सूची के साथ एक ईकॉमर्स सिस्टम देखा और इसकी लगभग 235 टेबल थीं! फिर, यदि आपके पास कुछ संबंधपरक डेटा है, तो SQL समाधान में वास्तव में कुछ फायदे भी हो सकते हैं।

मैं निश्चित रूप से देख सकता हूं कि मैं दिए गए बाधाओं के साथ मोंगो, सोफे, दंगा या ओरिएंटब का उपयोग करके समाधान कैसे बना सकता हूं। लेकिन किसके लिए सबसे अच्छा है? मैं सीधे डीबी विक्रेताओं से बात करने की कोशिश करता हूं, और शायद nosql टेप