MongoDB से Postgres

🚨 यह ब्लॉग पोस्ट मेरे MongoDB to Postgres (2024-03-06) और Sequelize vs. Prisma (2023-05-25) का संयोजन है। मूल ब्लॉग हटा दिए गए हैं, और यह ब्लॉग उनकी जगह ले चुका है क्योंकि दोनों में मूल रूप से समान सामग्री/सूचना थी। माइग्रेशन early March 2023 में शुरू हुआ, स्विच mid-November 2023 में हुआ, और पुराने MongoDB सिस्टम के सभी उदाहरण early January 2024 में पूरी तरह बंद कर दिए गए।

परिचय

During my time at eBay, I faced what became the most technically challenging problem of my career: migrating the Storage Management System (STMS) from MongoDB to Postgres. This wasn’t just a simple database swap; it was a complete architectural transformation of a critical system that ingests over 1.5 million metrics per minute across eBay’s data centers, with the requirement of zero downtime and maintaining nearly all existing functionality.

STMS क्या है?

The Storage Management System (STMS) serves as a critical internal tool for eBay’s Service & Storage Infrastructure (SSI) team. It monitors and manages devices across eBay’s data centers, allowing engineers to:

  • Monitor metrics from dozens of arrays, switches, hosts, disk groups, and clusters
  • Handle alerting for switches and arrays
  • Complete advanced tasks like host allocations
  • Access real-time data for other internal eBay services

STMS accounts for over 70 arrays, 60 switches, 1100 hosts, 900 disk groups, and 200 clusters across 3 of eBay’s data centers. Given its vital role in eBay’s infrastructure, any downtime or loss of functionality would directly impact the company’s core services and business operations.

चुनौती

माइग्रेशन आवश्यक क्यों था

The decision to migrate from MongoDB to Postgres wasn’t taken lightly. While MongoDB had served STMS well initially, the growing complexity of our data relationships and the need for more sophisticated querying capabilities made Postgres a better long-term solution for our use case.

इस समस्या को कठिन क्या बनाता है

The complexity of this migration stemmed from several fundamental challenges:

1. मूलभूत डेटाबेस अंतर MongoDB and Postgres are fundamentally different databases. MongoDB is a document-based database (NoSQL), meaning data is stored as JSON in collections, like documents in a filing cabinet. Postgres is a relational database (SQL), meaning data is stored as rows in tables, like in a spreadsheet.

2. कोडबेस आर्किटेक्चर STMS’s entire backend was built to process and manage data as JSONs, using packages exclusively compatible with MongoDB for database operations. This meant not just changing the database, but restructuring how our entire application handled data.

3. शून्य डाउनटाइम आवश्यकता Due to how vital STMS is as an internal tool, there could be no downtime during the migration. The system had to continue serving 1.5+ million metrics per minute throughout the entire process.

4. कठोर समयसीमा और सीमित अनुभव The migration had to be completed within a few months, with no clear execution plan initially. Neither I nor my coworkers had experience migrating a large legacy codebase from NoSQL to SQL databases, and I had limited prior experience with Postgres.

5. पैमाना और जटिलता The migration involved converting 36 MongoDB collections into 74 Postgres tables, requiring careful consideration of relationships, indexing, and query optimization.

सही ORM चुनना: Sequelize बनाम Prisma

One of the first major decisions was selecting an ORM (Object-Relational Mapping) tool. Since our codebase was already designed to use Mongoose for MongoDB, using an ORM would provide the smoothest transition path.

आवश्यकताओं का विश्लेषण

After careful analysis of the project’s needs, I established essential criteria for any ORM solution:

  • जावास्क्रिप्ट पैकेज होना चाहिए (हमारा अधिकांश कोड जावास्क्रिप्ट में लिखा गया था)
  • Postgres और उसकी अधिकांश सुविधाओं का समर्थन करना चाहिए
  • प्रदर्शन कम से कम Mongoose के बराबर या बेहतर होना चाहिए
  • ओपन सोर्स और मेंटेन किया गया होना चाहिए

उम्मीदवार

