ਮੋਂਗੋਡੀਬੀ ਤੋਂ ਪੋਸਟਗ੍ਰੇਸ

ਨੋਟ: ਇਹ ਬਲੌਗ ਪੋਸਟ ਮੇਰੇ ਮੋਂਗੋਡੀਬੀ ਤੋਂ ਪੋਸਟਗ੍ਰੇਸ (2024-03-06) ਅਤੇ ਸੀਕ੍ਵੇਲਾਈਜ਼ ਵਿਰੁੱਧ ਪ੍ਰਿਸਮਾ (2023-05-25) ਦਾ ਇਕੱਠ ਹੈ। ਮੂਲ ਬਲੌਗ ਹਟਾ ਦਿੱਤੇ ਗਏ ਹਨ, ਅਤੇ ਇਸ ਬਲੌਗ ਨੇ ਉਨ੍ਹਾਂ ਦੀ ਥਾਂ ਲੈ ਲਈ ਹੈ ਕਿਉਂਕਿ ਦੋਵਾਂ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਉਹੀ ਸਮੱਗਰੀ/ਜਾਣਕਾਰੀ ਸੀ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਰਚ 2023 ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ, ਸਵਿੱਚ ਨਵੰਬਰ 2023 ਦੇ ਮੱਧ ਵਿੱਚ ਹੋਇਆ, ਅਤੇ ਪੁਰਾਣੇ ਮੋਂਗੋਡੀਬੀ ਸਿਸਟਮ ਦੀਆਂ ਸਾਰੀਆਂ ਇੰਸਟੈਂਸਾਂ ਜਨਵਰੀ 2024 ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿੱਤੀਆਂ ਗਈਆਂ।

ਪਰਿਚਯ

eBay ਵਿੱਚ ਆਪਣੇ ਸਮੇਂ ਦੌਰਾਨ, ਮੈਂ ਆਪਣੇ ਕਰੀਅਰ ਦੀ ਸਭ ਤੋਂ ਤਕਨੀਕੀ ਤੌਰ ‘ਤੇ ਚੁਣੌਤੀਪੂਰਨ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ: Storage Management System (STMS) ਨੂੰ MongoDB ਤੋਂ Postgres ਵੱਲ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ। ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸਧਾਰਣ ਡਾਟਾਬੇਸ ਬਦਲਣਾ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕ ਅਹਿਮ ਸਿਸਟਮ ਦੇ ਪੂਰੇ ਆਰਕੀਟੈਕਚਰ ਦਾ ਪਰਿਵਰਤਨ ਸੀ ਜੋ eBay ਦੇ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਪ੍ਰਤੀ ਮਿੰਟ 1.5 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਮੈਟ੍ਰਿਕਸ ਇਨਜੈਸਟ ਕਰਦਾ ਹੈ, ਉਹ ਵੀ ਬਿਨਾਂ ਕਿਸੇ ਡਾਊਨਟਾਈਮ ਅਤੇ ਲਗਭਗ ਸਾਰੀਆਂ ਮੌਜੂਦਾ ਕਾਰਗੁਜ਼ਾਰੀਆਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਲੋੜ ਨਾਲ।

STMS ਕੀ ਹੈ?

Storage Management System (STMS) eBay ਦੀ Service & Storage Infrastructure (SSI) ਟੀਮ ਲਈ ਇੱਕ ਅਹਿਮ ਅੰਦਰੂਨੀ ਟੂਲ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ eBay ਦੇ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਡਿਵਾਈਸਾਂ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੰਜੀਨੀਅਰ ਇਹ ਕਰ ਸਕਦੇ ਹਨ:

• ਦਰਜਨਾਂ ਐਰੇਜ਼, ਸਵਿੱਚਾਂ, ਹੋਸਟਾਂ, ਡਿਸਕ ਗਰੁੱਪਾਂ, ਅਤੇ ਕਲੱਸਟਰਾਂ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ
• ਸਵਿੱਚਾਂ ਅਤੇ ਐਰੇਜ਼ ਲਈ ਅਲਰਟਿੰਗ ਨੂੰ ਸੰਭਾਲਣਾ
• ਹੋਸਟ ਅਲੋਕੇਸ਼ਨ ਵਰਗੇ ਉੱਨਤ ਕੰਮ ਪੂਰੇ ਕਰਨਾ
• ਹੋਰ ਅੰਦਰੂਨੀ eBay ਸੇਵਾਵਾਂ ਲਈ ਰੀਅਲ-ਟਾਈਮ ਡਾਟਾ ਤੱਕ ਪਹੁੰਚ

STMS eBay ਦੇ 3 ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ 70 ਤੋਂ ਵੱਧ ਐਰੇਜ਼, 60 ਸਵਿੱਚਾਂ, 1100 ਹੋਸਟਾਂ, 900 ਡਿਸਕ ਗਰੁੱਪਾਂ, ਅਤੇ 200 ਕਲੱਸਟਰਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। eBay ਦੇ ਇਨਫ੍ਰਾਸਟਰੱਕਚਰ ਵਿੱਚ ਇਸ ਦੀ ਅਹਿਮ ਭੂਮਿਕਾ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਕੋਈ ਵੀ ਡਾਊਨਟਾਈਮ ਜਾਂ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਘਾਟ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਕੰਪਨੀ ਦੀਆਂ ਮੁੱਖ ਸੇਵਾਵਾਂ ਅਤੇ ਵਪਾਰਕ ਕਾਰਜਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ।

ਚੁਣੌਤੀ

ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਿਉਂ ਜ਼ਰੂਰੀ ਸੀ

MongoDB ਤੋਂ Postgres ਵੱਲ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਹੌਲੀ-ਹੌਲੀ ਨਹੀਂ ਲਿਆ ਗਿਆ ਸੀ। ਜਦਕਿ MongoDB ਨੇ ਸ਼ੁਰੂ ਵਿੱਚ STMS ਦੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੇਵਾ ਕੀਤੀ ਸੀ, ਸਾਡੇ ਡਾਟਾ ਸੰਬੰਧਾਂ ਦੀ ਵਧਦੀ ਜਟਿਲਤਾ ਅਤੇ ਹੋਰ ਸੁਧਾਰੇ ਹੋਏ ਕਵੈਰੀ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦੀ ਲੋੜ ਨੇ ਸਾਡੇ ਯੂਜ਼ ਕੇਸ ਲਈ Postgres ਨੂੰ ਇੱਕ ਬਿਹਤਰ ਲੰਬੇ ਸਮੇਂ ਦਾ ਹੱਲ ਬਣਾ ਦਿੱਤਾ।

ਇਹ ਸਮੱਸਿਆ ਮੁਸ਼ਕਲ ਕਿਉਂ ਸੀ

ਇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਜਟਿਲਤਾ ਕਈ ਬੁਨਿਆਦੀ ਚੁਣੌਤੀਆਂ ਤੋਂ ਉੱਭਰੀ:

1. ਡਾਟਾਬੇਸਾਂ ਵਿਚਲੇ ਮੂਲਭੂਤ ਅੰਤਰ MongoDB ਅਤੇ Postgres ਮੂਲ ਰੂਪ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਡਾਟਾਬੇਸ ਹਨ। MongoDB ਇੱਕ ਡੌਕਯੂਮੈਂਟ-ਆਧਾਰਤ ਡਾਟਾਬੇਸ (NoSQL) ਹੈ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਕਿ ਡਾਟਾ ਕਲੈਕਸ਼ਨਾਂ ਵਿੱਚ JSON ਵਜੋਂ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਬਿਲਕੁਲ ਫਾਈਲਿੰਗ ਕੈਬਨਿਟ ਵਿੱਚ ਡੌਕਯੂਮੈਂਟਾਂ ਵਾਂਗ। Postgres ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡਾਟਾਬੇਸ (SQL) ਹੈ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਕਿ ਡਾਟਾ ਟੇਬਲਾਂ ਵਿੱਚ ਕਤਾਰਾਂ ਵਜੋਂ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਬਿਲਕੁਲ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਾਂਗ।

2. ਕੋਡਬੇਸ ਆਰਕੀਟੈਕਚਰ STMS ਦਾ ਪੂਰਾ ਬੈਕਐਂਡ ਡਾਟਾ ਨੂੰ JSONs ਵਜੋਂ ਪ੍ਰੋਸੈਸ ਕਰਨ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ MongoDB ਨਾਲ ਅਨੁਕੂਲ ਪੈਕੇਜਾਂ ਦੀ ਵਰਤੋਂ ਡਾਟਾਬੇਸ ਕਾਰਵਾਈਆਂ ਲਈ ਕੀਤੀ ਗਈ ਸੀ। ਇਸਦਾ ਅਰਥ ਸੀ ਕਿ ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਬਦਲਣਾ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਵੀ ਬਦਲਣਾ ਕਿ ਸਾਡੀ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਡਾਟਾ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੀ ਹੈ।

3. ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਦੀ ਲੋੜ ਕਿਉਂਕਿ STMS ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ ਵਜੋਂ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਕੋਈ ਡਾਊਨਟਾਈਮ ਨਹੀਂ ਹੋ ਸਕਦਾ ਸੀ। ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਸਿਸਟਮ ਨੂੰ ਪ੍ਰਤੀ ਮਿੰਟ 1.5+ ਮਿਲੀਅਨ ਮੈਟ੍ਰਿਕਸ ਸੇਵਾ ਦਿੰਦੇ ਰਹਿਣਾ ਸੀ।

4. ਤੰਗ ਸਮਾਂ-ਸੀਮਾ ਅਤੇ ਸੀਮਿਤ ਤਜਰਬਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ ਪੂਰਾ ਕਰਨਾ ਸੀ, ਅਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕੋਈ ਸਪਸ਼ਟ ਕਾਰਜਨਵਾਈ ਯੋਜਨਾ ਨਹੀਂ ਸੀ। ਨਾ ਮੈਂ ਅਤੇ ਨਾ ਹੀ ਮੇਰੇ ਸਹਿਕਰਮੀ ਇੱਕ ਵੱਡੇ ਲੈਗੇਸੀ ਕੋਡਬੇਸ ਨੂੰ NoSQL ਤੋਂ SQL ਡਾਟਾਬੇਸਾਂ ਵੱਲ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦਾ ਤਜਰਬਾ ਰੱਖਦੇ ਸੀ, ਅਤੇ ਮੇਰੇ ਕੋਲ Postgres ਨਾਲ ਸੀਮਿਤ ਪਿਛਲਾ ਤਜਰਬਾ ਸੀ।

5. ਪੈਮਾਨਾ ਅਤੇ ਜਟਿਲਤਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੱਚ 36 MongoDB ਕਲੈਕਸ਼ਨਾਂ ਨੂੰ 74 Postgres ਟੇਬਲਾਂ ਵਿੱਚ ਬਦਲਣਾ ਸ਼ਾਮਲ ਸੀ, ਜਿਸ ਲਈ ਸੰਬੰਧਾਂ, ਇੰਡੈਕਸਿੰਗ, ਅਤੇ ਕਵੈਰੀ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਬਾਰੇ ਧਿਆਨਪੂਰਵਕ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਸੀ।

ਸਹੀ ORM ਦੀ ਚੋਣ: ਸੀਕ੍ਵੇਲਾਈਜ਼ ਵਿਰੁੱਧ ਪ੍ਰਿਸਮਾ

ਪਹਿਲੇ ਵੱਡੇ ਫੈਸਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ ORM (Object-Relational Mapping) ਟੂਲ ਦੀ ਚੋਣ। ਕਿਉਂਕਿ ਸਾਡਾ ਕੋਡਬੇਸ ਪਹਿਲਾਂ ਹੀ MongoDB ਲਈ Mongoose ਵਰਤਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਸ ਲਈ ORM ਦੀ ਵਰਤੋਂ ਸਭ ਤੋਂ ਸਹਿਜ ਤਬਦੀਲੀ ਰਾਹ ਪ੍ਰਦਾਨ ਕਰਦੀ।

ਲੋੜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਧਿਆਨਪੂਰਵਕ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਕਿਸੇ ਵੀ ORM ਹੱਲ ਲਈ ਜ਼ਰੂਰੀ ਮਾਪਦੰਡ ਸਥਾਪਿਤ ਕੀਤੇ:

• JavaScript ਪੈਕੇਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਸਾਡੇ ਕੋਡ ਦਾ ਵਧੇਰੇ ਹਿੱਸਾ JavaScript ਵਿੱਚ ਲਿਖਿਆ ਸੀ)
• Postgres ਅਤੇ ਇਸ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
• ਕਾਰਗੁਜ਼ਾਰੀ ਘੱਟੋ-ਘੱਟ Mongoose ਦੇ ਬਰਾਬਰ ਜਾਂ ਉਸ ਤੋਂ ਵਧੀਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ
• ਓਪਨ ਸੋਰਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਰੱਖ-ਰਖਾਵ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੋਵੇ

ਉਮੀਦਵਾਰ

