AWS SimpleDB

Question

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

मेरे मामले में हमें 1024 से 10K टेक्स्ट डेटा स्टोर करने की आवश्यकता है।

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

मेरे दिमाग में मुझे यकीन नहीं है कि सरल डीबी सही समाधान है या नहीं। क्या किसी ने इस समस्या के बारे में सोचने के लिए क्या किया है या एक अलग तरीका प्रदान करने पर टिप्पणी कर सकते हैं?

Answer 1

अपने 10k टेक्स्ट डेटा को स्टोर करने के तरीके हैं, लेकिन यह स्वीकार्य होगा कि आपको स्टोर करने की आवश्यकता है और आप इसका उपयोग करने की योजना कैसे बना सकते हैं।

यदि आपको मनमाने ढंग से बड़े डेटा (विशेष रूप से बाइनरी डेटा) को स्टोर करने की आवश्यकता है तो S3 फ़ाइल सूचक आकर्षक हो सकता है। इस परिदृश्य में SimpleDB जो मान जोड़ता है वह वह है जिसे आप SimpleDB में संग्रहीत फ़ाइल मेटाडेटा के विरुद्ध क्वेरी चलाने की क्षमता रखते हैं।

10k तक सीमित टेक्स्ट डेटा के लिए मैं इसे सरल डीबी में सीधे संग्रहीत करने की अनुशंसा करता हूं। यह आसानी से एक ही आइटम में फिट होगा लेकिन आपको इसे कई विशेषताओं में फैलाना होगा। कुछ ड्रॉ बैक के साथ इसे करने के लिए मूल रूप से दो तरीके हैं।

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

तथ्य यह है कि आपके पास एक विशेषता में संग्रहीत सभी पाठ एक प्रश्न के साथ प्रश्नों को आसान बनाता है भविष्यवाणी में विशेषता का नाम। आप प्रत्येक आइटम में 1k से 200 + के लिए कहीं भी एक अलग आकार टेक्स्ट जोड़ सकते हैं और इसे उचित तरीके से संभाला जाता है। लेकिन आपको यह पता होना चाहिए कि आपकी प्रीपेन्ड लाइन संख्याएं आपके प्रश्नों के लिए सकारात्मक हो सकती हैं (उदाहरण के लिए यदि आप 01 खोज रहे हैं तो प्रत्येक आइटम उस क्वेरी से मेल खाएगा)।

SimpleDB के भीतर पाठ को संग्रहीत करने का दूसरा तरीका आपको अपने टेक्स्ट भागों में मनमाने ढंग से ऑर्डर करने की आवश्यकता नहीं है। आप एक अलग नामित विशेषता में प्रत्येक पाठ खंड डालकर ऑर्डर करते हैं। उदाहरण के लिए आप विशेषता नामों का उपयोग कर सकते हैं: desc01desc02 ... desc10। फिर आप उचित विशेषता में प्रत्येक खंड डालते हैं। आप अभी भी दोनों विधियों के साथ पूर्ण पाठ खोज कर सकते हैं लेकिन खोज इस विधि के साथ धीमी हो जाएंगी क्योंकि आपको कई भविष्यवाणियों को निर्दिष्ट करने की आवश्यकता होगी और सरल डीबी प्रत्येक विशेषता के लिए एक अलग इंडेक्स के माध्यम से खोज समाप्त कर देगा।

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

यदि आपको पता चला कि एक रिलेशनल डेटाबेस आपके टेक्स्ट को 1k भाग में विभाजित करने के लिए डिस्क पर स्टोर करने के लिए एक कार्यान्वयन विस्तार के रूप में विभाजित कर रहा था, तो यह एक हैक जैसा प्रतीत नहीं होता है। समस्या यह है कि SimpleDB क्लाइंट की वर्तमान स्थिति ऐसी है कि आपको इस प्रकार के डेटा स्वरूपण को स्वयं लागू करना होगा। यह एक प्रकार का चीज है जो आदर्श रूप से आपके स्मार्ट क्लाइंट में संभाला जाएगा।अभी तक कोई स्मार्ट क्लाइंट मुफ्त में उपलब्ध नहीं हैं।

Answer 2