After extensive research, I narrowed down to two main contenders: Sequelize and Prisma. I created comprehensive testing environments using Docker for Postgres and converted our largest, most complex dataset from document structure to table structure.

परीक्षण कार्यप्रणाली

For each ORM, I measured performance across critical operations:

  • एक प्रविष्टि बनाने में लगने वाला समय
  • एक प्रविष्टि को अपडेट करने में लगने वाला समय
  • नेस्टेड प्रविष्टियों को अपडेट करने में लगने वाला समय (संबंध और JSON कुंजी-मूल्य)
  • एक प्रविष्टि को हटाने में लगने वाला समय
  • एक प्रविष्टि को क्वेरी/प्राप्त करने में लगने वाला समय

निर्णय: Sequelize

Around May 15, 2023, I decided that Sequelize was the better ORM for our use case. Here’s why:

Sequelize के लाभ:

  • वास्तव में ओपन-सोर्स और किसी फंडेड स्टार्टअप द्वारा मेंटेन नहीं किया गया
  • Postgres की अधिकांश सुविधाओं का समर्थन किया
  • बेहतर प्रदर्शन, विशेष रूप से Prisma की तुलना में
  • 10 से अधिक वर्षों के विकास के साथ परिपक्व इकोसिस्टम
  • जावास्क्रिप्ट क्लासेज़ का उपयोग करके लचीला मॉडल/स्कीमा प्रतिनिधित्व
  • जटिल जॉइन और फ़िल्टरिंग विकल्पों का समर्थन, जिसमें Regex शामिल है

प्रदर्शन परिणाम:

In my testing, Sequelize significantly outperformed Prisma. For our large dataset entries:

  • Sequelize: ~2.26 सेकंड प्रति प्रविष्टि
  • Prisma: ~11.21 सेकंड प्रति प्रविष्टि

Prisma हमारे उपयोग केस के लिए लगभग 5 गुना धीमा था, Sequelize की तुलना में। अतिरिक्त रूप से, हमारे सबसे बड़े डेटासेट से एक प्रविष्टि को हटाने में Prisma को लगभग 4 मिनट लगे, जो हमारी आवश्यकताओं के लिए अस्वीकार्य था।

Sequelize चुनौतियाँ:

  • अधिक जटिल और फुलाए हुए मॉडल प्रतिनिधित्व (Mongoose के 262 लाइनों की तुलना में Sequelize में 564 लाइनों)
  • कुछ मामलों में भ्रमित करने वाला सिंटैक्स
  • डेटाबेस माइग्रेशन जटिलता
  • Prisma की तुलना में कम व्यापक दस्तावेज़ीकरण

Sequelize और Prisma की तुलना: फायदे और नुकसान

To give a fuller picture of why I went with Sequelize, I want to share the detailed pros and cons I compiled for both ORMs during my evaluation. I also looked at how they stacked up in terms of schema representation and community support as of May 15, 2023. This deeper dive helped solidify my choice, and I hope it might be useful for anyone else facing a similar decision.

Sequelize के फायदे:

  • sync() फ़ंक्शन है जो स्वचालित रूप से आपके लिए तालिकाएँ बनाता और संभालता है, जिससे बहुत सारी मैन्युअल मेहनत बचती है।
  • नेस्टेड डेटा के लिए जटिल जॉइन को संभाल सकता है, जो STMS की संरचना के लिए महत्वपूर्ण था।
  • फ़िल्टरिंग विकल्पों की विस्तृत श्रृंखला का समर्थन करता है, जिसमें Regex शामिल है, जिससे क्वेरी में लचीलापन मिलता है।
  • मॉडल/स्कीमा प्रतिनिधित्व कच्चे जावास्क्रिप्ट क्लासेज़ का उपयोग करके किया जाता है, जो विशिष्ट आवश्यकताओं के अनुसार अत्यधिक अनुकूलन योग्य हैं।
  • डेटाबेस कनेक्शन को सहजता से संभालता है, जिसमें कई रीड-कनेक्शन का समर्थन शामिल है।
  • जब आपको अंदर तक जाना हो तो कच्ची SQL क्वेरी का समर्थन करता है।
  • समुदाय आँकड़े 15 मई, 2023 तक: NPM पर, अंतिम अपडेट 14 दिन पहले, 1,505,835 साप्ताहिक डाउनलोड; GitHub पर, अंतिम अपडेट कल, 4.2k फोर्क और 27.9k स्टार। यह 10 से अधिक वर्षों से MIT लाइसेंस के साथ ओपन सोर्स है, इसलिए मुझे विश्वास है कि यह ऐसा ही रहेगा।

