मुख्य मूल्य प्रारूप में 3 मिलियन रिकॉर्ड कैसे स्टोर करें?

Question

हमें 3 मिलियन उत्पादों के बारे में बुनियादी जानकारी संग्रहीत करनी होगी। वर्तमान में जानकारी एक 180 mb CSV है जो त्रैमासिक रूप से अद्यतन की जाती है।

प्रति दिन लगभग 30,000 प्रश्न होंगे, लेकिन प्रश्न केवल एक बहुत ही सरल कुंजी मूल्य स्टोर हैं। हमें केवल उत्पाद आईडी देखने और बाकी जानकारी प्रदर्शित करने की आवश्यकता है (जो सभी एक ही रिकॉर्ड में होगी)।

यह वेब के लिए है, इसलिए तेज़ प्रदर्शन महत्वपूर्ण है।

क्या हमें MySQL का उपयोग करना चाहिए, भले ही हमें वास्तव में रिलेशनल डेटाबेस की आवश्यकता न हो? क्या हमें हर तिमाही में केवल 3 मिलियन स्टैटिक html फाइल्स जेनरेट करनी चाहिए? क्या हमें Amazon S3 या Rackspace Cloud Files जैसी किसी चीज़ पर प्रत्येक उत्पाद के लिए एक लाइन CSV स्टोर करनी चाहिए? इसे करने का बेहतरीन तरीका क्या है?

Answer 1

क्योंकि MySQL को इतना व्यापक रूप से समर्थन प्राप्त है और यह वास्तव में काफी तुच्छ बात है कि मैं इसके साथ जाने का सुझाव दूंगा। जब तक सर्वर में कम से कम कुछ जीबी मेमोरी न हो, मैं इन-मेमोरी सिस्टम का उपयोग करने के बजाय MySQL के साथ चिपके रहने का सुझाव दूंगा।

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

आप जो भी करते हैं, उन तीन मिलियन फ़ाइलों को न बनाएं। हमने कई प्रश्नों को देखा है जिनके परिणामस्वरूप पहले से ही इतनी सारी फाइलें बनती हैं।

Answer 2

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

• रेडिस - रेडिस एक ओपन सोर्स, एडवांस्ड की-वैल्यू स्टोर है। इसे अक्सर डेटा संरचना सर्वर के रूप में संदर्भित किया जाता है क्योंकि कुंजियों में तार, हैश, सूची, सेट और सॉर्ट किए गए सेट हो सकते हैं।
• MemcacheDB - MemcacheDB एक वितरित की-वैल्यू स्टोरेज सिस्टम है जिसे लगातार बनाया जाता है।
• अन्य (ऐसी सूचियों में से एक यहाँ देखी जा सकती है: http://nosql-database.org/ )

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

Comments

हम रेडिस का उपयोग कर सकते हैं, लेकिन क्या आपको लगता है कि यह पी 4 पर 2 गीगा रैम के साथ काम करेगा?

— फिल

@ आपकी CSV फ़ाइल को ध्यान में रखते हुए 180MB के आसपास है - ठीक होना चाहिए। हालाँकि हमने लगभग 200K रिकॉर्ड और सर्वर के साथ एक प्रोजेक्ट में (केवल एक बार अब तक) इसका उपयोग किया था और इसमें 8GB रैम थी इसलिए मेरी तुलना करना मुश्किल है।

— लाजोवन

Answer 3

और अब पूरी तरह से अलग कुछ करने के लिए:

दिया हुआ:

• 180MB / 3M उत्पाद = 62 बाइट्स / उत्पाद औसतन।
• प्रति दिन 30,000 प्रश्न = 0.34 प्रश्न प्रति सेकंड
• त्रैमासिक = अनिवार्य रूप से स्थिर डेटा अपडेट किया गया

बॉक्स समाधान के बाहर:

प्रत्येक उत्पाद को TXT संसाधन रिकॉर्ड के रूप में डंप करें और इसे DNS, जैसे: में संग्रहित करें।

$origin products.example.com.

product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"

लाभ:

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

कारण यह एक बुरा विचार हो सकता है:

• आपको डेटा खोजने की जरूरत है (DNS विशुद्ध रूप से कुंजी / मूल्य खोज है)
• आपको डेटा छिपाने की आवश्यकता है (DNS में कोई गोपनीयता नहीं है)

Comments

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

— मार्टिन विलकंस

मेरे साथ षड्यंत्र रचा गया। मैं वास्तव में इस विचार को वास्तव में पसंद करता हूं, लेकिन मेरे लिए, मैं काउचबीडी की तरह कुछ और कोशिश / परीक्षण किया जाऊंगा

— टॉम ओ'कॉनर

कुछ मोंटी अजगर देख रहा है?

— मार्क हेंडरसन

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

— थियोब्रोमा काकाओ जूल

यहां कैप्टन हिंडाइट। एक शब्द: ब्लॉकचेन।

— डेटशमैन

Answer 4

MySQL के साथ MySQL और कुछ अच्छे इंडेक्स इसके लिए परफेक्ट लगते हैं। पाठ्यक्रम के कई अन्य विकल्प हैं, लेकिन MySQL बहुत व्यापक रूप से (यदि सार्वभौमिक नहीं है) किसी व्यावसायिक वेब होस्ट पर समर्थित है। आपके द्वारा आवश्यक गति के आधार पर, मेमकास्ट भी देखने लायक हो सकता है , लेकिन प्रत्येक कुंजी / मान युग्म के आकार को जाने बिना, उनमें से 3 मिलियन मेमोरी में स्टोर करना 180Mb CSV फ़ाइल (ओह प्रतीक्षा) की तुलना में और भी बुरा विचार हो सकता है, यह है 180Mb CSV फ़ाइल है, इसलिए हम जानते हैं कि वे कितनी बड़ी हैं। वे बहुत छोटे जोड़े होने चाहिए, इसलिए मेमस्कैड बेहतर हो सकता है)।

