Appboy मोबाइल ऐप्स के लिए दुनिया का अग्रणी मार्केटिंग ऑटोमेशन प्लेटफॉर्म है। हम हर महीने अरबों डेटा पॉइंट्स एकत्र करते हैं यह ट्रैक करके कि उपयोगकर्ता हमारे ग्राहकों के मोबाइल ऐप्स में क्या कर रहे हैं और उन्हें उनके व्यवहार या जनसांख्यिकी के आधार पर ईमेल, पुश नोटिफिकेशन और इन-ऐप मैसेज के लिए उपयोगकर्ताओं को टार्गेट करने की अनुमति देते हैं। MongoDB हमारे अधिकांश डेटाबेस स्टैक को शक्ति प्रदान करता है, और हम ObjectRocket पर कई क्लस्टर्स में दर्जनों शार्ड्स होस्ट करते हैं।
MongoDB के साथ एक आम प्रदर्शन अनुकूलन रणनीति डॉक्यूमेंट्स में छोटे फील्ड नामों का उपयोग करना है। यानी, एक डॉक्यूमेंट बनाने के बजाय जो ऐसा दिखता है...
{first_name: "Jon", last_name: "Hyman"}...छोटे फील्ड नामों का उपयोग करें ताकि डॉक्यूमेंट ऐसा दिख सके...
{fn: "Jon", ln: "Hyman"}चूंकि MongoDB में कॉलम या पूर्वनिर्धारित स्कीमा की अवधारणा नहीं है, यह संरचना लाभप्रद है क्योंकि फील्ड नाम डेटाबेस में हर डॉक्यूमेंट पर डुप्लिकेट होते हैं। यदि आपके पास दस लाख डॉक्यूमेंट्स हैं जिनमें से प्रत्येक पर "first_name" फील्ड है, तो आप उस स्ट्रिंग को दस लाख बार स्टोर कर रहे हैं। यह प्रति डॉक्यूमेंट अधिक स्पेस की ओर ले जाता है, जो अंततः प्रभावित करता है कि कितने डॉक्यूमेंट्स मेमोरी में फिट हो सकते हैं और, बड़े पैमाने पर, थोड़ा प्रदर्शन प्रभावित कर सकता है, क्योंकि MongoDB को उन्हें पढ़ते समय डॉक्यूमेंट्स को मेमोरी में मैप करना पड़ता है।
इवेंट डेटा एकत्र करने के अलावा, Appboy हमारे ग्राहकों को उनके प्रत्येक उपयोगकर्ताओं पर "कस्टम एट्रिब्यूट्स" स्टोर करने की भी अनुमति देता है। उदाहरण के लिए, एक स्पोर्ट्स ऐप उपयोगकर्ता के "पसंदीदा खिलाड़ी" को स्टोर करना चाह सकता है, जबकि एक पत्रिका या समाचार पत्र ऐप स्टोर कर सकता है कि कोई ग्राहक "वार्षिक ग्राहक" है या नहीं। Appboy पर, हमारे पास एक ऐप के प्रत्येक अंतिम उपयोगकर्ता के लिए एक डॉक्यूमेंट है जिसे हम ट्रैक करते हैं, और उस पर हम उन कस्टम एट्रिब्यूट्स को फील्ड्स जैसे उनके पहले या अंतिम नाम के साथ संग्रहीत करते हैं। स्पेस बचाने और प्रदर्शन में सुधार करने के लिए, हम डॉक्यूमेंट पर स्टोर की जाने वाली हर चीज के फील्ड नामों को छोटा करते हैं। जिन फील्ड्स को हम पहले से जानते हैं (जैसे पहला नाम, ईमेल, लिंग, आदि) हम अपना खुद का एलियासिंग कर सकते हैं (उदाहरण के लिए, "fn" का अर्थ "पहला नाम"), लेकिन हम उन कस्टम एट्रिब्यूट्स के नामों का अनुमान नहीं लगा सकते जो हमारे ग्राहक रिकॉर्ड करेंगे। यदि कोई ग्राहक "supercalifragilisticexpialidocious" नामक एक कस्टम एट्रिब्यूट बनाने का फैसला करता है, तो हम इसे उनके सभी डॉक्यूमेंट्स पर स्टोर नहीं करना चाहते।
इसे हल करने के लिए, हम कस्टम एट्रिब्यूट फील्ड नामों को टोकनाइज़ करते हैं जिसे हम "नेम स्टोर" कहते हैं। प्रभावी रूप से, यह MongoDB में एक डॉक्यूमेंट है जो "पसंदीदा खिलाड़ी" जैसे मानों को एक अद्वितीय, पूर्वानुमेय, बहुत छोटे स्ट्रिंग पर मैप करता है। हम इस मैप को केवल MongoDB के एटॉमिक ऑपरेटर्स का उपयोग करके उत्पन्न कर सकते हैं।
नेम स्टोर डॉक्यूमेंट स्कीमा बेहद बुनियादी है: प्रत्येक ग्राहक के लिए एक डॉक्यूमेंट है, और प्रत्येक डॉक्यूमेंट में केवल एक सरणी फील्ड है जिसका नाम "list" है। विचार यह है कि सरणी में कस्टम एट्रिब्यूट्स के सभी मान होंगे और दी गई स्ट्रिंग का इंडेक्स उसका टोकन होगा। इसलिए यदि हम "पसंदीदा खिलाड़ी" को एक छोटे, पूर्वानुमेय फील्ड नाम में अनुवाद करना चाहते हैं, तो हम बस "list" की जांच करते हैं कि यह सरणी में कहां है। यदि यह वहां नहीं है, तो हम सरणी के अंत में एलिमेंट जोड़ने के लिए एक एटॉमिक पुश जारी कर सकते हैं, (db.custom_attribute_name_stores.update({_id : X, list: {$ne : "पसंदीदा खिलाड़ी"}}, {$push: {list: "पसंदीदा खिलाड़ी"}})), डॉक्यूमेंट को रीलोड करें और इंडेक्स निर्धारित करें। आदर्श रूप से, हम $addToSet का उपयोग करते, लेकिन $addToSet ऑर्डर की गारंटी नहीं देता, जबकि $push डिफ़ॉल्ट रूप से अंत में जोड़ने के लिए प्रलेखित है।
इस बिंदु पर, हम "पसंदीदा खिलाड़ी" जैसी किसी चीज़ को एक पूर्णांक मान में अनुवाद कर सकते हैं। मान लें कि वह मान 1 है। तब हमारा उपयोगकर्ता डॉक्यूमेंट ऐसा दिखेगा:
{ fn: "Jon", ln: "Hyman", custom: { 1: "LeBron James" } }फील्ड नाम छोटे और साफ! इसका एक बड़ा साइड इफेक्ट यह है कि हमें अपने ग्राहकों द्वारा उन कैरेक्टर्स का उपयोग करने के बारे में चिंता करने की ज़रूरत नहीं है जिन्हें MongoDB एस्केपिंग के बिना सपोर्ट नहीं कर सकता, जैसे डॉलर साइन या पीरियड्स।
अब, आप सोच रहे होंगे कि MongoDB लगातार बढ़ते डॉक्यूमेंट्स के खिलाफ चेतावनी देता है और हमारा नेम स्टोर डॉक्यूमेंट अनबाउंडेड बढ़ सकता है। व्यवहार में, हमने अपने कार्यान्वयन को थोड़ा बढ़ाया है ताकि हम प्रति ग्राहक एक से अधिक डॉक्यूमेंट स्टोर कर सकें। यह हमें एक नया डॉक्यूमेंट उत्पन्न करने से पहले "list" सरणी में कितने सरणी एलिमेंट्स की अनुमति देते हैं, इस पर एक उचित कैप लगाने देता है। सबसे अच्छी बात यह है कि हम अभी भी केवल MongoDB का उपयोग करके यह सब एटॉमिक रूप से कर सकते हैं! इसे प्राप्त करने के लिए, हम प्रत्येक डॉक्यूमेंट में "leastvalue" नामक एक और फील्ड जोड़ते हैं। "leastvalue" फील्ड दर्शाता है कि इस डॉक्यूमेंट के बनने से पहले पिछले डॉक्यूमेंट्स में कितने एलिमेंट्स जोड़े गए हैं। इसलिए यदि हम "leastvalue" 100 और "list" ["सीजन टिकट होल्डर", "पसंदीदा खिलाड़ी"] के साथ एक डॉक्यूमेंट देखते हैं, तो "पसंदीदा खिलाड़ी" के लिए टोकन मान 101 है (हम ज़ीरो-बेस्ड इंडेक्सिंग का उपयोग कर रहे हैं)। इस उदाहरण में, हम नया डॉक्यूमेंट बनाने से पहले "list" सरणी में केवल 100 मान स्टोर कर रहे हैं। अब, इन्सर्ट करते समय, हम पुश को थोड़ा संशोधित करते हैं ताकि यह उच्चतम "leastvalue" मान वाले डॉक्यूमेंट पर काम करे, और यह भी सुनिश्चित करे कि "list.99" मौजूद नहीं है (अर्थात "list" सरणी में इंडेक्स 99 में कुछ भी नहीं है)। यदि उस इंडेक्स पर पहले से ही एक एलिमेंट मौजूद है, तो पुश ऑपरेशन कुछ नहीं करेगा। उस स्थिति में, हम जानते हैं कि हमें एक नया नेम स्टोर डॉक्यूमेंट बनाने की आवश्यकता है जिसका "least_value" सभी डॉक्यूमेंट्स में मौजूद एलिमेंट्स की कुल संख्या के बराबर हो। एक एटॉमिक $findAndModify का उपयोग करके, हम नया डॉक्यूमेंट बना सकते हैं यदि यह मौजूद नहीं है, इसे वापस ला सकते हैं और फिर $push को फिर से आजमा सकते हैं।
यदि हमारे ग्राहक के पास केवल कुछ कस्टम एट्रिब्यूट्स से अधिक हैं, तो मानों से टोकन्स में अनुवाद करने के लिए सभी नेम स्टोर डॉक्यूमेंट्स को वापस पढ़ना बैंडविड्थ और प्रोसेसिंग के संदर्भ में महंगा हो सकता है। हालांकि, चूंकि एक दिए गए फील्ड का टोकन मान एक बार गणना होने के बाद हमेशा समान होता है, हम अनुवाद को तेज करने के लिए टोकन्स को कैश करते हैं।
हमने अपने एप्लिकेशन के विभिन्न हिस्सों में "नेम स्टोर टोकन" प्रतिमान को लागू किया है ताकि फील्ड नाम आकार को कम किया जा सके जबकि लचीली स्कीमा का उपयोग जारी रखा जा सके। यह मानों के लिए भी सहायक हो सकता है। मान लें कि एक रेडियो स्टेशन ऐप एक कस्टम एट्रिब्यूट स्टोर करता है जो शीर्ष 50 प्रदर्शन करने वाले कलाकारों की एक सरणी है जिन्हें एक उपयोगकर्ता सुनता है। 50 स्ट्रिंग्स वाली सरणी होने के बजाय, हम रेडियो स्टेशन नामों को टोकनाइज़ कर सकते हैं और उपयोगकर्ता पर 50 पूर्णांकों की एक सरणी स्टोर कर सकते हैं। उन उपयोगकर्ताओं को क्वेरी करना जो एक निश्चित कलाकार को पसंद करते हैं अब दो टोकन लुकअप शामिल हैं: एक फील्ड नाम के लिए और एक मान के लिए। लेकिन चूंकि हम मान से टोकन में अनुवाद को कैश करते हैं, हम किसी भी संख्या में मानों का अनुवाद करते समय कैश के लिए सिंगल राउंड-ट्रिप बनाए रखने के लिए अपने कैश लेयर में मल्टी-गेट का उपयोग कर सकते हैं।
यह अनुकूलन निश्चित रूप से कुछ इंडायरेक्शन और जटिलता जोड़ता है, लेकिन जब आप Appboy की तरह सैकड़ों लाखों उपयोगकर्ताओं को स्टोर करते हैं, तो यह एक सार्थक अनुकूलन है। हमने इस ट्रिक के माध्यम से महंगे SSD स्पेस के सैकड़ों गीगाबाइट बचाए हैं।
अधिक जानना चाहते हैं? मैं 18 सितंबर को सिप्रियानी में Rackspace Solve NYC कॉन्फ्रेंस के दौरान Appboy पर DevOps पर चर्चा करूंगा।