Sequelize के नुकसान:

  • मॉडल/स्कीमा प्रतिनिधित्व बहुत जटिल और फुला हुआ हो सकता है। उदाहरण के लिए, हमारे बड़े डेटासेट का Mongoose प्रतिनिधित्व लगभग 262 लाइनों (स्पेस सहित) था, जबकि वही डेटासेट Sequelize में 564 लाइनों तक बढ़ गया।
  • सिंटैक्स कुछ परिदृश्यों में भ्रमित करने वाला और जटिल हो सकता है, जिससे कभी-कभी मेरी गति धीमी हो गई।
  • डेटाबेस को माइग्रेट या संपादित करना झंझट है। यहाँ तक कि sequelize-cli द्वारा माइग्रेशन स्क्रिप्ट जनरेट करने पर भी यह अभी भी कष्टप्रद है, हालांकि मैंने देखा है कि यह अधिकांश ORMs में एक सामान्य समस्या है।
  • दस्तावेज़ीकरण बहुत अच्छा नहीं है, हालांकि यह सुधार रहा है। सौभाग्य से, ChatGPT जैसे टूल्स ने अपने लंबे इतिहास के कारण Sequelize को अच्छी तरह समझा है, जिससे अंतर भरने में मदद मिली।
  • Prisma की तुलना में टाइप-सेंसिटिव नहीं है, जिससे कुछ प्रोजेक्ट्स में समस्याएँ हो सकती हैं।
  • सीमित TypeScript समर्थन, हालांकि यह STMS के लिए चिंता का विषय नहीं था, यह दूसरों के लिए निर्णायक हो सकता है।

Prisma के फायदे:

  • अपनी स्वयं की स्कीमा भाषा का उपयोग करता है, जिससे मॉडल निर्माण साफ़ और संक्षिप्त हो जाता है। तुलना के लिए, जबकि Mongoose ने हमारे बड़े डेटासेट के लिए 262 लाइनों ली, Prisma ने इसे केवल 221 लाइनों में संभाला।
  • एक CLI टूल के साथ आता है जो डेटाबेस निर्माण और माइग्रेशन को सरल बनाता है, जो अब तक मैंने किसी ORM में देखा सबसे अच्छा है, भले ही यह पूर्ण नहीं है।
  • कच्ची SQL क्वेरी का समर्थन करता है, जब आवश्यकता हो तो लचीलापन प्रदान करता है।
  • कोड सिंटैक्स साफ़ और Sequelize की तुलना में समझने में सरल है, जिससे सीखना आसान हो जाता है।
  • अपने क्लाइंट के माध्यम से Node.js और TypeScript के लिए क्वेरी बिल्डर स्वचालित रूप से जनरेट करता है, जो एक अच्छा स्पर्श है।
  • उत्कृष्ट, साफ़ दस्तावेज़ीकरण है। ChatGPT Prisma पर उतना अद्यतन नहीं है, लेकिन आधिकारिक दस्तावेज़ अक्सर इसकी भरपाई करते हैं।
  • समुदाय आँकड़े 15 मई, 2023 तक: NPM पर, अंतिम अपडेट 6 दिन पहले, 1,344,705 साप्ताहिक डाउनलोड; GitHub पर, अंतिम अपडेट 3 घंटे पहले, 1.1k फोर्क और 31.3k स्टार।