ਵਿਆਪਕ ਖੋਜ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਦੋ ਮੁੱਖ ਦਾਅਵੇਦਾਰਾਂ ਤੱਕ ਸੀਮਿਤ ਹੋ ਗਿਆ: Sequelize ਅਤੇ Prisma। ਮੈਂ Docker ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ Postgres ਲਈ ਵਿਸਤ੍ਰਿਤ ਟੈਸਟਿੰਗ ਵਾਤਾਵਰਣ ਬਣਾਏ ਅਤੇ ਆਪਣੇ ਸਭ ਤੋਂ ਵੱਡੇ, ਸਭ ਤੋਂ ਜਟਿਲ ਡੈਟਾਸੈੱਟ ਨੂੰ ਡੌਕਯੂਮੈਂਟ ਸੰਰਚਨਾ ਤੋਂ ਟੇਬਲ ਸੰਰਚਨਾ ਵਿੱਚ ਬਦਲਿਆ।

ਟੈਸਟਿੰਗ ਵਿਧੀ

ਹਰ ORM ਲਈ, ਮੈਂ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਮਾਪੀ:

• ਇੱਕ ਐਂਟਰੀ ਬਣਾਉਣ ਦਾ ਸਮਾਂ
• ਇੱਕ ਐਂਟਰੀ ਅਪਡੇਟ ਕਰਨ ਦਾ ਸਮਾਂ
• ਨੇਸਟਡ ਐਂਟਰੀਆਂ ਅਪਡੇਟ ਕਰਨ ਦਾ ਸਮਾਂ (ਸੰਬੰਧ ਅਤੇ JSON ਕੀ-ਵੈਲਯੂਜ਼)
• ਇੱਕ ਐਂਟਰੀ ਮਿਟਾਉਣ ਦਾ ਸਮਾਂ
• ਇੱਕ ਐਂਟਰੀ ਕਵੈਰੀ/ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਮਾਂ

ਫੈਸਲਾ: ਸੀਕ੍ਵੇਲਾਈਜ਼

ਲਗਭਗ 15 ਮਈ, 2023 ਨੂੰ, ਮੈਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ Sequelize ਸਾਡੇ ਯੂਜ਼ ਕੇਸ ਲਈ ਬਿਹਤਰ ORM ਸੀ। ਇਹ ਰਹੇ ਕਾਰਨ:

ਸੀਕ੍ਵੇਲਾਈਜ਼ ਦੇ ਫਾਇਦੇ:

• ਸੱਚਮੁੱਚ ਓਪਨ-ਸੋਰਸ ਹੈ ਅਤੇ ਕਿਸੇ ਫੰਡਡ ਸਟਾਰਟਅੱਪ ਦੁਆਰਾ ਰੱਖ-ਰਖਾਵ ਨਹੀਂ ਕੀਤਾ ਜਾ ਰਿਹਾ
• Postgres ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ
• ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ, ਖਾਸ ਕਰਕੇ Prisma ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ
• 10 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਵਿਕਾਸ ਵਾਲਾ ਪਰਿਪੱਕ ਇਕੋਸਿਸਟਮ
• JavaScript ਕਲਾਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ ਲਚਕੀਲਾ ਮਾਡਲ/ਸਕੀਮਾ ਪ੍ਰਤਿਨਿਧੀਕਰਨ
• Regex ਸਮੇਤ ਜਟਿਲ ਜੋਇਨਜ਼ ਅਤੇ ਫਿਲਟਰਿੰਗ ਵਿਕਲਪਾਂ ਲਈ ਸਮਰਥਨ

ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਨਤੀਜੇ:

ਮੇਰੀ ਟੈਸਟਿੰਗ ਵਿੱਚ, Sequelize ਨੇ Prisma ਨਾਲੋਂ ਕਾਫ਼ੀ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ। ਸਾਡੇ ਵੱਡੇ ਡੈਟਾਸੈੱਟ ਐਂਟਰੀਆਂ ਲਈ:

• Sequelize: ਪ੍ਰਤੀ ਐਂਟਰੀ ਲਗਭਗ 2.26 ਸਕਿੰਟ
• Prisma: ਪ੍ਰਤੀ ਐਂਟਰੀ ਲਗਭਗ 11.21 ਸਕਿੰਟ

ਸਾਡੇ ਯੂਜ਼ ਕੇਸ ਲਈ Prisma, Sequelize ਨਾਲੋਂ ਲਗਭਗ 5 ਗੁਣਾ ਹੌਲੀ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਸਭ ਤੋਂ ਵੱਡੇ ਡੈਟਾਸੈੱਟ ਤੋਂ ਇੱਕ ਐਂਟਰੀ ਮਿਟਾਉਣ ਵਿੱਚ Prisma ਨੂੰ ਲਗਭਗ 4 ਮਿੰਟ ਲੱਗਦੇ ਸਨ, ਜੋ ਸਾਡੀਆਂ ਲੋੜਾਂ ਲਈ ਅਸਵੀਕਾਰਯੋਗ ਸੀ।

ਸੀਕ੍ਵੇਲਾਈਜ਼ ਦੀਆਂ ਚੁਣੌਤੀਆਂ:

• ਹੋਰ ਜਟਿਲ ਅਤੇ ਫੁੱਲਿਆ ਹੋਇਆ ਮਾਡਲ ਪ੍ਰਤਿਨਿਧੀਕਰਨ (Mongoose ਲਈ 262 ਲਾਈਨਾਂ ਦੇ ਮੁਕਾਬਲੇ 564 ਲਾਈਨਾਂ)
• ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਲਝਣ ਭਰਾ ਸਿੰਟੈਕਸ
• ਡਾਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਜਟਿਲਤਾ
• Prisma ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ ਘੱਟ ਵਿਸਤ੍ਰਿਤ ਦਸਤਾਵੇਜ਼ੀਕਰਨ

ਸੀਕ੍ਵੇਲਾਈਜ਼ ਅਤੇ ਪ੍ਰਿਸਮਾ ਦੀਆਂ ਫਾਇਦਿਆਂ ਅਤੇ ਨੁਕਸਾਨਾਂ ਦੀ ਤੁਲਨਾ

ਇਹ ਪੂਰੀ ਤਸਵੀਰ ਦੇਣ ਲਈ ਕਿ ਮੈਂ Sequelize ਕਿਉਂ ਚੁਣਿਆ, ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਆਪਣੀ ਮੁਲਾਂਕਣ ਦੌਰਾਨ ਦੋਵਾਂ ORMs ਲਈ ਇਕੱਠੇ ਕੀਤੇ ਵਿਸਤ੍ਰਿਤ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਸਾਂਝੇ ਕਰਾਂ। ਮੈਂ ਇਹ ਵੀ ਵੇਖਿਆ ਕਿ 15 ਮਈ, 2023 ਤੱਕ ਸਕੀਮਾ ਪ੍ਰਤਿਨਿਧੀਕਰਨ ਅਤੇ ਕਮਿਊਨਿਟੀ ਸਹਾਇਤਾ ਦੇ ਪੱਖ ਤੋਂ ਇਹ ਕਿਵੇਂ ਸਨ। ਇਸ ਡੂੰਘੀ ਜਾਂਚ ਨੇ ਮੇਰੀ ਚੋਣ ਨੂੰ ਪੱਕਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਅਤੇ ਮੈਂ ਆਸ ਕਰਦਾ ਹਾਂ ਕਿ ਇਹ ਕਿਸੇ ਹੋਰ ਲਈ ਵੀ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ ਫੈਸਲੇ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਿਹਾ ਹੋਵੇ।

