डेटाबेस के बजाय डेटा स्टोर में कैसे सोचें?


183

उदाहरण के लिए, Google App Engine डेटा को संग्रहीत करने के लिए Google डेटाबेस का उपयोग करता है, न कि एक मानक डेटाबेस का। क्या किसी के पास डेटाबेस के बजाय Google डेटास्टोर का उपयोग करने के लिए कोई सुझाव है? ऐसा लगता है कि मैंने अपने दिमाग को ऑब्जेक्ट संबंधों में 100% सोचने के लिए प्रशिक्षित किया है जो सीधे टेबल संरचनाओं के लिए मैप करता है, और अब कुछ भी अलग तरीके से देखना मुश्किल है। मैं Google डेटास्टोर के कुछ लाभों (उदाहरण के प्रदर्शन और डेटा को वितरित करने की क्षमता) को समझ सकता हूं, लेकिन कुछ अच्छे डेटाबेस कार्यक्षमता का त्याग किया जाता है (जैसे जुड़ता है)।

क्या कोई व्यक्ति जिसने Google डेटास्टोर या बिगटेबल के साथ काम किया है, उसके साथ काम करने के लिए कोई अच्छी सलाह है?


DataSource एक पुरानी एपीआई है जिसे हम धीरे-धीरे हटा रहे हैं - यह एक डेटाबेस कनेक्शन मॉडल से बहुत जुड़ा हुआ था। DataStore निम्न स्तर की एपीआई है जो कि फीचरराइडर्स और फ़ीचरविटर का उपयोग करके जीआईएस सामग्री के लिए "कच्चे" स्ट्रीमिंग आधारित दृष्टिकोण तक पहुंच की अनुमति देता है।
मुरली

अब Google क्लाउड एसक्यूएल Google ऐप इंजन के लिए रिलेशनल डेटाबेस सपोर्ट प्रदान करता है। यदि आप अभी भी डेटा स्टोर के समाधान की तलाश में हैं, तो आप Google क्लाउड SQL का उपयोग कर सकते हैं ।
चंदना

आप मुंगो डाटासटोर एपीआई की जाँच कर सकते हैं: bit.ly/13eSDpr
quarks

जवाबों:


149

'पारंपरिक' संबंधपरक डेटाबेस की तुलना में ऐप इंजन डेटास्टोर के बारे में उपयोग करने के लिए दो मुख्य बातें हैं:

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

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

एक बार जब आप इसे अवशोषित कर लेते हैं, तो आपके पास डेटास्टोर की क्षमताओं और सीमाओं को समझने के लिए आवश्यक बुनियादी ज्ञान होता है। मनमाने ढंग से लगने वाले प्रतिबंध शायद अधिक समझ में आते हैं।

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

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


4
अच्छी खबर है, इंटरनेट रसोई की किताब के बारे में नहीं भूल गया है, अर्थात् इंटरनेट संग्रह नहीं भूल गया है। साइट का भूत अभी भी यहाँ मौजूद है: web.archive.org/web/20090416113704/http://…
आसानी से वापस लाया जा सकता है

42

जिस तरह से मैं माइंड स्विच के बारे में जा रहा हूं वह डेटाबेस के बारे में पूरी तरह से भूलना है।

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

यदि आप इस धारणा को भूल जाते हैं कि डेटाबेस का आकार मायने रखता है और डेटा को डुप्लिकेट नहीं किया जाना चाहिए, तो आप वहां 3/4 हैं और आपको कोई कोड भी नहीं लिखना है! अपने विचारों को अपने मॉडलों को निर्देशित करने दें। आपको अपनी वस्तुओं को लेने की ज़रूरत नहीं है और उन्हें रिलेशनल दुनिया की तरह 2 आयामी बनाना है। अब आप आकृतियों के साथ वस्तुओं को संग्रहीत कर सकते हैं।

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


2
मुझे पसंद है "अपने विचारों को अपने मॉडल तय करें।" बिट। मुझे लगता है कि यह आरडीबीएमएस से लटका हुआ है, लेकिन यह सब कुछ सरल करता है।
cbednarski