Prisma के नुकसान:

  • Postgres के लिए Regex फ़िल्टरिंग का समर्थन नहीं करता, हालांकि यह “contains”, “includes”, और “startsWith” जैसे विकल्प प्रदान करता है।
  • प्रदर्शन मेरे परीक्षणों में एक बड़ा मुद्दा था। हमारे बड़े डेटासेट के लिए प्रविष्टियों को बनाने में Prisma को लगभग 11.21 सेकंड प्रति प्रविष्टि लगा, जबकि Sequelize को 2.26 सेकंड, लगभग 5 गुना धीमा।
  • बड़े डेटासेट से एकल प्रविष्टि को हटाने में लगभग 4 मिनट लगे, जो हमारी आवश्यकताओं के लिए निर्णायक था।
  • जटिल, तीन-परत गहरी संबंध डेटासेट पर भी निष्पक्ष तुलना के साथ, Sequelize हटाने में काफी तेज़ था।
  • Prisma एक स्टार्टअप द्वारा समर्थित है जिसके पास $56.5 मिलियन फंडिंग है। जबकि इसका मुख्य ORM कोड Apache-2.0 के तहत ओपन सोर्स है, मैं संभावित लाइसेंस परिवर्तन के बारे में सतर्क हूँ, जैसा कि MongoDB के साथ हुआ था।

माइग्रेशन प्रक्रिया

डेटा संरचना रूपांतरण

MongoDB के दस्तावेज़ संरचना से Postgres की रिलेशनल संरचना में परिवर्तन करने के लिए सावधानीपूर्वक योजना बनानी पड़ी। मुझे करना पड़ा:

  1. संबंधों का विश्लेषण: पहचानें कि MongoDB दस्तावेज़ एक-दूसरे से कैसे संबंधित हैं और उपयुक्त विदेशी कुंजी संबंधों को डिज़ाइन करें
  2. डेटा को सामान्यीकृत करें: नेस्टेड दस्तावेज़ों को उपयुक्त स्थानों पर अलग-अलग तालिकाओं में विभाजित करें
  3. JSON सुविधाओं को संरक्षित रखें: वास्तव में असंरचित डेटा के लिए JSONB कॉलम का उपयोग करें जिसे लचीला रहना आवश्यक था
  4. इंडेक्स डिज़ाइन करें: क्वेरी प्रदर्शन के लिए उपयुक्त इंडेक्स बनाएं

कस्टम समाधान

माइग्रेशन के लिए कई कस्टम समाधान विकसित करने की आवश्यकता थी:

1. डेटा माइग्रेशन स्क्रिप्ट्स
मैंने व्यापक स्क्रिप्ट्स बनाई ताकि:

  • MongoDB कलेक्शनों से डेटा निकालें
  • दस्तावेज़ संरचनाओं को रिलेशनल फ़ॉर्मेट में बदलें
  • उचित संबंधों के साथ डेटा को Postgres तालिकाओं में आयात करें

2. API संगतता लेयर
शून्य डाउनटाइम बनाए रखने के लिए, मैंने एक संगतता लेयर बनाई जो कर सकती थी:

  • माइग्रेशन स्थिति के आधार पर अनुरोधों को MongoDB या Postgres में रूट करें
  • परिवर्तन अवधि के दौरान डेटा संगति सुनिश्चित करें
  • फ़ॉलबैक तंत्र प्रदान करें

3. कस्टम मिडलवेयर
MongoDB और Postgres के कुछ ऑपरेशनों को संभालने के तरीकों में अंतर को संभालने के लिए मिडलवेयर विकसित किया, जिससे मौजूदा API एंडपॉइंट्स बिना संशोधन के काम करना जारी रख सकें।

तकनीकी चुनौतियों को पार करना

जटिल संबंधों को संभालना

सबसे बड़ी चुनौतियों में से एक MongoDB के एम्बेडेड दस्तावेज़ों को Postgres संबंधों में बदलना था। उदाहरण के लिए, एक एकल MongoDB दस्तावेज़ में हो सकता है:

  • बेसिक प्रॉपर्टीज़
  • संबंधित इकाइयों का प्रतिनिधित्व करने वाले नेस्टेड ऑब्जेक्ट्स
  • एम्बेडेड दस्तावेज़ों के एरे