ਸੀਕ੍ਵੇਲਾਈਜ਼ ਦੇ ਫਾਇਦੇ:

• ਇਸ ਵਿੱਚ ਇੱਕ sync() ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਆਪਣੇ ਆਪ ਤੁਹਾਡੇ ਲਈ ਟੇਬਲਾਂ ਬਣਾਉਂਦਾ ਅਤੇ ਸੰਭਾਲਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕਾਫ਼ੀ ਹੱਥੀਂ ਮਿਹਨਤ ਬਚਦੀ ਹੈ।
• ਨੇਸਟਡ ਡਾਟਾ ਲਈ ਜਟਿਲ ਜੋਇਨਜ਼ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਜੋ STMS ਦੀ ਸੰਰਚਨਾ ਲਈ ਅਤਿ ਅਹਿਮ ਸੀ।
• Regex ਸਮੇਤ ਫਿਲਟਰਿੰਗ ਵਿਕਲਪਾਂ ਦੀ ਵਿਸ਼ਾਲ ਰੇਂਜ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜੋ ਕਵੈਰੀਆਂ ਵਿੱਚ ਲਚਕਤਾ ਦਿੰਦਾ ਹੈ।
• ਮਾਡਲ/ਸਕੀਮਾ ਪ੍ਰਤਿਨਿਧੀਕਰਨ ਰਾਅ JavaScript ਵਿੱਚ ਕਲਾਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਖਾਸ ਲੋੜਾਂ ਅਨੁਸਾਰ ਢਾਲਣ ਲਈ ਬਹੁਤ ਕਸਟਮਾਈਜ਼ੇਬਲ ਹਨ।
• ਡਾਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਈ ਰੀਡ-ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਸਮਰਥਨ ਸ਼ਾਮਲ ਹੈ।
• ਜਦੋਂ ਤੁਹਾਨੂੰ ਅੰਦਰ ਦੀ ਪਰਤ ਤੱਕ ਜਾਣ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਰਾਅ SQL ਕਵੈਰੀਆਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
• 15 ਮਈ, 2023 ਤੱਕ ਕਮਿਊਨਿਟੀ ਅੰਕੜੇ: NPM ‘ਤੇ, ਆਖ਼ਰੀ ਵਾਰ 14 ਦਿਨ ਪਹਿਲਾਂ ਅਪਡੇਟ ਹੋਇਆ, 1,505,835 ਹਫ਼ਤਾਵਾਰੀ ਡਾਊਨਲੋਡਾਂ ਨਾਲ; GitHub ‘ਤੇ, ਆਖ਼ਰੀ ਵਾਰ ਕੱਲ੍ਹ ਅਪਡੇਟ ਹੋਇਆ, 4.2k Forks ਅਤੇ 27.9k Stars ਨਾਲ। ਇਹ 10 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੋਂ MIT ਲਾਇਸੈਂਸ ਹੇਠ ਓਪਨ ਸੋਰਸ ਰਿਹਾ ਹੈ, ਇਸ ਲਈ ਮੈਨੂੰ ਭਰੋਸਾ ਹੈ ਕਿ ਇਹ ਇਸੇ ਤਰ੍ਹਾਂ ਰਹੇਗਾ।

ਸੀਕ੍ਵੇਲਾਈਜ਼ ਦੇ ਨੁਕਸਾਨ:

• ਮਾਡਲ/ਸਕੀਮਾ ਪ੍ਰਤਿਨਿਧੀਕਰਨ ਬਹੁਤ ਜਟਿਲ ਅਤੇ ਫੁੱਲਿਆ ਹੋਇਆ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਕਿ ਸਾਡੇ ਵੱਡੇ ਡੈਟਾਸੈੱਟ ਲਈ Mongoose ਪ੍ਰਤਿਨਿਧੀਕਰਨ ਲਗਭਗ 262 ਲਾਈਨਾਂ ਦਾ ਸੀ (ਖਾਲੀ ਥਾਵਾਂ ਸਮੇਤ), Sequelize ਵਿੱਚ ਉਹੀ ਡੈਟਾਸੈੱਟ 564 ਲਾਈਨਾਂ ਤੱਕ ਵੱਧ ਗਿਆ।
• ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਿੰਟੈਕਸ ਉਲਝਣ ਭਰਾ ਅਤੇ ਜਟਿਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਕਾਰਨ ਕਈ ਵਾਰ ਮੇਰੀ ਗਤੀ ਹੌਲੀ ਪੈ ਗਈ।
• ਡਾਟਾਬੇਸ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਜਾਂ ਸੰਪਾਦਿਤ ਕਰਨਾ ਔਖਾ ਕੰਮ ਹੈ। ਭਾਵੇਂ sequelize-cli ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਬਣਾਉਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਇਹ ਕਾਫ਼ੀ ਔਖਾ ਹੈ, ਹਾਲਾਂਕਿ ਮੈਂ ਦੇਖਿਆ ਹੈ ਕਿ ਇਹ ਜ਼ਿਆਦਾਤਰ ORMs ਵਿੱਚ ਇੱਕ ਆਮ ਦਰਦ-ਬਿੰਦੂ ਹੈ।
• ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਧੀਆ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਸੁਧਰ ਰਿਹਾ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ChatGPT ਵਰਗੇ ਟੂਲਾਂ ਨੂੰ ਇਸ ਦੇ ਲੰਮੇ ਇਤਿਹਾਸ ਕਰਕੇ Sequelize ਦੀ ਮਜ਼ਬੂਤ ਸਮਝ ਹੈ, ਜਿਸ ਨੇ ਖਾਲੀਆਂ ਥਾਵਾਂ ਭਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।
• Prisma ਜਿੰਨਾ ਟਾਈਪ-ਸੈਂਸੇਟਿਵ ਨਹੀਂ, ਜੋ ਕੁਝ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
• TypeScript ਲਈ ਸੀਮਿਤ ਸਮਰਥਨ, ਹਾਲਾਂਕਿ ਇਹ STMS ਲਈ ਚਿੰਤਾ ਦਾ ਵਿਸ਼ਾ ਨਹੀਂ ਸੀ, ਪਰ ਹੋਰਾਂ ਲਈ ਇਹ ਇੱਕ ਨਿਰਣਾਇਕ ਕਾਰਕ ਹੋ ਸਕਦਾ ਹੈ।