यदि आप लागत के बारे में चिंतित हैं, तो आप पाएंगे कि पाठ को एस 3 में डालने और सस्ता डीबी में पॉइंटर्स के साथ मेटाडेटा को सस्ता करना सस्ता है।

Answer 3

Simple Savant की आगामी रिलीज (मेरे द्वारा बनाई गई सरल डीबी के लिए सी # दृढ़ता लाइब्रेरी) म्यूकी द्वारा वर्णित विशेषता और ल्यूसीन.नेट का उपयोग करके सरल डीबी डेटा की पूर्ण-पाठ खोजों का समर्थन करेगा।

मुझे एहसास है कि आप संभवतः सी # में अपना ऐप नहीं बना रहे हैं, लेकिन जब से आपका प्रश्न एक सरल परिणाम है जब SimpleDB और पूर्ण-पाठ अनुक्रमण की खोज करना यह उल्लेखनीय लग रहा था।

अद्यतन: ऊपर वर्णित सरल सावन रिलीज अब उपलब्ध है।

Answer 4

आप एस 3 पर 10k टेक्स्ट डाल सकते हैं, फिर एक विशेषता बनाएं जिसमें 10k टेक्स्ट के सभी अद्वितीय शब्द एकाधिक मान के रूप में हों। फिर खोज तेज होगी। हालांकि कोई वाक्यांश खोज नहीं है।

आप एक 'पंक्ति' (नाम) में एक विशेषता में कितने मूल्य संग्रहीत कर सकते हैं? मैंने दस्तावेज़ों में देखा, मेरे पास कोई जवाब नहीं आया।

टॉम

Answer 5

SimpleDb है, ठीक है, सरल। इसमें सबकुछ एक स्ट्रिंग है। दस्तावेज़ीकरण बहुत सीधी है। और बहुत सारे उपयोग प्रतिबंधित हैं। जैसे:

• आप केवल IN में एक SELECT * FROM ___ WHERE ItemName() IN (...) 20 के साथ ItemName रों कर सकते हैं।
• आप एक समय में केवल PUT (अपडेट) से 25 रिकॉर्ड कर सकते हैं।
• सभी पढ़ना गणना समय पर आधारित हैं। तो यदि आप 1000 के साथ के साथ 800 (या यहां तक ​​कि कुछ भी नहीं) nextToken के साथ कुछ वापस कर सकते हैं जिसमें आपको अतिरिक्त अनुरोध करने की आवश्यकता है (nextToken के साथ)। इसका मतलब है कि अगले SELECT वास्तव में सीमा गणना वापस कर सकता है, इसलिए दो SELECT से लौटाई गई पंक्तियों की राशि आपकी मूल सीमा से अधिक हो सकती है। यदि आप बहुत कुछ चुन रहे हैं तो यह एक चिंता है। इसके अलावा, यदि आप SELECT COUNT(*) करते हैं तो आप एक समान समस्या को दबाएंगे। यह nextToken के साथ आपको एक गिनती वापस कर देगा। और आपको उन nextToken एस पर पुनरावृत्ति रखने की आवश्यकता है और वास्तविक (कुल) गणना प्राप्त करने के लिए वापसी की गणना राशि को जोड़ना होगा।
• इन सभी गणना समयों को स्टोर में बड़े डेटा से काफी हद तक प्रभावित किया जाएगा।
• आप अंत हैं, तो आप की संभावना होगा रिकॉर्ड की एक बड़ी संख्या को एकाधिक डोमेन में अपने रिकॉर्ड ठीकरा को
• अमेज़न आपके अनुरोध थ्रोटल होगा यदि आप एक डोमेन पर भी कई बनाने

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

आपके मामले में मैं MongoDb जैसे कुछ की सिफारिश करता हूं। इसमें अपनी समस्याओं का भी हिस्सा है, लेकिन इस मामले के लिए बेहतर हो सकता है। हालांकि, यदि आपके पास बहुत से रिकॉर्ड (लाखों और ऊपर की ओर) हैं और फिर बहुत से रिकॉर्ड में इंडेक्स जोड़ने का प्रयास करते हैं तो आप इसे तोड़ सकते हैं यदि यह स्पिंडल पर है और एसएसडी नहीं है।