इसे सावधानीपूर्वक विभाजित करना पड़ा:

  • मुख्य इकाइयों के लिए प्राथमिक तालिकाएँ
  • बहु-से-बहु संबंधों के लिए जंक्शन तालिकाएँ
  • एक-से-बहु एसोसिएशन के लिए विदेशी कुंजी संबंध

क्वेरी अनुकूलन

MongoDB के क्वेरी पैटर्न सीधे SQL में अनुवादित नहीं होते। मुझे करना पड़ा:

  • जटिल एग्रीगेशन पाइपलाइन को SQL जॉइन्स के रूप में पुनर्लेखन करें
  • नए क्वेरी पैटर्न के लिए इंडेक्स को अनुकूलित करें
  • सुनिश्चित करें कि क्वेरी प्रदर्शन MongoDB प्रदर्शन को पूरा या उससे अधिक हो

डेटा अखंडता

माइग्रेशन के दौरान डेटा अखंडता सुनिश्चित करने के लिए आवश्यक था:

  • व्यापक वैलिडेशन स्क्रिप्ट्स
  • रोलबैक प्रक्रियाएँ
  • परिवर्तन अवधि के दौरान रीयल-टाइम डेटा सिंक्रनाइज़ेशन

परिणाम और प्रभाव

MongoDB से Postgres तक का STMS माइग्रेशन शून्य डाउनटाइम के साथ सफलतापूर्वक पूरा हुआ, जबकि लगभग सभी फीचर्स और कार्यक्षमता को बनाए रखा गया। परिणाम अपेक्षाओं से अधिक थे:

प्रदर्शन सुधार:

  • जटिल रिलेशनल क्वेरीज़ के लिए क्वेरी प्रदर्शन में सुधार हुआ
  • बेहतर डेटा संगति और अखंडता
  • अधिक कुशल स्टोरेज उपयोग

ऑपरेशनल लाभ:

  • उन्नत मॉनिटरिंग और डिबगिंग क्षमताएँ
  • eBay के मौजूदा SQL-आधारित टूल्स के साथ बेहतर एकीकरण
  • बेहतर बैकअप और रिकवरी प्रक्रियाएँ

टीम प्रभाव:

  • रिलेशनल डेटाबेस के बारे में टीम का ज्ञान बढ़ा
  • भविष्य के डेटाबेस माइग्रेशन के लिए पैटर्न स्थापित किए
  • पुन: उपयोग योग्य टूल्स और प्रक्रियाएँ बनाई

प्राप्त तकनीकी कौशल

इस प्रोजेक्ट ने मेरे तकनीकी विशेषज्ञता को काफी हद तक विस्तारित किया:

डेटाबेस तकनीकें:

  • Postgres सुविधाओं और अनुकूलन की गहरी समझ
  • SQL क्वेरी अनुकूलन और प्रदर्शन ट्यूनिंग
  • डेटाबेस डिज़ाइन पैटर्न और सामान्यीकरण
  • प्राइमरी-स्टैंडबाय डेटाबेस कॉन्फ़िगरेशन

डेवलपमेंट टूल्स:

  • Sequelize ORM और क्वेरी निर्माण
  • डेटाबेस माइग्रेशन रणनीतियाँ
  • प्रदर्शन परीक्षण पद्धतियाँ
  • डेटा वैलिडेशन और अखंडता जांच

आर्किटेक्चर पैटर्न:

  • शून्य-डाउनटाइम माइग्रेशन रणनीतियाँ
  • API संगतता लेयर
  • डेटाबेस एब्स्ट्रैक्शन पैटर्न
  • मॉनिटरिंग और अलर्टिंग सिस्टम

व्यक्तिगत और पेशेवर विकास

यह माइग्रेशन प्रोजेक्ट मेरे करियर विकास के लिए परिवर्तनकारी था। इसने मुझे अज्ञात क्षेत्र में धकेला, जिसके लिए आवश्यक था:

नेतृत्व कौशल:

  • पहले अनुभव के बिना एक जटिल तकनीकी प्रोजेक्ट का नेतृत्व करना
  • दबाव में महत्वपूर्ण आर्किटेक्चरल निर्णय लेना
  • कई टीमों और स्टेकहोल्डर्स के साथ समन्वय करना

