How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE भारत का सबसे बड़ा मीडिया और मनोरंजन व्यवसाय है, जो प्रसारण टीवी, फिल्मों, स्ट्रीमिंग मीडिया, और संगीत को कवर करता है। ZEE5 उनके अग्रणी ओटीटीटी स्ट्रीमिंग सेवा है, 190 से अधिक देशों में उपलब्ध है, जिसमें ~ 150 मिलियन मासिक सक्रिय उपयोगकर्ता हैं। सिस्टम के पीछे के इंजीनियरों को पता था कि व्यापार के निरंतर विकास से उनकी बुनियादी ढांचे (और डेटाबेस बिलों की समीक्षा करने वाले लोग) को जोर दिया जाएगा). इसलिए, टीम ने किसी भी दिल का दौरा करने से पहले सिस्टम को फिर से सोचने का फैसला किया. TL;DR, उन्होंने एक सिस्टम डिजाइन किया जिसे आंतरिक रूप से और उपयोगकर्ताओं द्वारा प्यार किया गया था. और Jivesh Threja (टेक लीड) और Srinivas Shanmugam (प्रमुख आर्किटेक्ट) ने पिछले साल वेलेंटाइन डे पर अपने अनुभवों को साझा करने के लिए हमारे साथ शामिल किया। उन्होंने प्रतिस्थापन के लिए तकनीकी आवश्यकताओं का वर्णन किया (क्लाउड तटस्थता, मल्टी-टेनेंट तैयारता, नए उपयोग मामलों के इनबॉर्डिंग की सरलता, और उच्च प्रवाह और कम लाटेंशन इष्टतम लागत पर) और यह ScyllaDB के लिए कैसे चला गया। एक साथ, उन्होंने सीखने के सबक साझा किए जो किसी को भी ScyllaDB का उपयोग करने या उपयोग करने में मदद कर सकते हैं। 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true आइये उस बातचीत से कुछ विशेषताएं... Heartbeat क्या है? "Heartbeat" एक अनुरोध को संदर्भित करता है जो ZEE5 ओटीटी प्लेटफॉर्म पर वीडियो प्लेसमेंट के दौरान नियमित अंतराल पर जारी किया जाता है. ये सरल अनुरोध ट्रैक करते हैं कि उपयोगकर्ता क्या देख रहे हैं और वे प्रत्येक वीडियो में कितना प्रगति कर रहे हैं. वे ZEE5 के "अंतर दृश्य" कार्यक्षमता के लिए आवश्यक हैं, जो उपयोगकर्ताओं को एक डिवाइस पर सामग्री को रोकने और फिर इसे किसी भी डिवाइस पर फिर से शुरू करने की अनुमति देता है। क्यों बदलते हैं? ZEE5 की मूल दिल धड़कने प्रणाली अलग-अलग डेटाबेस की एक वेब थी, प्रत्येक स्ट्रीमिंग अनुभव का एक विशिष्ट हिस्सा संभालती थी. हालांकि यह तकनीकी रूप से कार्यात्मक था, यह दृष्टिकोण महंगा था और उन्हें एक विशिष्ट विक्रेता पारिस्थितिकी तंत्र में बंद कर दिया। टीम ने अपनी बुनियादी ढांचे को अनुकूलित करने का अवसर पहचाना – और वे इसके लिए गए. वे एक प्रणाली चाहते थे जो किसी विशेष क्लाउड प्रदाता में लॉक नहीं किया गया था, ऑपरेटिंग के लिए कम लागत होगी, और लगातार तेजी से प्रदर्शन के साथ उनकी विशाल पैमाने पर संभाल सकता था – विशेष रूप से, एक डिफ़ॉल्ट मिलीसेकंड प्रतिक्रिया। सिस्टम वास्तुकला, पहले और बाद में यहाँ कई डेटाबेस के साथ उनके मूल सिस्टम आर्किटेक्चर की एक नज़र है: DynamoDB दिल की धड़कन डेटा को संग्रहीत करने के लिए Amazon RDS अगले और पिछले एपिसोड की जानकारी संग्रहीत करने के लिए Apache Solr स्थायी मेटाडेटा को स्टोर करने के लिए Metadata को Cache करने के लिए One Redis instance एक और Redis उदाहरण दर्शकों की जानकारी संग्रहीत करने के लिए ZEE5 टीम ने इस परियोजना के लिए चार मुख्य डेटाबेस विकल्पों पर विचार किया: Redis, Cassandra, Apache Ignite, और ScyllaDB. मूल्यांकन और बेंचमार्किंग के बाद, उन्होंने ScyllaDB चुना। हम स्थायी डेटाबेस के शीर्ष पर एक अतिरिक्त कैश परत की आवश्यकता नहीं है. ScyllaDB एक ही बुनियादी ढांचे के भीतर कैश परत और स्थायी डेटाबेस दोनों का प्रबंधन करता है, जो क्षेत्रों, पुनरावृत्ति और मल्टी क्लाउड तैयारी के बीच कम लाटेनता सुनिश्चित करता है. यह किसी भी क्लाउड प्रदाता के साथ काम करता है, जिसमें Azure, AWS, और GCP शामिल हैं, और अब एक घंटे से कम समय के साथ प्रबंधित समर्थन प्रदान करता है. हम स्थायी डेटाबेस के शीर्ष पर एक अतिरिक्त कैश परत की आवश्यकता नहीं है. ScyllaDB एक ही बुनियादी ढांचे के भीतर कैश परत और स्थायी डेटाबेस दोनों का प्रबंधन करता है, जो क्षेत्रों, पुनरावृत्ति और मल्टी क्लाउड तैयारी के बीच कम लाटेनता सुनिश्चित करता है. यह किसी भी क्लाउड प्रदाता के साथ काम करता है, जिसमें Azure, AWS, और GCP शामिल हैं, और अब एक घंटे से कम समय के साथ प्रबंधित समर्थन प्रदान करता है. नई वास्तुकला पहले सिस्टम वास्तुकला संरचना को सरल और पतला करती है। अब, सभी दिल की धड़कन घटनाओं को उनके दिल की धड़कन विषय में धक्का दिया जाता है, स्ट्रीमिंग प्रोसेसिंग के माध्यम से संसाधित किया जाता है, और ScyllaDB क्लाउड में ScyllaDB कनेक्टरों का उपयोग करके इंजेक्ट किया जाता है. जब भी सामग्री प्रकाशित होती है, तो यह उनके मेटाडेटा विषय में इंजेक्ट किया जाता है और फिर मेटाडेटा कनेक्टरों के माध्यम से ScyllaDB क्लाउड में इंजेक्ट किया जाता है. Srinivas निष्कर्ष निकालता है: "इस नए आर्किटेक्चर के साथ, हमने DynamoDB, RDS, Redis और Solr से कार्य भार को सफलतापूर्वक ScyllaDB में स्थानांतरित किया है। ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. डिजाइन में गहराई से Next Jivesh ने अपने कम-स्तरीय डिजाइन के बारे में अधिक साझा किया ... रियल टाइम प्रसंस्करण पाइपलाइन वास्तविक समय प्रसंस्करण पाइपलाइन में, दिल की धड़कन को नियमित अंतराल पर ScyllaDB को भेजा जाता है। दिल की धड़कन अंतराल को 60 सेकंड तक सेट किया गया है, जिसका अर्थ है कि प्रत्येक फ्रंट एंड क्लाइंट हर 60 सेकंड में एक दिल की धड़कन भेजता है जबकि एक उपयोगकर्ता एक वीडियो देख रहा है. ये दिल की धड़कन प्लेबैक स्ट्रीमिंग प्रोसेसिंग सिस्टम के माध्यम से गुजरती हैं, व्यावसायिक तर्क उपभोक्ता उस डेटा को आवश्यक प्रारूप में परिवर्तित करते हैं - फिर संसाधित डेटा ScyllaDB में संग्रहीत होता है. स्केलेबल API Layer स्केलेबल एपीआई परत का पहला घटक दिल की धड़कन सेवा है, जो बड़ी मात्रा में डेटा इंजेक्शन को संभालने के लिए जिम्मेदार है. विषय डेटा को संसाधित करते हैं, फिर यह एक कनेक्टर सेवा के माध्यम से गुजरता है और ScyllaDB में संग्रहीत होता है. एक और उल्लेखनीय एपीआई परत सेवा समकालीन दृश्य संख्या संख्या सेवा है. यह सेवा ScyllaDB का उपयोग करके समकालीन दृश्यता डेटा प्राप्त करने के लिए करती है – या तो प्रति उपयोगकर्ता या प्रति संपत्ति (उदाहरण के लिए, प्रति आईडी)। मेटाडेटा प्रबंधन उपयोग के मामले ZEE5 का सामना करने वाली पहली बड़ी चुनौतियों में से एक उनके बड़े पैमाने पर ओटीटी प्लेटफॉर्म के लिए मेटाडेटा का प्रबंधन करना था। शुरुआत में, वे अपने व्यापक मेटाडेटा आवश्यकताओं को संभालने के लिए तीन अलग-अलग डेटाबेस – Solr, Redis और Postgres – के संयोजन पर भरोसा करते थे। यहां उनके मेटाडेटा मॉडल की एक नज़र है: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; इस मॉडल में, आईडी विभाजन कुंजी के रूप में कार्य करता है. चूंकि यह तालिका अपेक्षाकृत कम लिखने का अनुभव करती है (एक लिखना केवल तब होता है जब एक नई संपत्ति जारी की जाती है) लेकिन काफी अधिक पढ़ती है, इसलिए उन्होंने प्रदर्शन को अनुकूलित करने के लिए स्तरित संपीड़न रणनीति का उपयोग किया। Viewership Count उपयोग के मामले Viewership Count एक और उपयोग के मामले है जिसे वे ScyllaDB में स्थानांतरित कर चुके हैं. Viewership count प्रति उपयोगकर्ता या संपत्ति आईडी के अनुसार ट्रैक किया जा सकता है. ZEE5 ने एक तालिका डिजाइन करने का फैसला किया जहां उपयोगकर्ता आईडी विभाजन कुंजी के रूप में और संपत्ति आईडी वर्गीकरण कुंजी के रूप में कार्य करता था - देखने वाले डेटा को कुशलता से पूछताछ करने की अनुमति देता है। उन्होंने ScyllaDB के TTL को 60 सेकंड के दिल की धड़कन अंतराल के अनुरूप सेट किया, यह सुनिश्चित करने के लिए कि डेटा निर्दिष्ट समय के बाद स्वचालित रूप से समाप्त हो जाता है। Jivesh ने समझाया, "यह तालिका लगातार हर सामने के अंत और प्रत्येक उपयोगकर्ता से दिल की धड़कन के साथ अद्यतन की जाती है. दिल की धड़कन के रूप में, दर्शकों की गिनती को वास्तविक समय में ट्रैक किया जाता है और स्वचालित रूप से साफ किया जाता है जब TTL समाप्त हो जाता है. यह हमें ScyllaDB का उपयोग करके लाइव दर्शकों के डेटा को कुशलता से प्राप्त करने की अनुमति देता है। यहां उनकी दर्शकों की गिनती डेटा मॉडल है: CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; ScyllaDB परिणाम और सीखा सबक निम्नलिखित लोड परीक्षण रिपोर्ट प्रति सेकंड 41.7K अनुरोधों का प्रवाह दिखाता है. यह संदर्भ उच्च लोड के तहत प्रदर्शन का मूल्यांकन करने के लिए डेटाबेस चयन प्रक्रिया के दौरान किया गया था. Jivesh ने टिप्पणी की, "इस तरह के उच्च पारगमन के साथ भी, हम एक माइक्रो सेकंड लिखने की लाटेंसी और औसत माइक्रो सेकंड पढ़ने की लाटेंसी प्राप्त कर सकते हैं. यह वास्तव में हमें एक स्पष्ट दृष्टिकोण देता है कि ScyllaDB क्या कर सकता है - और यह हमें निर्णय लेने में मदद करता है। फिर उन्होंने कुछ तथ्यों को साझा करना जारी रखा जो ZEE5 के ScyllaDB तैनाती के पैमाने पर प्रकाश डालते हैं: "हमारे पास ScyllaDB पर लगभग 9TB है। यहां तक कि इतने बड़े डेटा की मात्रा के साथ, यह माइक्रोसेकंड और एक डिफ़ॉल्ट मिलीसेकंड के भीतर लाटेक्शन को संभालने में सक्षम है, जो काफी भारी है। हर सेकंड, हम ScyllaDB में इतने सारे डेटा लिख रहे हैं और इससे इतने सारे डेटा प्राप्त कर रहे हैं हम एक दिन में 100 अरब से अधिक दिल की धड़कन को संसाधित करते हैं, जो काफी बड़ा है। भाषण को निम्नलिखित सबक सीखा गया था: डेटा मॉडलिंग एकल डिजिटल मिलीसेकंड लाटेक्शन प्राप्त करने में सबसे महत्वपूर्ण कारक है। सही क्वोरम सेटिंग और संपीड़न रणनीति चुनें. उदाहरण के लिए, क्या इसे पढ़ने से पहले प्रत्येक नोड पर एक दिल की धड़कन लिखने की आवश्यकता होती है, या क्या एक स्थानीय क्वोरम पर्याप्त है? सही क्वोरम का चयन लाटेंस और एसएलए आवश्यकताओं के बीच सबसे अच्छा संतुलन सुनिश्चित करता है। विभाजन और क्लस्टरिंग कुंजी को बुद्धिमानी से चुनें - बाद में उन्हें संशोधित करना आसान नहीं है। तेजी से खोज के लिए भौतिक दृष्टिकोण का उपयोग करें और फ़िल्टर पूछताछ से बचें। दक्षता में सुधार के लिए तैयार बयानों का उपयोग करें। उदाहरण के लिए, मेटाडेटा मॉडल में, 20 सिंक्रनाइज़ कवरेज समानांतर रूप से निष्पादित किए गए थे, और ScyllaDB ने उन्हें मिलीसेकंड के भीतर संसाधित किया। Zone-aware ScyllaDB क्लाइंट क्रॉस-AZ (Availability Zone) नेटवर्क लागत को कम करने में मदद करते हैं।