आप 3 मिलियन स्टैटिक HTML फाइल्स नहीं चाहते हैं, यह आपके फाइल सिस्टम को बुरी तरह प्रभावित करेगा। एक लाइन CSV, यहां तक ​​कि S3 पर भी यही समस्या है। कोई भी एक फ़ोल्डर में 3 मिलियन फाइलें नहीं चाहता है।

Comments

वे बहुत छोटे जोड़े हैं ... यह मूल्य, निर्माण की तारीख, गोदाम की संख्या, आदि जैसे बहुत ही बुनियादी डेटा है। 10 से कम कॉलम। तो आपको लगता है कि MySQL वास्तव में जाने का रास्ता है? यह जिस सर्वर पर चलने वाला है, वह एक पी 4 है जिसमें 2 गीगा रैम है- मुझे लगता है कि यह ठीक होना चाहिए?

— फिल

@Phil - So you think MySQL is the way to go, really?- नहीं, वास्तव में नहीं, लेकिन यह बहुत लचीला है और जैसा कि मैंने उल्लेख किया है, लगभग सार्वभौमिक रूप से समर्थन किया है। हालाँकि LazyOne ने ऊपर कुछ अच्छे विकल्प पोस्ट किए हैं। मुझे NoSQL शब्द याद नहीं है, लेकिन यह मेरे दिमाग में कहीं घूम रहा था

— मार्क हेंडरसन

Answer 5

आप बर्कले डेटाबेस का उपयोग कर सकते हैं जो वास्तव में इस तरह का काम करता है, भले ही वह पर्ल 5 की सुबह से ही कूल्हा न हो। बर्कले केवल प्रमुख मूल्य जोड़े का समर्थन करता है, और आप पूरे डीबी को एक हैश से बाँधते हैं और इसे इस तरह एक्सेस करते हैं।

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

Comments

BDB पुरानी खोपड़ी है लेकिन इस स्थिति के लिए बहुत प्रभावी और उपयुक्त है।

— Womble

Berkely DB en.wikipedia.org/wiki/Sleepycat_license के लिए लाइसेंस से सावधान रहें इसके लिए सभी स्रोत कोड उपलब्ध कराने की आवश्यकता है न कि केवल डीबी भाग।

— वोल्फमैन जेएम

Answer 6

आपने अपने प्रश्न को amazon S3 के रूप में चिह्नित किया है।

मैं अमेज़ॅन सिम्पलबीडीबी नामक उनके अन्य संबंधित उत्पादों में से एक पर आपका ध्यान आकर्षित करना चाहता हूं।
ऐसा लगता है कि SimpleDB डेटा मॉडल आपके प्रकार के एप्लिकेशन के साथ अच्छी तरह से फिट होगा।

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

एसडीबी डेटा मॉडल एक स्प्रेडशीट जैसा दिखता है।

