Pinterest केवल 6 इंजीनियरों के साथ 1.1 करोड़ उपयोगकर्ताओं तक कैसे स्केल कर पाया

Pinterest की स्केलिंग यात्रा

Pinterest की स्केलिंग प्रक्रिया को चार चरणों में बांटा जा सकता है:

1. आत्म-खोज का दौर: एक छोटी इंजीनियरिंग टीम ने तेज़ प्रोटोटाइपिंग और लगातार बदलती प्रोडक्ट आवश्यकताओं को संभाला।
2. प्रयोग का दौर: उपयोगकर्ताओं की संख्या में तेज़ बढ़ोतरी के कारण तेज़ स्केलिंग की ज़रूरत पड़ी, लेकिन इससे जटिल और नाज़ुक सिस्टम बन गए।
3. परिपक्वता का दौर: आर्किटेक्चर को सरल बनाने के लिए MySQL, Memcache और Redis जैसी परिपक्व और स्केलेबल तकनीकों का उपयोग किया गया।
4. प्रतिगमन का दौर: सही आर्किटेक्चर तैयार होने के बाद, क्षैतिज रूप से स्केल करके वृद्धि जारी रखी गई।

मुख्य तकनीकें

Pinterest ने उन तकनीकों को प्राथमिकता दी जो विश्वसनीय, समझने में आसान और स्केलेबल थीं:

• MySQL: स्थिर और मेंटेन करना आसान relational database।
• Memcache: अक्सर एक्सेस किए जाने वाले डेटा को मेमोरी में cache करके database reads का लोड कम करता है।
• Redis: विभिन्न data structures को संभाल सकने वाला लचीला data store।
• Solr: जल्दी उपयोग में लाई जा सकने वाली search platform।

डेटाबेस स्केलिंग: clustering बनाम sharding

Pinterest ने डेटाबेस को वितरित करने के लिए दो तरीकों पर विचार किया:

Clustering

• जब डेटा आता है, तो उसके लिए सबसे उपयुक्त node तय किया जाता है और डेटा को कई nodes पर replicate किया जाता है।
• इसके फ़ायदे हैं auto scaling, आसान configuration और data availability; लेकिन कमियाँ हैं complexity, maturity की कमी और upgrades की कठिनाई।

Sharding

• डेटा को छोटे chunks में बाँटकर हर chunk को अलग server पर रखा जाता है।
• इसके फ़ायदे हैं सरल architecture, स्वतंत्र scaling और स्पष्ट data ownership; लेकिन कमियाँ हैं database-level joins और transactions का न होना, तथा application complexity का बढ़ना।

Clustering के साथ नकारात्मक अनुभव के कारण Pinterest ने sharding चुना।

sharding architecture में बदलाव

Pinterest ने feature freeze के दौरान चरणबद्ध तरीके से sharding में माइग्रेट किया:

1. joins हटाना: सभी MySQL joins हटाए गए और data denormalization तथा caching का उपयोग किया गया।
2. ID-आधारित sharding: 64-bit ID के आधार पर sharding करके data routing को सरल बनाया गया।

sharding की कमियाँ और समाधान

• migration scripts: डेटा को sharding infrastructure में ट्रांसफ़र करने की प्रक्रिया में बहुत समय लगा।
• application logic: database-level joins और transactions न होने के कारण data consistency को application स्तर पर बनाए रखना पड़ा।
• schema changes: सभी shards पर schema बदलावों की योजना बनाकर उन्हें लागू करना पड़ा।
• report generation: कई shards को एक साथ जोड़कर reports तैयार करनी पड़ीं।

सीख

Pinterest की स्केलिंग यात्रा से मिली मुख्य सीखें:

• सरलता महत्वपूर्ण है: ऐसी तकनीकें चुनना जिन्हें समझना आसान हो, समस्याओं को हल करने और जोखिम कम करने में मदद करता है।
• स्केलेबिलिटी पहले: तेज़ वृद्धि वाले माहौल में database features से समझौता करना पड़े तब भी स्केलेबिलिटी को प्राथमिकता देनी चाहिए।
• क्षैतिज स्केलिंग के लिए डिज़ाइन: ऐसा architecture चुनें जिसमें user base बढ़ने पर resources जोड़े जा सकें।