ਪ੍ਰਿਸਮਾ ਦੇ ਫਾਇਦੇ:

• ਆਪਣੀ ਖੁਦ ਦੀ ਸਕੀਮਾ ਭਾਸ਼ਾ ਵਰਤਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਾਡਲ ਬਣਾਉਣਾ ਹੋਰ ਸਾਫ਼ ਅਤੇ ਸੰਖੇਪ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੁਲਨਾ ਲਈ, ਜਦੋਂ Mongoose ਨੇ ਸਾਡੇ ਵੱਡੇ ਡੈਟਾਸੈੱਟ ਲਈ 262 ਲਾਈਨਾਂ ਲਈਆਂ, Prisma ਨੇ ਇਸਨੂੰ ਸਿਰਫ਼ 221 ਲਾਈਨਾਂ ਵਿੱਚ ਸੰਭਾਲ ਲਿਆ।
• ਇੱਕ CLI ਟੂਲ ਨਾਲ ਆਉਂਦਾ ਹੈ ਜੋ ਡਾਟਾਬੇਸ ਬਣਾਉਣ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ ਹੁਣ ਤੱਕ ਮੈਂ ਕਿਸੇ ORM ਤੋਂ ਦੇਖਿਆ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ, ਭਾਵੇਂ ਇਹ ਪੂਰਾ ਨਹੀਂ।
• ਰਾਅ SQL ਕਵੈਰੀਆਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਲਚਕਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• Sequelize ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ ਕੋਡ ਸਿੰਟੈਕਸ ਸਾਫ਼ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਸੌਖਾ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਸਿੱਖਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਆਪਣੇ ਕਲਾਇੰਟ ਰਾਹੀਂ Node.js ਅਤੇ TypeScript ਲਈ ਕਵੈਰੀ ਬਿਲਡਰ ਆਪਣੇ ਆਪ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਇੱਕ ਵਧੀਆ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।
• ਸ਼ਾਨਦਾਰ, ਸਾਫ਼ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਹੈ। ChatGPT Prisma ਬਾਰੇ ਇੰਨਾ ਅਪ-ਟੂ-ਡੇਟ ਨਹੀਂ ਹੈ, ਪਰ ਅਕਸਰ ਸਰਕਾਰੀ ਦਸਤਾਵੇਜ਼ ਇਸ ਦੀ ਕਮੀ ਪੂਰੀ ਕਰ ਦਿੰਦੇ ਸਨ।
• 15 ਮਈ, 2023 ਤੱਕ ਕਮਿਊਨਿਟੀ ਅੰਕੜੇ: NPM ‘ਤੇ, ਆਖ਼ਰੀ ਵਾਰ 6 ਦਿਨ ਪਹਿਲਾਂ ਅਪਡੇਟ ਹੋਇਆ, 1,344,705 ਹਫ਼ਤਾਵਾਰੀ ਡਾਊਨਲੋਡਾਂ ਨਾਲ; GitHub ‘ਤੇ, ਆਖ਼ਰੀ ਵਾਰ 3 ਘੰਟੇ ਪਹਿਲਾਂ ਅਪਡੇਟ ਹੋਇਆ, 1.1k Forks ਅਤੇ 31.3k Stars ਨਾਲ।

ਪ੍ਰਿਸਮਾ ਦੇ ਨੁਕਸਾਨ:

• Postgres ਲਈ Regex ਫਿਲਟਰਿੰਗ ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਹਾਲਾਂਕਿ ਇਹ “contains,” “includes,” ਅਤੇ “startsWith” ਵਰਗੇ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਮੇਰੇ ਟੈਸਟਾਂ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਸੀ। ਸਾਡੇ ਵੱਡੇ ਡੈਟਾਸੈੱਟ ਲਈ ਐਂਟਰੀਆਂ ਬਣਾਉਣ ਵਿੱਚ Prisma ਨੂੰ ਪ੍ਰਤੀ ਐਂਟਰੀ ਲਗਭਗ 11.21 ਸਕਿੰਟ ਲੱਗੇ, ਜਦਕਿ Sequelize ਨੂੰ 2.26 ਸਕਿੰਟ, ਯਾਨੀ ਲਗਭਗ 5 ਗੁਣਾ ਹੌਲੀ।
• ਵੱਡੇ ਡੈਟਾਸੈੱਟ ਤੋਂ ਇੱਕੋ ਇੱਕ ਐਂਟਰੀ ਮਿਟਾਉਣ ਵਿੱਚ ਲਗਭਗ 4 ਮਿੰਟ ਲੱਗੇ, ਜੋ ਸਾਡੀਆਂ ਲੋੜਾਂ ਲਈ ਇੱਕ ਨਿਰਣਾਇਕ ਰੁਕਾਵਟ ਸੀ।
• ਤਿੰਨ-ਪਰਤਾਂ ਡੂੰਘੇ ਸੰਬੰਧਾਂ ਵਾਲੇ ਜਟਿਲ ਡੈਟਾਸੈੱਟ ‘ਤੇ ਨਿਆਂਸੰਗਤ ਤੁਲਨਾ ਦੇ ਬਾਵਜੂਦ, Sequelize ਮਿਟਾਉਣਾਂ ਵਿੱਚ ਕਾਫ਼ੀ ਤੇਜ਼ ਸੀ।
• Prisma ਨੂੰ $56.5 ਮਿਲੀਅਨ ਫੰਡਿੰਗ ਵਾਲੀ ਸਟਾਰਟਅੱਪ ਦਾ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਹੈ। ਜਦਕਿ ਇਸ ਦਾ ਮੁੱਖ ORM ਕੋਡ Apache-2.0 ਹੇਠ ਓਪਨ ਸੋਰਸ ਹੈ, ਮੈਂ ਭਵਿੱਖ ਵਿੱਚ ਲਾਇਸੈਂਸਿੰਗ ਬਦਲਾਅ ਦੀ ਸੰਭਾਵਨਾ ਬਾਰੇ ਸਾਵਧਾਨ ਹਾਂ, ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ MongoDB ਨਾਲ ਹੋਇਆ ਸੀ।

