MongoDB से PostgreSQL में बड़े पैमाने पर माइग्रेशन का अनुभव

 (infisical.com)
11 पॉइंट द्वारा GN⁺ 2024-03-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Infisical तेज़ी से बढ़ते हुए ऐसे प्लेटफ़ॉर्म के रूप में उभरा है जो हर दिन 5 करोड़ से अधिक secrets प्रोसेस करता है
  • उपयोग बढ़ने के साथ स्टैक को लगातार अपग्रेड करना ज़रूरी था, और हाल ही में MongoDB से PostgreSQL में पूरे डेटाबेस का माइग्रेशन किया गया
  • इस माइग्रेशन में नई तकनीक अपनाना, डेटाबेस स्कीमा बनाना, लॉजिक को फिर से संरचित करना, queries दोबारा लिखना, और लाखों (या अरबों) डेटा रिकॉर्ड्स को PostgreSQL में स्थानांतरित करना जैसी जटिल प्रक्रियाएँ शामिल थीं

शुरुआती चरण

  • Infisical को पहली बार बनाते समय, टीम ने वही स्टैक चुना जिससे वह सबसे अधिक परिचित थी: MongoDB + Mongoose ORM
  • शुरुआत में ध्यान Infisical Cloud, यानी managed SaaS ऑफ़रिंग, पर अधिक था और यह ज़्यादा अनुमान नहीं था कि उपयोगकर्ता प्रोडक्ट को self-host भी करेंगे

MongoDB क्यों नहीं?

  • शुरुआती दौर में MongoDB ने अच्छा काम किया, लेकिन जैसे-जैसे प्रोडक्ट के use case managed service से आगे बढ़े, इसकी कमियाँ सामने आने लगीं
  • कई संगठनों ने Infisical Cloud के बजाय Infisical को self-host करना पसंद किया, और कुछ को on-premise आवश्यकताओं को भी पूरा करना था
  • MongoDB की सीमाओं और usability समस्याओं के कारण PostgreSQL में जाने का फ़ैसला किया गया

PostgreSQL क्यों चुना?

  • नया डेटाबेस चुनते समय manageability, transaction support, और relational features जैसे पहलुओं को महत्वपूर्ण माना गया
  • internal storage और external storage solutions के बीच विचार-विमर्श हुआ, लेकिन अंततः PostgreSQL चुना गया
  • PostgreSQL सक्रिय community, समृद्ध documentation, कई solutions और extensions देता है, और ज़्यादातर cloud providers इसके managed services भी देते हैं

ORM के बारे में

  • PostgreSQL चुनने के बाद यह तय करना था कि application डेटाबेस के साथ किस तरह इंटरैक्ट करेगी
  • ऐसा टूल खोजा गया जो Mongoose ORM जैसा अनुभव दे सके, और Knex.js query builder इस्तेमाल करने का निर्णय लिया गया
  • Knex.js seeding और migration tools देता है, और TypeScript support के लिए custom Zod integration पर काम करके टीम संतोषजनक स्तर तक पहुँची

माइग्रेशन योजना

  • कोड rewrite लगभग पूरा होने पर यह सोचा गया कि MongoDB के डेटा को PostgreSQL में न्यूनतम व्यवधान के साथ मैप करने वाला माइग्रेशन कैसे किया जाए
  • Infisical की महत्वपूर्ण इन्फ्रास्ट्रक्चर भूमिका को देखते हुए किसी भी तरह का downtime स्वीकार्य नहीं था, इसलिए माइग्रेशन अवधि के दौरान writes रोकने का समझौता किया गया

बड़ा स्थानांतरण

  • माइग्रेशन की तैयारी के लिए एक विस्तृत checklist और अनुमानित timeline बनाई गई
  • माइग्रेशन 6 घंटे तक केवल reads की अनुमति देते हुए किया गया, और डेटा ट्रांसफ़र के बाद DNS को नए instance पर स्विच कर दिया गया

परिणाम

  • माइग्रेशन बिना डेटा लॉस के सुचारु रूप से पूरा हुआ, और ग्राहकों पर न्यूनतम असर डालने वाली कुछ फ़ीचर त्रुटियाँ 36 घंटे के भीतर ठीक कर दी गईं
  • joins के ज़रिए query optimization होने से प्लेटफ़ॉर्म की performance बेहतर हुई, और डेटाबेस लागत भी 50% कम हुई
  • PostgreSQL अपनाने से data validation बेहतर हुई, और अब Infisical को self-host करना काफ़ी आसान हो गया है

निष्कर्ष

  • MongoDB से PostgreSQL में जाने का फ़ैसला आसान नहीं था; सावधानीपूर्वक योजना और चर्चा के बाद इसमें 3-4 महीने लगे
  • ऐसी बड़ी परियोजना शुरू करने से पहले अपने use case और implementation पर गहराई से विचार करने की सलाह दी गई है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-30