23

जब लोग बाहर आते हैं तो मैं हमेशा चकराता हूं - यह संबंधपरक नहीं है। मैंने django में cellectr लिखा है और यहाँ मेरे मॉडल का एक स्निपेट नीचे दिया गया है। जैसा कि आप देखेंगे, मेरे पास लीग हैं जो उपयोगकर्ताओं द्वारा प्रबंधित या कोच हैं। मैं एक लीग से सभी प्रबंधकों को प्राप्त कर सकता हूं, या किसी दिए गए उपयोगकर्ता से मैं लीग को वापस कर सकता हूं वह कोच या प्रबंधक।

सिर्फ इसलिए कि कोई विशिष्ट विदेशी कुंजी समर्थन का मतलब यह नहीं है कि आपके पास रिश्तों के साथ डेटाबेस मॉडल नहीं हो सकता है।

मेरी दो पेंस।


class League(BaseModel):
    name = db.StringProperty()    
    managers = db.ListProperty(db.Key) #all the users who can view/edit this league
    coaches = db.ListProperty(db.Key) #all the users who are able to view this league

    def get_managers(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.managers)

    def get_coaches(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.coaches)      

    def __str__(self):
        return self.name

    # Need to delete all the associated games, teams and players
    def delete(self):
        for player in self.leagues_players:
            player.delete()
        for game in self.leagues_games:
            game.delete()
        for team in self.leagues_teams:
            team.delete()            
        super(League, self).delete()

class UserPrefs(db.Model):
    user = db.UserProperty()
    league_ref = db.ReferenceProperty(reference_class=League,
                            collection_name='users') #league the users are managing

    def __str__(self):
        return self.user.nickname

    # many-to-many relationship, a user can coach many leagues, a league can be
    # coached by many users
    @property
    def managing(self):
        return League.gql('WHERE managers = :1', self.key())

    @property
    def coaching(self):
        return League.gql('WHERE coaches = :1', self.key())

    # remove all references to me when I'm deleted
    def delete(self):
        for manager in self.managing:
            manager.managers.remove(self.key())
            manager.put()
        for coach in self.managing:
            coach.coaches.remove(self.key())
            coaches.put()            
        super(UserPrefs, self).delete()    

12

मैं रिलेशनल डेटाबेस की दुनिया से आया था तब मुझे यह डाटासटोर की बात लगी। इसे लटकने में कई दिन लग गए। खैर मेरे कुछ निष्कर्ष हैं।

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

RDBMS VS DataStore
संरचना
डेटाबेस में, हम आमतौर पर अपने डेटा को टेबल्स, पंक्तियों में संरचना करते हैं, जो डेटास्टोर में है यह किंड्स और एंटिटीज़ बन जाता है ।


RDBMS में संबंध , अधिकांश लोग एक-से-एक, कई-से-एक, कई-से-कई संबंधों में, दातासोर में, जैसे कि "नो जॉइन" चीज होती है, लेकिन फिर भी हम इस संदर्भ का उपयोग करके अपने सामान्यीकरण को प्राप्त कर सकते हैं। "जैसे एक-से-एक संबंध उदाहरण

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


RDMBS में गणना , (*) को गिनना बहुत आसान है, लेकिन डेटास्टोर में, कृपया इसे सामान्य तरीके से भी न सोचें (हाँ एक गिनती कार्य है) क्योंकि इसकी 1000 सीमा है और यह इकाई के रूप में बहुत छोटे रूप में खर्च होगा अच्छा नहीं है लेकिन हमारे पास हमेशा अच्छे विकल्प होते हैं, हम शार्द काउंटर्स का उपयोग कर सकते हैं ।