ਇਨ੍ਹਾਂ ਵਿਸਤ੍ਰਿਤ ਤੁਲਨਾਵਾਂ ਨੇ ਇਹ ਸਪਸ਼ਟ ਕਰ ਦਿੱਤਾ ਕਿ Sequelize STMS ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਵਧੇਰੇ ਮੇਲ ਖਾਂਦਾ ਸੀ, ਖਾਸ ਕਰਕੇ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ। ਪਰ ਮੈਨੂੰ ਲੱਗਿਆ ਕਿ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਵੰਡ ਕੇ ਪੇਸ਼ ਕਰਨਾ ਹੋਰਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਇਸੇ ਚੋਣ ਨਾਲ ਜੂਝ ਰਹੇ ਹਨ।

ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ

ਡਾਟਾ ਸੰਰਚਨਾ ਰੂਪਾਂਤਰਨ

MongoDB ਦੀ ਦਸਤਾਵੇਜ਼ ਸੰਰਚਨਾ ਤੋਂ Postgres ਦੀ ਸੰਬੰਧਤ ਸੰਰਚਨਾ ਵੱਲ ਤਬਦੀਲੀ ਲਈ ਧਿਆਨਪੂਰਵਕ ਯੋਜਨਾ ਦੀ ਲੋੜ ਸੀ। ਮੈਨੂੰ ਇਹ ਕਰਨਾਂ ਪਿਆ:

1. ਸੰਬੰਧਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ: ਪਛਾਣ ਕਰੋ ਕਿ MongoDB ਦਸਤਾਵੇਜ਼ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਸੰਬੰਧਿਤ ਸਨ ਅਤੇ ਉਚਿਤ foreign key ਸੰਬੰਧ ਡਿਜ਼ਾਈਨ ਕਰੋ
2. ਡਾਟਾ ਨੂੰ ਸਧਾਰਣ ਬਣਾਓ: ਜਿੱਥੇ ਉਚਿਤ ਹੋਵੇ, nested ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਵੱਖਰੀਆਂ tables ਵਿੱਚ ਵੰਡੋ
3. JSON ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸੰਭਾਲੋ: ਅਸਲ ਵਿੱਚ unstructured ਡਾਟਾ ਲਈ JSONB columns ਵਰਤੋ, ਜਿਸਨੂੰ ਲਚਕੀਲਾ ਰਹਿਣਾ ਸੀ
4. Index ਡਿਜ਼ਾਈਨ ਕਰੋ: query ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਉਚਿਤ indexes ਬਣਾਓ

ਕਸਟਮ ਹੱਲ

ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਕਈ ਕਸਟਮ ਹੱਲ ਵਿਕਸਿਤ ਕਰਨੇ ਪਏ:

1. ਡਾਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟਸ ਮੈਂ ਇਹ ਕਰਨ ਲਈ ਵਿਸਤ੍ਰਿਤ scripts ਬਣਾਏ:

• MongoDB collections ਤੋਂ ਡਾਟਾ extract ਕਰੋ
• document ਸੰਰਚਨਾਵਾਂ ਨੂੰ relational ਫਾਰਮੈਟ ਵਿੱਚ transform ਕਰੋ
• ਉਚਿਤ ਸੰਬੰਧਾਂ ਨਾਲ ਡਾਟਾ Postgres tables ਵਿੱਚ import ਕਰੋ

2. API ਅਨੁਕੂਲਤਾ ਪਰਤ Zero downtime ਬਣਾਈ ਰੱਖਣ ਲਈ, ਮੈਂ ਇੱਕ compatibility layer ਬਣਾਈ ਜੋ ਇਹ ਕਰ ਸਕਦੀ ਸੀ:

• ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਥਿਤੀ ਦੇ ਅਨੁਸਾਰ requests ਨੂੰ MongoDB ਜਾਂ Postgres ਵੱਲ route ਕਰਨਾ
• ਤਬਦੀਲੀ ਅਵਧੀ ਦੌਰਾਨ ਡਾਟਾ ਸਥਿਰਤਾ ਯਕੀਨੀ ਬਣਾਉਣਾ
• fallback mechanisms ਪ੍ਰਦਾਨ ਕਰਨਾ

3. ਕਸਟਮ ਮਿਡਲਵੇਅਰ MongoDB ਅਤੇ Postgres ਕੁਝ operations ਨੂੰ ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ, ਉਸ ਵਿੱਚ ਫਰਕ ਨੂੰ ਸੰਭਾਲਣ ਲਈ middleware ਵਿਕਸਿਤ ਕੀਤਾ ਗਿਆ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਮੌਜੂਦਾ API endpoints ਬਿਨਾਂ ਕਿਸੇ modification ਦੇ ਕੰਮ ਕਰਦੇ ਰਹੇ।

ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ ਨੂੰ ਪਾਰ ਕਰਨਾ

ਜਟਿਲ ਸੰਬੰਧਾਂ ਨੂੰ ਸੰਭਾਲਣਾ

ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਚੁਣੌਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ MongoDB ਦੇ embedded documents ਨੂੰ Postgres relationships ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਸੀ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਸਿੰਗਲ MongoDB document ਵਿੱਚ ਇਹ ਹੋ ਸਕਦਾ ਸੀ:

• ਬੁਨਿਆਦੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ
• ਸੰਬੰਧਿਤ entities ਨੂੰ ਦਰਸਾਉਂਦੇ nested objects
• embedded documents ਦੇ arrays

ਇਸ ਨੂੰ ਧਿਆਨਪੂਰਵਕ ਇਸ ਵਿੱਚ ਵਿਘਟਿਤ ਕਰਨਾ ਪਿਆ:

• ਮੁੱਖ entities ਲਈ primary tables
• many-to-many ਸੰਬੰਧਾਂ ਲਈ junction tables
• one-to-many associations ਲਈ foreign key relationships

Query ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ

MongoDB ਦੇ query patterns ਸਿੱਧੇ ਤੌਰ ‘ਤੇ SQL ਵਿੱਚ ਤਰਜਮਾ ਨਹੀਂ ਹੁੰਦੇ। ਮੈਨੂੰ ਇਹ ਕਰਨਾਂ ਪਿਆ:

• ਜਟਿਲ aggregation pipelines ਨੂੰ SQL joins ਵਜੋਂ ਮੁੜ ਲਿਖਣਾ
• ਨਵੇਂ query patterns ਲਈ indexes ਅਪਟੀਮਾਈਜ਼ ਕਰਨਾ
• ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ query ਕਾਰਗੁਜ਼ਾਰੀ MongoDB ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਬਰਾਬਰ ਜਾਂ ਉਸ ਤੋਂ ਵੱਧ ਹੋਵੇ

ਡਾਟਾ ਅਖੰਡਤਾ

ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਡਾਟਾ ਅਖੰਡਤਾ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇਹ ਲੋੜੀਂਦਾ ਸੀ:

• ਵਿਸਤ੍ਰਿਤ validation scripts
• rollback procedures
• ਤਬਦੀਲੀ ਅਵਧੀਆਂ ਦੌਰਾਨ real-time ਡਾਟਾ synchronization

