अमेज़न जैसी कंपनी डेटाबेस लेयर तक पहुँचने में आने वाली अड़चनों से कैसे बचती है?

Question

यदि आप अमेज़ॅन (या किसी अन्य बड़े ई-कॉमर्स वेब एप्लिकेशन) जैसी कंपनी की कल्पना करते हैं, जो बड़े पैमाने पर एक ऑनलाइन स्टोर संचालित कर रहा है और केवल उसके गोदामों में भौतिक वस्तुओं की सीमित मात्रा है, तो वे इसे कैसे अनुकूलित कर सकते हैं, ऐसा नहीं है सिंगल टोंटी? बेशक, उनके पास प्रतिकृति के साथ कई डेटाबेस होने चाहिए, और कई सर्वर जो लोड को स्वतंत्र रूप से संभाल रहे हैं। हालांकि, यदि कई उपयोगकर्ताओं को अलग-अलग सर्वरों द्वारा सेवा दी जा रही है और दोनों एक ही आइटम को अपनी कार्ट में जोड़ने का प्रयास करते हैं, जिसके लिए केवल एक ही शेष है, तो उस आइटम के लिए छोड़ी गई मात्रा के लिए कुछ "सत्य का स्रोत" होना चाहिए। क्या इसका मतलब यह नहीं होगा कि बहुत कम से कम, किसी एक आइटम के लिए उत्पाद जानकारी एक्सेस करने वाले सभी उपयोगकर्ताओं को सीरियल में एक ही डेटाबेस को क्वेरी करना होगा?

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

Comments

2000 के मध्य में अमेज़न वास्तुकला (अभी भी आपके प्रश्न के लिए प्रासंगिक है): highscalability.com/amazon-altecture

— Joeri Sebrechts

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

— रेमकोगर्लिच

@RemcoGerlich: जिस तरह से आप कहते हैं "एक अंतिम सत्य डेटाबेस" मुझे इस पर बड़े पवित्र डेटाबेस के साथ एक मशीन के बारे में सोचता है। वास्तव में, महत्वपूर्ण डेटा के लिए क्या होता है बल्कि यह है कि सभी लेनदेन एक साथ कई सर्वरों तक पहुंचते हैं, यह सुनिश्चित करते हुए कि सभी डेटाबेस हर समय सिंक में हैं।

— आर्सेनी मूरज़ेंको

Answer 1

हालाँकि, यदि कई उपयोगकर्ताओं को अलग-अलग सर्वरों द्वारा परोसा जा रहा है और दोनों एक ही आइटम को अपनी कार्ट में जोड़ने का प्रयास करते हैं, जिसके लिए केवल एक ही शेष है, तो उस आइटम के लिए छोड़ी गई मात्रा के लिए कुछ "सत्य का स्रोत" होना चाहिए।

ज़रुरी नहीं। यह एक समस्या नहीं है जिसके लिए 100% सही तकनीकी समाधान की आवश्यकता होती है, क्योंकि दोनों त्रुटि मामलों में एक व्यावसायिक समाधान है जो बहुत महंगा नहीं है:

• यदि आप किसी उपयोगकर्ता को किसी वस्तु को बेचे जाने को गलत बताते हैं, तो आप एक बिक्री खो देते हैं। यदि आप हर दिन लाखों आइटम बेचते हैं और यह दिन में एक या दो बार होता है, तो यह शोर में खो जाता है।
• यदि आप एक आदेश स्वीकार करते हैं और इसे संसाधित करते समय यह पाते हैं कि आप आइटम से बाहर भाग चुके हैं, तो आप ग्राहक को बस इतना बताएं और जब तक आप आदेश को रद्द या रद्द नहीं कर सकते, तब तक उन्हें प्रतीक्षा करने का विकल्प दें। आपके पास थोड़ा परेशान ग्राहक है। जब 99.99% ऑर्डर ठीक काम करते हैं, तो एक बड़ी समस्या नहीं है।

वास्तव में, मैंने हाल ही में खुद ही दूसरे मामले का अनुभव किया है, इसलिए यह काल्पनिक नहीं है: यही होता है और अमेज़ॅन इसे कैसे संभालता है।

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

Comments

पैट हेलंड की यादें, अनुमान और माफी भी क्विकसैंड पर बिल्डिंग में शामिल हैं और लेनदेन की भरपाई यहां प्रासंगिक विचार हैं।

— डेरेक एलकिंस

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

— मटमैग्जाम 1990

@ Mattgmg1990: सही है, आखिरकार आपको कहीं न कहीं "सच्चाई" को जानना होगा, लेकिन महत्वपूर्ण अंतर यह है कि आदेशों का प्रसंस्करण एक कतार में किया जा सकता है, इसलिए आपको समवर्ती परमाणु लेखन की आवश्यकता नहीं है। मेरे मामले में, "त्रुटि संदेश" वास्तव में घंटों बाद आया जब मैंने अमेज़ॅन वेबसाइट पर आदेश समाप्त किया - मुझे एक ईमेल मिला जिसमें कहा गया था कि उन्हें उस वस्तु की आपूर्ति में समस्या है और मैं आदेश को रद्द करने या कुछ भी नहीं करने और प्रतीक्षा करने का विकल्प चुन सकता हूं। उन्हें पूरा करने के लिए। मैंने बाद में किया क्योंकि मुझे तुरंत आइटम की आवश्यकता नहीं थी, और उन्होंने वास्तव में इसे कई सप्ताह बाद दिया।

