2012-09-19 35 views
11

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

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

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

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

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

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

तो इन 3 (या यहां तक ​​कि अन्य जो भी आपको लगता है बेहतर हो सकता है) के बीच, ग्राहक लेनदेन से निपटने के दौरान, ईकॉमर्स आधारित साइट के संबंध में प्रत्येक में कौन सी सुविधाएं संभावित रूप से काम कर सकती हैं या मेरे खिलाफ काम कर सकती हैं?

संपादित करें: कारण मैं एक मौजूदा समाधान का उपयोग नहीं कर रहा हूँ, क्योंकि एकीकृत सुविधाओं की आवश्यकता के साथ, वहाँ कोई समाधान उपलब्ध वहाँ बाहर हो रहा है। हम इसे हमारी कंपनी के लिए एक पूर्ण उत्पाद के रूप में उपयोग करने का भी लक्ष्य रख रहे हैं। केवल बिक्री की तुलना में कुछ अन्य एकीकरण होगा। यह एक स्टोर के पीओएस सिस्टम के साथ काम करने जा रहा है।

+0

एसक्यूएल + सोलर/लोचदार खोज पर जाएं। एसक्यूएल मध्यम क्वेरी/लिखने की दर, डेटा सुरक्षा और लेनदेन सुरक्षा के लिए (जो दो डीबी नोड्स को दो अलग-अलग लोगों को एक ही चीज़ बेचने के लिए चाहता है?)। और लचीला (या नहीं) स्कीमा के लिए सोलर/लोचदार खोज, बहुत सक्षम विज्ञापन-संबंधी प्रश्न और खोज करने के लिए वास्तव में तेज़। आप संभवतः प्रत्येक रात एक फ़ाइल में अपने एसक्यूएल डीबी का बैक अप ले सकते हैं। – aitchnyu

+0

@aitchnyu मुझे यकीन नहीं है कि आप एसक्यूएल के उपयोग को उचित ठहराना चाहते हैं। "दो डीबी नोड्स एक ही चीज़ को दो अलग-अलग लोगों को बेचने के लिए" का क्या मतलब है? – Sammaye

+1

एक ओपन-सोर्स ई-कॉमर्स प्लेटफॉर्म है जो मोंगोडीबी का उपयोग करता है। इसे देखें: getfwd.com –

उत्तर

12

सदस्यता और आवर्ती सदस्यता के लिए के माध्यम से शॉपिंग कार्ट से सब कुछ शामिल कर सकते हैं के बाद से ई-कॉमर्स, उसका अनुमान लगाना आप वास्तव में क्या आवश्यकताओं और जटिलता envisioning कर रहे हैं मुश्किल है।

जब किसी ई-कॉमर्स साइट है, जल्दी विचार में से एक का निर्माण की जांच की जानी चाहिए पहले से ही है कि क्या वहाँ एक स्थापित ई-कॉमर्स उत्पाद या टूलकिट कि आपकी आवश्यकताओं को पूरा कर सकता है। यहां तक ​​कि जब आपके उपयोग के मामले सीधा हो गया लगता है आदेश, चालान, भुगतान, उत्पादों, और ग्राहक संबंधों की तरह प्रक्रियाओं के लिए कई बारीकियों रहे हैं। "बिलिंग" (संभावित रूप से तृतीय पक्ष, शायद यहां तक ​​कि होस्टेड बिलिंग/भुगतान API के माध्यम से) के विरुद्ध "एप्लिकेशन कैटलॉग प्रबंधन" पहलुओं (संभावित रूप से अधिक कस्टम) में अपना एप्लिकेशन अलग करना भी संभव हो सकता है।

एक और विचार यह होना चाहिए कि आप किसके लिए ई-कॉमर्स साइट विकसित कर रहे हैं: क्या यह आपके स्वयं के खुजली या ग्राहक के लिए खरोंच करना है? कस्टम बिल्ड के लिए समय, बजट और सुविधाएं अनुमान लगाना और शेड्यूल करना मुश्किल हो सकता है .. और तकनीक की एक विशिष्ट पसंद अतिरिक्त विकास विशेषज्ञता को ढूंढना/किराए पर लेना मुश्किल हो सकती है।