RDMBS में अनोखी अड़चनें, हमें इस सुविधा से प्यार है? लेकिन डेटासटोर का अपना तरीका है। आप किसी संपत्ति को अद्वितीय के रूप में परिभाषित नहीं कर सकते हैं :(।

क्वेरी
GAE Datatore एक बेहतर सुविधा प्रदान करता है ज्यादा की तरह (अरे नहीं! डेटासंग्रह नहीं है जैसे खोजशब्द) एसक्यूएल जो है GQL

डेटा इन्सर्ट / अपडेट / डिलीट / सेलेक्ट करें
जहाँ हम सभी में रूचि है, जैसे RDMBS में हमें RDBMS की तरह इन्सर्ट, अपडेट, डिलीट और सेलेक्ट के लिए एक क्वेरी की आवश्यकता होती है, डेटास्टोर ने डाल, डिलीट, गेट (न ही बहुत उत्साहित हो) क्योंकि डाटकोर डाल या के मामले में मिल लिखें, पढ़ें, छोटे ऑपरेशन (पढ़ें डेटास्टोर कॉल के लिए लागत ) और thats जहां डेटा मॉडलिंग कार्रवाई में आता है। आपको इन ऑपरेशनों को कम करना होगा और अपने ऐप को चालू रखना होगा। पढ़ने के संचालन को कम करने के लिए आप मेमेचे का उपयोग कर सकते हैं ।


6

ऑब्जेक्ट दस्तावेज़ देखें। पृष्ठ के नीचे पहली टिप्पणी में कहा गया है:

"अच्छा है, हालाँकि आपने इसे ऑब्जेक्टिफाई करने के लिए लिखा है, यह एपेंजाइन डेटास्टोर के सबसे संक्षिप्त स्पष्टीकरणों में से एक है जो मैंने खुद कभी पढ़ा है। धन्यवाद।"

https://github.com/objectify/objectify/wiki/Concepts


3

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


1
संदर्भ गुणों के साथ एक मुद्दा यह है कि वे जल्दी से 1 + एन क्वेरी समस्या बना सकते हैं। (100 लोगों को खोजने के लिए 1 क्वेरी खींचें, फिर उनमें से प्रत्येक के लिए एक और क्वेरी करें। person.address पाने के लिए।)
0124816

'रेफरेंस प्रॉपर्टीज' से लिंक टूट गया है, शायद जावा सपोर्ट के अलावा। कोशिश करें: code.google.com/appengine/docs/python/datastore/…
Spike0xff

लिंक ठीक किया गया। यदि आपके पास पर्याप्त प्रतिनिधि है, तो किसी भी उत्तर को संपादित करने के लिए स्वतंत्र महसूस करें।
मार्क सिडैड

0

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

अब वापस मूल टिप्पणी पर, google datastore और bigtable दो अलग-अलग चीजें हैं ताकि Google डेटास्टोर को डेटास्टोर स्टोरेज सेंस के लिए भ्रमित न करें। Bigtable, bigquery से अधिक महंगा है (प्राथमिक कारण जो हम इसके साथ नहीं गए थे)। Bigquery में उचित जुड़ाव और RDBMS जैसे sql भाषा और इसकी सस्ती, क्यों नहीं bigquery का उपयोग करें। कहा जा रहा है कि, bigquery की कुछ सीमाएँ हैं, जो आपके डेटा के आकार पर निर्भर करती है कि आप उनका सामना कर सकते हैं या नहीं।

इसके अलावा, डेटास्टर के संदर्भ में सोच के अनुसार, मुझे लगता है कि उचित कथन "NoSQL डेटाबेस के संदर्भ में सोच रहा होगा"। इन दिनों उनमें से बहुत सारे उपलब्ध हैं, लेकिन जब Google क्लाउड SQL (जो कि mySQL है) को छोड़कर Google उत्पादों की बात आती है तो बाकी सब कुछ NoSQL है।


-6

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

(बिगटेबल संदर्भ: http://en.wikipedia.org/wiki/BigTable )


यह प्रश्न विशेष रूप से Google App Engine से संबंधित है, जो Bigtable का उपयोग करता है; रिलेशनल डेटाबेस का उपयोग करना एक विकल्प नहीं है।
निक जॉनसन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.