ਨਤੀਜੇ ਅਤੇ ਪ੍ਰਭਾਵ

MongoDB ਤੋਂ Postgres ਵੱਲ STMS ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਫਲਤਾਪੂਰਵਕ zero downtime ਨਾਲ ਪੂਰੀ ਕੀਤੀ ਗਈ, ਜਦਕਿ ਲਗਭਗ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਗਿਆ। ਨਤੀਜੇ ਉਮੀਦਾਂ ਤੋਂ ਵੱਧ ਸਨ:

ਕਾਰਗੁਜ਼ਾਰੀ ਸੁਧਾਰ:

• ਜਟਿਲ relational queries ਲਈ query ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ
• ਬਿਹਤਰ ਡਾਟਾ ਸਥਿਰਤਾ ਅਤੇ ਅਖੰਡਤਾ
• ਹੋਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ storage utilization

ਸੰਚਾਲਕੀ ਲਾਭ:

• ਸੁਧਾਰਿਆ ਹੋਇਆ monitoring ਅਤੇ debugging ਸਮਰੱਥਾਵਾਂ
• eBay ਦੇ ਮੌਜੂਦਾ SQL-ਆਧਾਰਿਤ tools ਨਾਲ ਬਿਹਤਰ integration
• ਸੁਧਾਰੀਆਂ backup ਅਤੇ recovery procedures

ਟੀਮ ਪ੍ਰਭਾਵ:

• relational databases ਬਾਰੇ ਟੀਮ ਦੇ ਗਿਆਨ ਵਿੱਚ ਸੁਧਾਰ
• ਭਵਿੱਖ ਦੀਆਂ database migrations ਲਈ patterns ਸਥਾਪਤ ਕੀਤੇ
• ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ tools ਅਤੇ processes ਬਣਾਏ

ਪ੍ਰਾਪਤ ਕੀਤੇ ਤਕਨੀਕੀ ਹੁਨਰ

ਇਸ ਪ੍ਰੋਜੈਕਟ ਨੇ ਮੇਰੀ ਤਕਨੀਕੀ ਮਹਾਰਤ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਤਰੀਕੇ ਨਾਲ ਵਧਾਇਆ:

ਡਾਟਾਬੇਸ ਤਕਨਾਲੋਜੀਆਂ:

• Postgres ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੀ ਡੂੰਘੀ ਸਮਝ
• SQL query ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਅਤੇ performance tuning
• ਡਾਟਾਬੇਸ ਡਿਜ਼ਾਈਨ patterns ਅਤੇ normalization
• primary-standby ਡਾਟਾਬੇਸ configurations

ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਜ਼:

• Sequelize ORM ਅਤੇ query ਬਣਾਉਣਾ
• ਡਾਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਣਨੀਤੀਆਂ
• ਕਾਰਗੁਜ਼ਾਰੀ ਟੈਸਟਿੰਗ ਵਿਧੀਆਂ
• ਡਾਟਾ validation ਅਤੇ ਅਖੰਡਤਾ ਜਾਂਚ

ਆਰਕੀਟੈਕਚਰ patterns:

• zero-downtime ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਣਨੀਤੀਆਂ
• API compatibility layers
• ਡਾਟਾਬੇਸ abstraction patterns
• monitoring ਅਤੇ alerting systems

ਨਿੱਜੀ ਅਤੇ ਪੇਸ਼ਾਵਰ ਵਾਧਾ

ਇਹ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰੋਜੈਕਟ ਮੇਰੇ ਕਰੀਅਰ ਵਿਕਾਸ ਲਈ ਬਦਲਾਅਕਾਰੀ ਸੀ। ਇਸ ਨੇ ਮੈਨੂੰ ਅਣਜਾਣ ਖੇਤਰ ਵਿੱਚ ਧੱਕਿਆ, ਜਿਸ ਲਈ ਇਹ ਲੋੜੀਂਦਾ ਸੀ:

ਲੀਡਰਸ਼ਿਪ ਹੁਨਰ:

• ਪਹਿਲਾਂ ਦੇ ਤਜਰਬੇ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਜਟਿਲ ਤਕਨੀਕੀ ਪ੍ਰੋਜੈਕਟ ਦੀ ਅਗਵਾਈ ਕਰਨੀ
• ਦਬਾਅ ਹੇਠ ਮਹੱਤਵਪੂਰਣ ਆਰਕੀਟੈਕਚਰਲ ਫ਼ੈਸਲੇ ਲੈਣੇ
• ਕਈ teams ਅਤੇ stakeholders ਨਾਲ ਸਮਨ्वਯ ਕਰਨਾ

ਸਮੱਸਿਆ-ਹਲ ਕਰਨ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ:

• ਜਟਿਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸੰਭਾਲਣਯੋਗ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣਾ
• ਬੇਮਿਸਾਲ ਚੁਣੌਤੀਆਂ ਲਈ ਰਚਨਾਤਮਕ ਹੱਲ ਵਿਕਸਿਤ ਕਰਨੇ
• ਕਈ ਮੁਕਾਬਲੇ ਵਾਲੀਆਂ ਲੋੜਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਣਾ

ਸੰਚਾਰ ਅਤੇ ਟੀਮਵਰਕ:

• ਗੈਰ-ਤਕਨੀਕੀ stakeholders ਨੂੰ ਤਕਨੀਕੀ ਸੰਕਲਪ ਸਮਝਾਉਣੇ
• ਭਵਿੱਖੀ ਹਵਾਲੇ ਲਈ processes ਅਤੇ decisions ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ
• ਨਵੀਆਂ technologies ਅਤੇ patterns ਬਾਰੇ team members ਨੂੰ ਮਾਰਗਦਰਸ਼ਨ ਦੇਣਾ

ਸਿੱਖੇ ਗਏ ਸਬਕ

ਤਕਨੀਕੀ ਸਬਕ