एक तीसरा विचार यह है कि आपकी पसंद के लिए आपकी भाषा की पसंद क्या है। कुछ भाषाओं में विभिन्न डेटाबेस के लिए अधिक पूर्ण/परिपक्व/दस्तावेज ड्राइवर और/या ढांचे के सार तत्व होंगे।

उस ने कहा, एक ई-कॉमर्स सिस्टम लिखना कई डेवलपर्स के लिए पारित होने का अनुष्ठान प्रतीत होता है ;-)। (घोषित इरादे से अन्य डेटाबेस का समर्थन करने के) एक नया खुला स्रोत ई-कॉमर्स MongoDB का उपयोग कर मंच -

  • Forward:

    विशेष रूप से MongoDB के लिए, आप इस पर गौर कर सकते हैं। वर्तमान में "निजी बीटा" के रूप में वर्णित है लेकिन जांच के लायक दिखता है (और स्पष्ट रूप से कुछ लाइव साइटों के लिए उपयोग किया जाता है)। मैंने देखा कि हाल ही में मोंगोडीबी ब्लॉग पर उल्लेख किया गया था: How MongoDB makes custom e-commerce easy

  • MongoDB and E-Commerce - केली बैंकर, मैनिंग पुस्तक MongoDB के लेखक कार्रवाई में से एक ब्लॉग पोस्ट। यह कुछ साल पुराना है, लेकिन डेटा मॉडलिंग विचारों पर कुछ रोचक चर्चा है; E-Commerce Inventory पर एक फॉलो-अप भी था। नोट: aggregation और reporting मोंगो डीबी के लिए उपलब्ध विकल्प उन पदों के बाद से काफी सुधार हुए हैं।

  • Perform Two-Phase Commits - MongoDB

    में बहु दस्तावेज़ अपडेट कर

मास्टर मास्टर प्रतिकृति (MVCC) तुम उल्लेख के लिए एक डिजाइन पैटर्न प्रतीत नहीं होता है जैसे कि यह ई-कॉमर्स के लिए एक प्रासंगिक सुविधा होगी , जहां आपको आम तौर पर निरंतर स्थिरता की बजाय मजबूत स्थिरता की आवश्यकता होगी। आप उपयोगकर्ता डेटाबेस को सिंक करने का जिक्र करते हैं, इसलिए शायद उस विशिष्ट आवश्यकता को ओपनआईडी जैसे एकल साइन-ऑन समाधान द्वारा बेहतर तरीके से संबोधित किया जा सकता है।

+0

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

+0

यह उसका स्वयं का उत्पाद और सेवा होगा जिसे हम किसी के लिए उपभोग करने के लिए उपलब्ध कराने की योजना बना रहे हैं। इसका उपयोग वास्तविक स्टोरफ्रंट और तब तक संबंधित व्यवसाय के लिए भी किया जाएगा जब तक कि कोई मित्र न हो। उत्पाद हम दोनों से एक विचार है स्टार्टअप के रूप में बनाने के लिए। अब तक, सिस्टम पायथन में लिखा जाएगा, क्योंकि एक डेस्कटॉप क्लाइंट को अंततः (पीओएस स्टोर में) करने की आवश्यकता होगी। मास्टर: मास्टर प्रतिकृति बस एक सुविधा है जो मैं स्टोर के लिए करना चाहता हूं अपने डेटा को ऑनलाइन सिंक करने के लिए, यदि कभी भी उनकी स्थानीय प्रणाली विफल हो जाती है। वे अन्य स्थानों पर स्टोर में नहीं होने पर सिस्टम से ऑनलाइन सिस्टम का उपयोग करने में सक्षम होना चाहिए। – skift

+0

हालांकि, मैं निश्चित रूप से लिंक की जांच करूँगा, धन्यवाद। – skift

2

विभिन्न उपलब्ध नोएसक्ल डेटाबेस here की तुलना की जांच करें। इसके अनुसार अपनी आवश्यकता सूट।