— माइकल बोर्गवर्ड

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

— माइकल बोर्गवर्ड

Answer 2

का संयोजन

• हैशिंग
• sharding
• प्रतिकृति
• वितरण
• फेल-ओवर
• की-वैल्यू स्टोर

कोई जादू नहीं है, बस अधिक से अधिक जटिल स्थितियों। डीएनएस की तरह ही इसे पैमाना बनाया जाता है।

The सत्य का एकल संस्करण ’ऐसी प्रणालियों का हिस्सा है। एक नई कुंजी उत्पन्न करना अनुक्रम में अगले नंबर को उत्पन्न करने की तुलना में अधिक जटिल ऑपरेशन बन जाता है। उदाहरण के लिए अन्य क्रम मौजूद हैं। यह उस प्रकार की जटिलता है जो वितरित डेटाबेस सिस्टम को संभाल सकती है और वे नई वस्तुओं को बनाते समय और घटकों से कई ऑपरेशन करके, उन्हें दूसरों को उपलब्ध कराते हुए सुनिश्चित करते हैं कि यह सुनिश्चित करना कि अनुक्रम अद्वितीय हैं जब उन्हें होना चाहिए, समग्र कुंजी, आदि। ।

Comments

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

— १90 पर मैटगाम १

थोड़ा और जोड़ा। मैं वास्तव में इस प्रारूप में शामिल सभी जटिलता की व्याख्या नहीं कर सकता, क्षमा करें।

— माइकल डुरंट

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

— बसिलेव्स

मुझे लगता है कि जिस परिदृश्य में आप सिस्टम का वर्णन कर रहे हैं, उसे केवल उस उपयोगकर्ता से माफ़ी मांगनी होगी, जिसे किसी और ने अंतिम प्रति खरीदी थी। मुझे लगता है कि यह समय-समय पर होता है।

— मैथ्यू जेम्स ब्रिग्स

मैं शर्त लगाता हूं कि केवल 5 पुस्तकें ही शेष हैं जो कम कंप्यूटिंग और अधिक विपणन है।

— मौविसील

Answer 3

मैंने 'लास्ट आइटम इन स्टॉक' समस्या को निम्न तरीके से हल किया है:

थ्रेशोल्ड स्तरों के अनुसार सभी स्टॉक स्तरों को दैनिक और फ्लैग उत्पादों को उच्च, निम्न, ऑर्डर पर या स्टॉक श्रेणियों से बाहर अपडेट करें।

स्पष्ट रूप से इसकी 'कम स्टॉक' वाली वस्तुएं जो समस्याग्रस्त हैं

• उच्च स्टॉक स्तरों के साथ आइटम

स्टॉक स्तर की जाँच करने की जहमत न उठायें। बस आदेश जगह है

• कम स्टॉक के स्तर वाले आइटम

'अंतिम कुछ बचे!' ब्राउज़ करते समय उपयोगकर्ता को चेतावनी दें। जब वे भुगतान करने के लिए जाते हैं, तो स्टॉक स्तर की जांच करें और घटाएं। यदि इसका स्टॉक खत्म हो गया है, तो आइटम की स्थिति अपडेट करें।

इस तरह से आप केवल 'कम स्टॉक' वस्तुओं के लिए डेटाबेस को हिट करते हैं और आप केवल तब करते हैं जब ग्राहक खरीदने की प्रक्रिया से काफी दूर होता है। लागत यह है कि कुछ ग्राहक अपनी खरीद को पूरा करने में सक्षम नहीं होंगे।

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

बिक्री जैसे उच्च लोड समय के दौरान, आप स्टॉक की जाँच बंद कर सकते हैं और बाद में ग्राहकों को ईमेल कर सकते हैं, 'क्षमा करें कि हम X से बाहर भाग गए, क्या आप Y पसंद करेंगे'

अनिवार्य रूप से किसी भी ईकॉमर्स प्लेटफॉर्म का उद्देश्य डेटाबेस से कभी नहीं पढ़ा जाता है। हमेशा कैश्ड पृष्ठों की सेवा करें और सब कुछ क्लाइंट की तरफ करें।

Answer 4

इस वीडियो में, मार्टिन फाउलर NoSQL डेटाबेस पर चर्चा करता है:

https://www.youtube.com/watch?v=qI_g07C_Q5I

बिंदुओं में से एक (कहीं न कहीं), यह है कि अमेज़ॅन जैसी जगहें 99% लोगों को खुश रखेंगी, लेकिन उनके आदेश को बिना जांचे-परखे, "वास्तव में उपलब्ध है", या हो सकता है कि वह बहुत कम प्रतिशत से परेशान हो। कहने के लिए "क्षमा करें, ऐसा लगता है कि किसी ने आपको इसे हराया है।"

जो कहना है, आपके द्वारा वर्णित परिदृश्य के लिए कोई वास्तविक हैंडलिंग नहीं है, बस यह है कि अमेज़ॅन अंतिम सफल इन्वेंट्री पढ़ने के आधार पर संदेह का लाभ उठाता है, और यदि एक समवर्ती लेनदेन बीच में फिसल जाता है।

(btw, यह एक बढ़िया वीडियो है अगर आप NoSQL के बारे में उत्सुक हैं)