Hacker News प्रतिक्रियाएँ

  • Postgres और MongoDB को बड़े पैमाने पर ऑपरेट करने का अनुभव रखने वाले एक उपयोगकर्ता ने कहा कि उन्हें दोनों डेटाबेस पसंद हैं, लेकिन Postgres में high availability (HA) और horizontal scaling सपोर्ट की कमी समझ से बाहर लगती है। उन्होंने बताया कि Postgres की हर installation कुछ अलग होती है, और इसे पूरा करने के लिए कई extensions और scripts का सहारा लेना पड़ता है। उन्होंने यह भी जोड़ा कि ये extensions अक्सर buggy होते हैं और इनका documentation कमजोर होता है। Postgres के major version file format बदलावों की वजह से upgrades बहुत कठिन हो जाते हैं। उन्हें यह देखकर आश्चर्य हुआ कि HA/sharding के मामले में MySQL, Postgres से काफी बेहतर है.

  • MongoDB से PostgreSQL में migration के अनुभव को तकनीकी दृष्टिकोण से समझाने वाली एक blog post साझा की गई। कहा गया कि इस पोस्ट में examples और graphs शामिल हैं, और यह ज्यादा technical है तथा इसमें business पक्ष कम है.

  • PostgreSQL के database दुनिया पर कब्ज़ा करने की बात करने वाले एक उपयोगकर्ता ने कहा कि लेखकों ने शुरुआत में ऐसा architecture चुना जो data model के लिए उपयुक्त नहीं था। उनका कहना था कि relational data को non-relational store में डालना हमेशा समस्याएँ पैदा करेगा.

  • इस बात में विरोधाभास की ओर इशारा किया गया कि MongoDB और Mongoose ORM को feature development की speed बढ़ाने के लिए सबसे सही विकल्प बताया गया, जबकि उसी चुनाव को सही ठहराने के लिए Tony Hoare के इस कथन का इस्तेमाल किया गया: "premature optimization is the root of all evil".

  • एक उपयोगकर्ता, जो मानता है कि document database नए projects के लिए उपयुक्त नहीं हैं, ने कहा कि MongoDB की licensing cost और hosting cost बढ़ेगी और feature development ठहर जाएगा.

  • MongoDB की वजह से समस्याएँ झेलने के बाद Postgres पर स्विच करने वाले एक उपयोगकर्ता ने कहा कि वे उस फैसले से बहुत संतुष्ट हैं। उन्होंने यह भी जोड़ा कि MongoDB में SQL की जगह JavaScript का इस्तेमाल असुविधाजनक था.

  • एक उपयोगकर्ता ने कहा कि असली rewrite प्रक्रिया के दौरान आई समस्याओं पर चर्चा गायब थी, और पूछा कि क्या queries को समान रूप से लागू किया गया था, product को दोनों databases पर read/write करने लायक कैसे बनाया गया, migration के दौरान bugs मिले या नहीं, और क्या queries को 1:1 migrate किया जा सका.

  • MongoDB इस्तेमाल कर चुके एक उपयोगकर्ता ने कहा कि document databases कुछ use cases के लिए उपयुक्त हो सकते हैं, लेकिन जब आपको महसूस हो कि Mongoose का इस्तेमाल करना पड़ेगा, तो relational database पर जाने के बारे में सोचना चाहिए। उनका कहना था कि ज़्यादातर मामलों में Mongoose को मौजूदा project में बाद में जोड़ा जाता है, और अगर शुरुआत से इसकी ज़रूरत है तो relational database इस्तेमाल करना चाहिए.

  • MongoDB इस्तेमाल करने वाला एक project संभाल चुके एक उपयोगकर्ता ने कहा कि BSON format अच्छा नहीं है, लेकिन उन्हें यह पसंद है कि JSON API से लेकर database तक एक ही schema इस्तेमाल किया जा सकता है। उन्होंने जोड़ा कि यह Go और Rust में data-oriented programming के लिए अच्छा है। उनका निष्कर्ष था कि MongoDB केवल read-heavy workloads के लिए उपयुक्त है, और write-heavy मामलों में यह ज्यादा मददगार नहीं है.

  • एक उपयोगकर्ता ने कहा कि PostgreSQL पर स्विच करने की मुख्य वजह तकनीकी कारणों से ज्यादा licensing issues थे। उन्होंने साझा किया कि joins का उपयोग करके query optimization के कारण performance में सुधार मिला। चूँकि data को key-value store के लिए उपयुक्त तरीके से model नहीं किया गया था, इसलिए सही प्रकार के store में जाना ही निर्णायक कारण बना.