समस्या-समाधान क्षमताएँ:

  • जटिल समस्याओं को प्रबंधनीय घटकों में विभाजित करना
  • अभूतपूर्व चुनौतियों के लिए रचनात्मक समाधान विकसित करना
  • कई प्रतिस्पर्धी आवश्यकताओं और प्रतिबंधों को संतुलित करना

संचार और टीमवर्क:

  • गैर-तकनीकी स्टेकहोल्डर्स को तकनीकी अवधारणाएँ समझाना
  • भविष्य के संदर्भ के लिए प्रक्रियाओं और निर्णयों का दस्तावेजीकरण
  • नई तकनीकों और पैटर्न पर टीम सदस्यों को मेंटरिंग करना

सीखे गए सबक

तकनीकी सबक

  1. डेटाबेस चयन महत्वपूर्ण है: NoSQL और SQL के बीच चयन विशिष्ट उपयोग मामलों और दीर्घकालिक आवश्यकताओं पर आधारित होना चाहिए
  2. प्रदर्शन परीक्षण महत्वपूर्ण है: सैद्धांतिक लाभ हमेशा वास्तविक दुनिया में प्रदर्शन सुधार में नहीं बदलते
  3. माइग्रेशन योजना: व्यापक योजना और परीक्षण जटिल माइग्रेशन के लिए आवश्यक हैं
  4. टूलिंग में निवेश: प्रारंभ में उचित टूलिंग बनाना काफी समय बचाता है और त्रुटियों को कम करता है

प्रोजेक्ट मैनेजमेंट सबक

  1. स्टेकहोल्डर संचार: नियमित अपडेट और स्पष्ट संचार गलतफहमियों को रोकते हैं
  2. जोखिम प्रबंधन: फ़ॉलबैक योजनाएँ और रोलबैक प्रक्रियाएँ होना आवश्यक है
  3. समयरेखा प्रबंधन: अप्रत्याशित चुनौतियों और सीखने की वक्रता के लिए बफ़र समय रखें
  4. दस्तावेज़ीकरण: विस्तृत दस्तावेज़ीकरण ज्ञान स्थानांतरण और भविष्य के रखरखाव को सक्षम बनाता है

निष्कर्ष

STMS MongoDB से Postgres तक का माइग्रेशन मेरे करियर में अब तक का सबसे चुनौतीपूर्ण और संतोषजनक तकनीकी समस्या है जिसे मैंने हल किया है। इसके लिए केवल तकनीकी विशेषज्ञता ही नहीं, बल्कि नेतृत्व, योजना और अनुकूलनशीलता भी आवश्यक थी। प्रोजेक्ट की सफलता ने यह सिद्ध किया कि उचित योजना, व्यापक परीक्षण और उत्कृष्टता के प्रति प्रतिबद्धता के साथ, सबसे जटिल तकनीकी चुनौतियों को भी पार किया जा सकता है।

इस अनुभव ने सॉफ़्टवेयर इंजीनियरिंग के प्रति मेरे दृष्टिकोण को मूल रूप से बदल दिया, जिससे महत्व पर ज़ोर दिया गया:

  • तकनीकी निर्णय लेने से पहले पूरे संदर्भ और आवश्यकताओं को समझना
  • उचित टूलिंग और परीक्षण में समय निवेश करना
  • जटिल प्रोजेक्ट्स के दौरान स्पष्ट संचार बनाए रखना
  • ज़रूरत पड़ने पर नई तकनीकों और दृष्टिकोणों को सीखने की इच्छा रखना

माइग्रेशन की सफलता ने न केवल STMS की क्षमताओं को सुधारा, बल्कि ऐसे पैटर्न और प्रक्रियाएँ स्थापित कीं जो eBay के इन्फ्रास्ट्रक्चर प्रोजेक्ट्स को लाभ पहुंचाती रहती हैं। इसने मेरे विश्वास को मजबूत किया कि अज्ञात चुनौतियों को अपनाना और उनमें सफल होना व्यक्तिगत और पेशेवर विकास दोनों के लिए कुंजी है।

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