इसके बारे में अधिक जानकारी के लिए यहां देखें: http://aws.amazon.com/simpledb/ और डेटा मॉडल: http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/

Comments

SimpleDB महंगा है। बहुत सारे मामलों में, दर्दनाक रूप से।

— टॉम ओ'कॉनर

Answer 7

भले ही 180mb डेटा आसानी से किसी भी संबंधपरक डेटाबेस द्वारा नियंत्रित किया जा सकता है, मैं अत्यधिक MongoDB की सिफारिश करूंगा ( http://www.mongodb.org/) की) MySQL, Redis, MemcacheDB और अन्य सरल कुंजी-मूल्य स्टोर या रिलेशनल डेटाबेस से ऊपर। इसका कारण यह है कि इस तरह की समस्या के लिए, MongoDB सबसे तेज़, सबसे अधिक अभिव्यंजक प्रणाली का उपयोग करने के लिए है, बिना किसी स्कीमा प्रतिबंध के साथ सुपर फास्ट डायनेमिक अपडेट की अनुमति देता है, इसलिए यदि आप उन्हें पसंद करते हैं तो आपके दस्तावेज़ों के अलग-अलग प्रारूप हो सकते हैं। मैं दूसरे दिन guardian.co.uk की एक प्रस्तुति में था और उन्होंने सभी रिलेशनल डेटाबेस को प्रतिबंधित करने और अपनी ख़बर परोसने के लिए MongoDB का विशेष रूप से उपयोग करने का नीतिगत निर्णय लिया है। आप महसूस कर सकते हैं कि उनकी वेबसाइट कितनी तेज़ है और जो 1995 से ऑनलाइन है (यूके में सबसे पुराना ऑनलाइन अखबार)। वे रिलेशनल डेटाबेस के कारण अतीत में सभी प्रकार की अड़चनों से गुज़रे हैं। 180mb के लिए, MongoDB इन-मेमोरी से सब कुछ परोसने वाला है, इसलिए सब-एमएस लोडिंग समय के मामले में होने की संभावना है।

Answer 8

प्रति दिन लगभग 30,000 प्रश्न होंगे, लेकिन प्रश्न केवल एक बहुत ही सरल कुंजी मूल्य स्टोर हैं। हमें केवल उत्पाद आईडी देखने और बाकी जानकारी प्रदर्शित करने की आवश्यकता है (जो सभी एक ही रिकॉर्ड में होगी)।

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

मैं कहने की हिम्मत बहुत कुछ ठीक होगा। आपका लोड 30000 प्रश्नों / दिन का मतलब है (यह मानते हुए कि आपका लोड पूरे दिन स्थिर है) आपके पास प्रत्येक 20 सेकंड में एक ही क्वेरी है; ये इतना बुरा नहीं है।

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

Answer 9

ऐसा करने का सबसे अच्छा तरीका वास्तव में आपके डेटा और प्रश्नों की गुणवत्ता और प्रकृति पर निर्भर करता है। शुरुआत के लिए, उत्पादों के लिए एक ही तालिका में 180MB डेटा कोई समस्या नहीं है, जो भी आप इसे देखते हैं। और प्रति दिन 30k प्रश्न एक समस्या से भी कम है। ठीक से कॉन्फ़िगर किए गए डेटाबेस के साथ, कोई भी पुराना डेस्कटॉप इस लोड को संभाल सकता है।

अन्य लोगों ने पहले ही आपके दो प्रमुख विकल्प, MySQL या noSQL डेटाबेस को इंगित किया है।

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

यदि विशेषताओं की उपस्थिति और डेटा प्रकार में व्यापक रूप से भिन्नता है, तो आप noSQL डेटाबेस का उपयोग करने में बेहतर हो सकते हैं, जो इस परिदृश्य को पारंपरिक SQL डेटाबेस की तुलना में अधिक कुशल बनाते हैं।

प्रदर्शन के बारे में: मैंने पहले एक ई-कॉमर्स कंपनी के लिए काम किया है, जहां एक लंबे समय के लिए वेबसाइट को एक MySQL सर्वर से डेटा प्रदान किया गया था। इस सर्वर में 2GB RAM था, कुल मिलाकर डेटाबेस लगभग था। आकार में 5GB और शीर्ष लोड के तहत सर्वर ने प्रति सेकंड कई हजार प्रश्नों को संभाला। हां, हमने काफी क्वेरी ऑप्टिमाइज़ेशन किया था, लेकिन यह निश्चित रूप से उल्लेखनीय है।