1. ਡਾਟਾਬੇਸ ਚੋਣ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ: NoSQL ਅਤੇ SQL ਵਿਚਕਾਰ ਚੋਣ ਵਿਸ਼ੇਸ਼ use cases ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਲੋੜਾਂ ‘ਤੇ ਆਧਾਰਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ
2. ਕਾਰਗੁਜ਼ਾਰੀ ਟੈਸਟਿੰਗ ਨਿਰਣਾਇਕ ਹੈ: ਸਿਧਾਂਤਕ ਲਾਭ ਹਮੇਸ਼ਾਂ ਅਸਲ ਦੁਨੀਆ ਦੇ ਕਾਰਗੁਜ਼ਾਰੀ ਲਾਭਾਂ ਵਿੱਚ ਤਬਦੀਲ ਨਹੀਂ ਹੁੰਦੇ
3. ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਬਣਾਉਣਾ: ਜਟਿਲ migrations ਲਈ ਵਿਸਤ੍ਰਿਤ ਯੋਜਨਾ ਅਤੇ ਟੈਸਟਿੰਗ ਜ਼ਰੂਰੀ ਹਨ
4. ਟੂਲਿੰਗ ਵਿੱਚ ਨਿਵੇਸ਼: ਸ਼ੁਰੂ ਵਿੱਚ ਉਚਿਤ tooling ਬਣਾਉਣ ਨਾਲ ਮਹੱਤਵਪੂਰਣ ਸਮਾਂ ਬਚਦਾ ਹੈ ਅਤੇ ਗਲਤੀਆਂ ਘਟਦੀਆਂ ਹਨ

ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਬੰਧਨ ਸਬਕ

1. Stakeholder ਸੰਚਾਰ: ਨਿਯਮਤ ਅਪਡੇਟ ਅਤੇ ਸਪਸ਼ਟ ਸੰਚਾਰ ਗਲਤਫਹਿਮੀਆਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ
2. ਜੋਖਮ ਪ੍ਰਬੰਧਨ: fallback ਯੋਜਨਾਵਾਂ ਅਤੇ rollback procedures ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ
3. ਟਾਈਮਲਾਈਨ ਪ੍ਰਬੰਧਨ: ਅਣਉਮੀਦ ਚੁਣੌਤੀਆਂ ਅਤੇ ਸਿੱਖਣ ਦੀਆਂ ਲਕੀਰਾਂ ਲਈ buffer ਸਮਾਂ ਰੱਖੋ
4. ਦਸਤਾਵੇਜ਼ੀਕਰਨ: ਵਿਸਤ੍ਰਿਤ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਗਿਆਨ ਸਾਂਝਾ ਕਰਨ ਅਤੇ ਭਵਿੱਖ ਦੀ maintenance ਨੂੰ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ

ਨਤੀਜਾ

STMS MongoDB ਤੋਂ Postgres ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੇਰੇ ਕਰੀਅਰ ਵਿੱਚ ਮੇਰੇ ਦੁਆਰਾ ਹੱਲ ਕੀਤੀ ਗਈ ਸਭ ਤੋਂ ਚੁਣੌਤੀਪੂਰਨ ਅਤੇ ਫ਼ਾਇਦੇਮੰਦ ਤਕਨੀਕੀ ਸਮੱਸਿਆ ਵਜੋਂ ਖੜ੍ਹੀ ਹੈ। ਇਸ ਲਈ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਮਹਾਰਤ ਹੀ ਨਹੀਂ, ਸਗੋਂ leadership, ਯੋਜਨਾ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀ ਵੀ ਲੋੜ ਸੀ। ਪ੍ਰੋਜੈਕਟ ਦੀ ਸਫਲਤਾ ਨੇ ਦਰਸਾਇਆ ਕਿ ਉਚਿਤ ਯੋਜਨਾ, ਵਿਸਤ੍ਰਿਤ ਟੈਸਟਿੰਗ, ਅਤੇ ਉੱਤਮਤਾ ਪ੍ਰਤੀ ਵਚਨਬੱਧਤਾ ਨਾਲ, ਸਭ ਤੋਂ ਜਟਿਲ ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ ਨੂੰ ਵੀ ਪਾਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਅਨੁਭਵ ਨੇ software engineering ਪ੍ਰਤੀ ਮੇਰੇ ਰਵੱਈਏ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਜਿਸ ਨੇ ਇਹ ਮਹੱਤਤਾ ਉਭਾਰੀ:

• ਤਕਨੀਕੀ ਫ਼ੈਸਲੇ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੇ ਸੰਦਰਭ ਅਤੇ ਲੋੜਾਂ ਨੂੰ ਸਮਝਣਾ
• ਉਚਿਤ tooling ਅਤੇ testing ਵਿੱਚ ਸਮਾਂ ਨਿਵੇਸ਼ ਕਰਨਾ
• ਜਟਿਲ ਪ੍ਰੋਜੈਕਟਾਂ ਦੌਰਾਨ ਸਪਸ਼ਟ ਸੰਚਾਰ ਬਣਾਈ ਰੱਖਣਾ
• ਲੋੜ ਪੈਣ ‘ਤੇ ਨਵੀਆਂ technologies ਅਤੇ approaches ਸਿੱਖਣ ਲਈ ਤਿਆਰ ਰਹਿਣਾ

ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਸਫਲਤਾ ਨੇ ਨਾ ਸਿਰਫ਼ STMS ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ, ਸਗੋਂ ਅਜਿਹੇ patterns ਅਤੇ processes ਵੀ ਸਥਾਪਤ ਕੀਤੇ ਜੋ ਅੱਜ ਵੀ eBay ਦੇ infrastructure projects ਨੂੰ ਲਾਭ ਪਹੁੰਚਾਉਂਦੇ ਹਨ। ਇਸ ਨੇ ਮੇਰੇ ਇਸ ਵਿਸ਼ਵਾਸ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ ਕਿ ਅਣਜਾਣ ਚੁਣੌਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚ ਸਫਲ ਹੋਣਾ ਨਿੱਜੀ ਅਤੇ ਪੇਸ਼ਾਵਰ ਵਿਕਾਸ ਦੋਵਾਂ ਲਈ ਕੁੰਜੀ ਹੈ।

ਪਿੱਛੇ ਮੁੜ ਕੇ ਦੇਖਦਿਆਂ, ਇਹ ਪ੍ਰੋਜੈਕਟ ਮੇਰੇ ਕਰੀਅਰ ਵਿੱਚ ਇੱਕ ਮੋੜ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜਿਸ ਨੇ ਮੈਨੂੰ ਇੱਕ ਅਜਿਹੇ developer ਤੋਂ, ਜੋ solutions ਲਾਗੂ ਕਰਦਾ ਹੈ, ਇੱਕ ਅਜਿਹੇ engineer ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਜਟਿਲ ਤਕਨੀਕੀ initiatives ਦੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਅਗਵਾਈ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਅਨੁਭਵ ਤੋਂ ਪ੍ਰਾਪਤ ਵਿਸ਼ਵਾਸ ਅਤੇ ਹੁਨਰ software engineering ਵਿੱਚ ਨਵੀਆਂ ਚੁਣੌਤੀਆਂ ਅਤੇ ਮੌਕਿਆਂ ਪ੍ਰਤੀ ਮੇਰੇ ਰਵੱਈਏ ਨੂੰ ਅੱਜ ਵੀ ਦਿਸ਼ਾ ਦਿੰਦੇ ਹਨ।