21ਵੀਂ ਸਦੀ ਵਿੱਚ ਇੱਕ SQL ਡੇਟਾਬੇਸ ਨੂੰ ਕਿਵੇਂ ਬਚਾਇਆ ਜਾਵੇ: ਕਲਾਉਡਸ, ਕੁਬਰਨੇਟਸ ਅਤੇ ਪੋਸਟਗ੍ਰੇਸਕਿਯੂਐਲ ਮਲਟੀਮਾਸਟਰ

ਹੈਲੋ, Khabrovsk ਨਿਵਾਸੀ. ਕੋਰਸ ਦੇ ਪਹਿਲੇ ਗਰੁੱਪ ਦੀਆਂ ਕਲਾਸਾਂ ਅੱਜ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਰਹੀਆਂ ਹਨ "PostgreSQL". ਇਸ ਸਬੰਧ ਵਿਚ, ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਇਸ ਕੋਰਸ 'ਤੇ ਓਪਨ ਵੈਬਿਨਾਰ ਕਿਵੇਂ ਹੋਇਆ।

В ਅਗਲਾ ਖੁੱਲਾ ਪਾਠ ਅਸੀਂ ਕਲਾਉਡਸ ਅਤੇ ਕੁਬਰਨੇਟਸ ਦੇ ਦੌਰ ਵਿੱਚ SQL ਡੇਟਾਬੇਸ ਨੂੰ ਦਰਪੇਸ਼ ਚੁਣੌਤੀਆਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ। ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਕਿਵੇਂ SQL ਡੇਟਾਬੇਸ ਇਹਨਾਂ ਚੁਣੌਤੀਆਂ ਦੇ ਪ੍ਰਭਾਵ ਅਧੀਨ ਅਨੁਕੂਲ ਅਤੇ ਪਰਿਵਰਤਿਤ ਹੁੰਦੇ ਹਨ।

ਵੈਬੀਨਾਰ ਕਰਵਾਇਆ ਗਿਆ ਵੈਲੇਰੀ ਬੇਜ਼ਰੂਕੋਵ, EPAM ਸਿਸਟਮਾਂ 'ਤੇ Google ਕਲਾਊਡ ਪ੍ਰੈਕਟਿਸ ਡਿਲੀਵਰੀ ਮੈਨੇਜਰ।

ਜਦੋਂ ਰੁੱਖ ਛੋਟੇ ਹੁੰਦੇ ਸਨ...

ਪਹਿਲਾਂ, ਆਓ ਯਾਦ ਕਰੀਏ ਕਿ ਪਿਛਲੀ ਸਦੀ ਦੇ ਅੰਤ ਵਿੱਚ ਡੀਬੀਐਮਐਸ ਦੀ ਚੋਣ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਈ ਸੀ. ਹਾਲਾਂਕਿ, ਇਹ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਦਿਨਾਂ ਵਿੱਚ ਇੱਕ ਡੀਬੀਐਮਐਸ ਦੀ ਚੋਣ ਸ਼ੁਰੂ ਹੋਈ ਅਤੇ ਖਤਮ ਹੋ ਗਈ ਓਰੇਕਲ.

90 ਦੇ ਦਹਾਕੇ ਦੇ ਅਖੀਰ ਅਤੇ 2 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ, ਜਦੋਂ ਉਦਯੋਗਿਕ ਸਕੇਲੇਬਲ ਡੇਟਾਬੇਸ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ ਤਾਂ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਸੀ। ਹਾਂ, IBM DBXNUMX, Sybase ਅਤੇ ਕੁਝ ਹੋਰ ਡੇਟਾਬੇਸ ਸਨ ਜੋ ਆਏ ਅਤੇ ਗਏ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਓਰੇਕਲ ਦੇ ਪਿਛੋਕੜ ਦੇ ਵਿਰੁੱਧ ਇੰਨੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਸਨ। ਇਸ ਅਨੁਸਾਰ, ਉਸ ਸਮੇਂ ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਹੁਨਰ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਇਕੋ ਵਿਕਲਪ ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਸੀ ਜੋ ਮੌਜੂਦ ਸੀ.

ਓਰੇਕਲ ਡੀਬੀਏ ਨੂੰ ਇਹ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ:

• ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਕਿੱਟ ਤੋਂ ਓਰੇਕਲ ਸਰਵਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ;
• ਓਰੇਕਲ ਸਰਵਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ:

• init.ora;
• listener.ora;

- ਬਣਾਓ:

• ਟੇਬਲਸਪੇਸ;
• ਸਕੀਮਾਂ;
• ਉਪਭੋਗਤਾ;

- ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਕਰੋ;
- ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ;
- ਸਬ-ਅਨੁਕੂਲ ਬੇਨਤੀਆਂ ਨਾਲ ਨਜਿੱਠਣਾ।

ਉਸੇ ਸਮੇਂ, ਓਰੇਕਲ ਡੀਬੀਏ ਤੋਂ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਲੋੜ ਨਹੀਂ ਸੀ:

• ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਅਨੁਕੂਲ DBMS ਜਾਂ ਹੋਰ ਤਕਨਾਲੋਜੀ ਦੀ ਚੋਣ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ;
• ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਹਰੀਜੱਟਲ ਸਕੇਲੇਬਿਲਟੀ ਪ੍ਰਦਾਨ ਕਰੋ (ਇਹ ਹਮੇਸ਼ਾ DBA ਮੁੱਦਾ ਨਹੀਂ ਸੀ);
• ਵਿਸ਼ਾ ਖੇਤਰ, ਬੁਨਿਆਦੀ ਢਾਂਚਾ, ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ, ਓਐਸ ਦਾ ਚੰਗਾ ਗਿਆਨ;
• ਡਾਟਾ ਲੋਡ ਅਤੇ ਅਨਲੋਡ ਕਰੋ, ਵੱਖ-ਵੱਖ DBMSs ਵਿਚਕਾਰ ਡਾਟਾ ਮਾਈਗਰੇਟ ਕਰੋ।

ਆਮ ਤੌਰ 'ਤੇ, ਜੇ ਅਸੀਂ ਉਨ੍ਹਾਂ ਦਿਨਾਂ ਵਿਚ ਚੋਣ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ 80 ਦੇ ਦਹਾਕੇ ਦੇ ਅਖੀਰ ਵਿਚ ਸੋਵੀਅਤ ਸਟੋਰ ਵਿਚ ਚੋਣ ਵਰਗਾ ਹੈ:

ਸਾਡਾ ਸਮਾਂ

ਉਦੋਂ ਤੋਂ, ਬੇਸ਼ੱਕ, ਰੁੱਖ ਵਧੇ ਹਨ, ਸੰਸਾਰ ਬਦਲ ਗਿਆ ਹੈ, ਅਤੇ ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਗਿਆ ਹੈ:

ਡੀਬੀਐਮਐਸ ਮਾਰਕੀਟ ਵੀ ਬਦਲ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਗਾਰਟਨਰ ਦੀ ਤਾਜ਼ਾ ਰਿਪੋਰਟ ਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ:

ਅਤੇ ਇੱਥੇ ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਬੱਦਲ, ਜਿਨ੍ਹਾਂ ਦੀ ਪ੍ਰਸਿੱਧੀ ਵਧ ਰਹੀ ਹੈ, ਨੇ ਆਪਣੇ ਸਥਾਨ 'ਤੇ ਕਬਜ਼ਾ ਕਰ ਲਿਆ ਹੈ. ਜੇ ਅਸੀਂ ਉਹੀ ਗਾਰਟਨਰ ਰਿਪੋਰਟ ਪੜ੍ਹਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਸਿੱਟੇ ਦੇਖਾਂਗੇ:

1. ਬਹੁਤ ਸਾਰੇ ਗਾਹਕ ਕਲਾਉਡ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਮੂਵ ਕਰਨ ਦੇ ਰਾਹ 'ਤੇ ਹਨ।
2. ਨਵੀਆਂ ਤਕਨੀਕਾਂ ਪਹਿਲਾਂ ਕਲਾਉਡ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਇੱਕ ਤੱਥ ਨਹੀਂ ਹੈ ਕਿ ਉਹ ਕਦੇ ਵੀ ਗੈਰ-ਕਲਾਊਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਚਲੇ ਜਾਣਗੇ।
3. ਪੇ-ਐਜ਼-ਯੂ-ਗੋ ਕੀਮਤ ਮਾਡਲ ਆਮ ਹੋ ਗਿਆ ਹੈ। ਹਰ ਕੋਈ ਸਿਰਫ਼ ਉਸ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਜੋ ਉਹ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇਹ ਇੱਕ ਰੁਝਾਨ ਵੀ ਨਹੀਂ ਹੈ, ਪਰ ਸਿਰਫ਼ ਤੱਥ ਦਾ ਬਿਆਨ ਹੈ।

ਹੁਣ ਕੀ?

ਅੱਜ ਅਸੀਂ ਸਾਰੇ ਬੱਦਲ ਵਿੱਚ ਹਾਂ। ਅਤੇ ਸਾਡੇ ਲਈ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਸਵਾਲ ਚੋਣ ਦੇ ਸਵਾਲ ਹਨ। ਅਤੇ ਇਹ ਬਹੁਤ ਵੱਡਾ ਹੈ, ਭਾਵੇਂ ਅਸੀਂ ਸਿਰਫ ਆਨ-ਪ੍ਰੀਮਿਸ ਫਾਰਮੈਟ ਵਿੱਚ DBMS ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਚੋਣ ਬਾਰੇ ਗੱਲ ਕਰੀਏ। ਅਸੀਂ ਸੇਵਾਵਾਂ ਅਤੇ SaaS ਦਾ ਪ੍ਰਬੰਧਨ ਵੀ ਕੀਤਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਚੋਣ ਸਿਰਫ ਹਰ ਸਾਲ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ.

ਚੋਣ ਦੇ ਸਵਾਲਾਂ ਦੇ ਨਾਲ, ਇਹ ਵੀ ਹਨ ਸੀਮਤ ਕਾਰਕ:

• ਕੀਮਤ. ਬਹੁਤ ਸਾਰੀਆਂ ਤਕਨੀਕਾਂ ਅਜੇ ਵੀ ਪੈਸੇ ਦੀ ਲਾਗਤ ਕਰਦੀਆਂ ਹਨ;
• ਹੁਨਰ. ਜੇਕਰ ਅਸੀਂ ਮੁਫਤ ਸੌਫਟਵੇਅਰ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਹੁਨਰਾਂ ਦਾ ਸਵਾਲ ਉੱਠਦਾ ਹੈ, ਕਿਉਂਕਿ ਮੁਫਤ ਸੌਫਟਵੇਅਰ ਨੂੰ ਉਹਨਾਂ ਲੋਕਾਂ ਤੋਂ ਲੋੜੀਂਦੀ ਯੋਗਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ ਅਤੇ ਸੰਚਾਲਿਤ ਕਰਦੇ ਹਨ;
• ਕਾਰਜਸ਼ੀਲ. ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਜੋ ਕਲਾਉਡ ਵਿੱਚ ਉਪਲਬਧ ਹਨ ਅਤੇ ਬਣੀਆਂ ਹਨ, ਕਹੋ, ਉਸੇ ਪੋਸਟਗ੍ਰੇਸ 'ਤੇ ਵੀ, ਪੋਸਟਗ੍ਰੇਸ ਆਨ-ਪ੍ਰੀਮਿਸਸ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਹੀਂ ਹਨ। ਇਹ ਇੱਕ ਜ਼ਰੂਰੀ ਕਾਰਕ ਹੈ ਜਿਸਨੂੰ ਜਾਣਨ ਅਤੇ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਕਾਰਕ ਇੱਕ ਸਿੰਗਲ DBMS ਦੀਆਂ ਕੁਝ ਲੁਕੀਆਂ ਹੋਈਆਂ ਸਮਰੱਥਾਵਾਂ ਦੇ ਗਿਆਨ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦਾ ਹੈ।

ਹੁਣ DA/DE ਤੋਂ ਕੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

• ਵਿਸ਼ਾ ਖੇਤਰ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਦੀ ਚੰਗੀ ਸਮਝ;
• ਹੱਥ ਵਿੱਚ ਕੰਮ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਉਚਿਤ DBMS ਤਕਨਾਲੋਜੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚੁਣਨ ਦੀ ਯੋਗਤਾ;
• ਮੌਜੂਦਾ ਸੀਮਾਵਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਚੁਣੀ ਗਈ ਤਕਨਾਲੋਜੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਅਨੁਕੂਲ ਢੰਗ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਯੋਗਤਾ;
• ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਰਨ ਦੀ ਯੋਗਤਾ;
• ਚੁਣੇ ਗਏ ਹੱਲਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਚਲਾਉਣ ਦੀ ਸਮਰੱਥਾ।

ਉਦਾਹਰਨ ਹੇਠ GCP 'ਤੇ ਆਧਾਰਿਤ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਡੇਟਾ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਜਾਂ ਕਿਸੇ ਹੋਰ ਤਕਨਾਲੋਜੀ ਦੀ ਚੋਣ ਇਸਦੇ ਢਾਂਚੇ ਦੇ ਅਧਾਰ ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ:

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ PostgreSQL ਸਕੀਮਾ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸ਼ਬਦਾਵਲੀ ਦੇ ਹੇਠਾਂ ਲੁਕਿਆ ਹੋਇਆ ਹੈ SQL ਕ੍ਲਾਉਡ. ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਕਲਾਉਡ SQL 'ਤੇ ਪਹੁੰਚਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਦੁਬਾਰਾ ਚੋਣ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਚੋਣ ਹਮੇਸ਼ਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦੀ, ਇਸਲਈ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਅਕਸਰ ਅਨੁਭਵ ਦੁਆਰਾ ਸੇਧਿਤ ਹੁੰਦੇ ਹਨ.

ਕੁੱਲ:

1. ਜਿੰਨਾ ਅੱਗੇ ਤੁਸੀਂ ਜਾਂਦੇ ਹੋ, ਚੋਣ ਦਾ ਸਵਾਲ ਓਨਾ ਹੀ ਜ਼ਿਆਦਾ ਦਬਾਇਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਭਾਵੇਂ ਤੁਸੀਂ ਸਿਰਫ GCP, ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਅਤੇ SaaS ਨੂੰ ਦੇਖਦੇ ਹੋ, ਫਿਰ RDBMS ਦਾ ਕੁਝ ਜ਼ਿਕਰ ਸਿਰਫ 4 ਵੇਂ ਪੜਾਅ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਅਤੇ ਉੱਥੇ ਸਪੈਨਰ ਨੇੜੇ ਹੈ)। ਨਾਲ ਹੀ, PostgreSQL ਦੀ ਚੋਣ 5ਵੇਂ ਪੜਾਅ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਸਦੇ ਅੱਗੇ MySQL ਅਤੇ SQL ਸਰਵਰ ਵੀ ਹਨ, ਯਾਨੀ ਇੱਥੇ ਸਭ ਕੁਝ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਚੁਣਨਾ ਪਵੇਗਾ.
2. ਸਾਨੂੰ ਪਰਤਾਵੇ ਦੇ ਪਿਛੋਕੜ ਦੇ ਵਿਰੁੱਧ ਪਾਬੰਦੀਆਂ ਬਾਰੇ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ ਹੈ. ਅਸਲ ਵਿੱਚ ਹਰ ਕੋਈ ਇੱਕ ਸਪੈਨਰ ਚਾਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਮਹਿੰਗਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਇੱਕ ਆਮ ਬੇਨਤੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: "ਕਿਰਪਾ ਕਰਕੇ ਸਾਨੂੰ ਇੱਕ ਸਪੈਨਰ ਬਣਾਓ ਪਰ ਕਲਾਉਡ SQL ਦੀ ਕੀਮਤ ਲਈ, ਤੁਸੀਂ ਪੇਸ਼ੇਵਰ ਹੋ!"

ਸਾਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਅੰਤਮ ਸੱਚ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕੀਤੇ ਬਿਨਾਂ, ਆਓ ਹੇਠਾਂ ਕਹੀਏ:

ਸਾਨੂੰ ਸਿੱਖਣ ਲਈ ਆਪਣੀ ਪਹੁੰਚ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ:

• DBAs ਨੂੰ ਪਹਿਲਾਂ ਸਿਖਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਸਿਖਾਉਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ;
• ਇੱਕ ਉਤਪਾਦ ਦਾ ਗਿਆਨ ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ;
• ਪਰ ਦਰਜਨਾਂ ਨੂੰ ਇੱਕ ਦੇ ਪੱਧਰ 'ਤੇ ਜਾਣਨਾ ਅਸੰਭਵ ਹੈ।

ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ਼ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਉਤਪਾਦ ਕਿੰਨਾ ਹੈ, ਪਰ:

• ਇਸਦੀ ਅਰਜ਼ੀ ਦੇ ਕੇਸ ਦੀ ਵਰਤੋਂ ਕਰੋ;
• ਵੱਖ-ਵੱਖ ਤੈਨਾਤੀ ਢੰਗ;
• ਹਰ ਇੱਕ ਢੰਗ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ;
• ਇੱਕ ਸੂਚਿਤ ਅਤੇ ਅਨੁਕੂਲ ਚੋਣ ਕਰਨ ਲਈ ਸਮਾਨ ਅਤੇ ਵਿਕਲਪਕ ਉਤਪਾਦ ਅਤੇ ਹਮੇਸ਼ਾਂ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਉਤਪਾਦ ਦੇ ਹੱਕ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ।

ਤੁਹਾਨੂੰ ਡੇਟਾ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਅਤੇ ETL ਨਾਲ ਏਕੀਕਰਣ ਦੇ ਬੁਨਿਆਦੀ ਸਿਧਾਂਤਾਂ ਨੂੰ ਸਮਝਣ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਵੀ ਲੋੜ ਹੈ।

ਅਸਲੀ ਕੇਸ

ਹਾਲ ਹੀ ਵਿੱਚ, ਇੱਕ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਬੈਕਐਂਡ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ. ਜਦੋਂ ਤੱਕ ਇਸ 'ਤੇ ਕੰਮ ਸ਼ੁਰੂ ਹੋਇਆ, ਬੈਕਐਂਡ ਪਹਿਲਾਂ ਹੀ ਵਿਕਸਤ ਹੋ ਚੁੱਕਾ ਸੀ ਅਤੇ ਲਾਗੂ ਕਰਨ ਲਈ ਤਿਆਰ ਸੀ, ਅਤੇ ਵਿਕਾਸ ਟੀਮ ਨੇ ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਲਗਭਗ ਦੋ ਸਾਲ ਬਿਤਾਏ ਸਨ। ਹੇਠ ਦਿੱਤੇ ਕਾਰਜ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਸਨ:

• CI/CD ਬਣਾਓ;
• ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਮੀਖਿਆ ਕਰੋ;
• ਇਸ ਨੂੰ ਸਾਰੇ ਕੰਮ ਵਿੱਚ ਪਾਓ.

ਐਪਲੀਕੇਸ਼ਨ ਖੁਦ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਸੀ, ਅਤੇ Python/Django ਕੋਡ ਨੂੰ ਸਕ੍ਰੈਚ ਤੋਂ ਅਤੇ ਸਿੱਧਾ GCP ਵਿੱਚ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਜਿਵੇਂ ਕਿ ਨਿਸ਼ਾਨਾ ਦਰਸ਼ਕਾਂ ਲਈ, ਇਹ ਮੰਨਿਆ ਗਿਆ ਸੀ ਕਿ ਦੋ ਖੇਤਰ ਹੋਣਗੇ - ਯੂਐਸ ਅਤੇ ਈਯੂ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਗਲੋਬਲ ਲੋਡ ਬੈਲੇਂਸਰ ਦੁਆਰਾ ਵੰਡਿਆ ਗਿਆ ਸੀ. ਸਾਰੇ ਵਰਕਲੋਡ ਅਤੇ ਕੰਪਿਊਟ ਵਰਕਲੋਡ ਗੂਗਲ ਕੁਬਰਨੇਟਸ ਇੰਜਣ 'ਤੇ ਚੱਲਦੇ ਹਨ।

ਡੇਟਾ ਲਈ, ਇੱਥੇ 3 ਢਾਂਚੇ ਸਨ:

• ਕਲਾਉਡ ਸਟੋਰੇਜ;
• ਡਾਟਾਸਟੋਰ;
• Cloud SQL (PostgreSQL)।

ਕੋਈ ਹੈਰਾਨ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕਲਾਉਡ SQL ਕਿਉਂ ਚੁਣਿਆ ਗਿਆ ਸੀ? ਸੱਚ ਦੱਸਣ ਲਈ, ਅਜਿਹੇ ਸਵਾਲ ਨੇ ਹਾਲ ਹੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ ਕੁਝ ਅਜੀਬ ਵਿਰਾਮ ਦਾ ਕਾਰਨ ਬਣਾਇਆ ਹੈ - ਇੱਕ ਭਾਵਨਾ ਹੈ ਕਿ ਲੋਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਬਾਰੇ ਸ਼ਰਮੀਲੇ ਹੋ ਗਏ ਹਨ, ਪਰ ਫਿਰ ਵੀ ਉਹ ਉਹਨਾਂ ਦੀ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੋਂ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਨ;-).

ਸਾਡੇ ਕੇਸ ਲਈ, ਕਲਾਉਡ SQL ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਰਨਾਂ ਕਰਕੇ ਚੁਣਿਆ ਗਿਆ ਸੀ:

1. ਜਿਵੇਂ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ Django ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਇਸ ਵਿੱਚ ਇੱਕ SQL ਡੇਟਾਬੇਸ ਤੋਂ Python ਆਬਜੈਕਟ (Django ORM) ਤੱਕ ਨਿਰੰਤਰ ਡੇਟਾ ਨੂੰ ਮੈਪ ਕਰਨ ਲਈ ਇੱਕ ਮਾਡਲ ਹੈ।
2. ਫਰੇਮਵਰਕ ਨੇ ਖੁਦ DBMSs ਦੀ ਇੱਕ ਸੀਮਤ ਸੂਚੀ ਦਾ ਸਮਰਥਨ ਕੀਤਾ:

• PostgreSQL;
• ਮਾਰੀਆਡੀਬੀ;
• MySQL;
• ਓਰੇਕਲ;
• SQLite.

ਇਸ ਅਨੁਸਾਰ, PostgreSQL ਨੂੰ ਇਸ ਸੂਚੀ ਵਿੱਚੋਂ ਚੁਣਿਆ ਗਿਆ ਸੀ ਨਾ ਕਿ ਅਨੁਭਵੀ ਤੌਰ 'ਤੇ (ਠੀਕ ਹੈ, ਇਹ ਚੁਣਨਾ ਓਰੇਕਲ ਨਹੀਂ ਹੈ, ਅਸਲ ਵਿੱਚ)।

ਕੀ ਗੁੰਮ ਸੀ:

• ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਿਰਫ 2 ਖੇਤਰਾਂ ਵਿੱਚ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਇੱਕ ਤੀਸਰਾ ਯੋਜਨਾਵਾਂ (ਏਸ਼ੀਆ) ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ;
• ਡੇਟਾਬੇਸ ਉੱਤਰੀ ਅਮਰੀਕੀ ਖੇਤਰ (ਆਯੋਵਾ) ਵਿੱਚ ਸਥਿਤ ਸੀ;
• ਗਾਹਕ ਦੇ ਹਿੱਸੇ 'ਤੇ ਸੰਭਵ ਬਾਰੇ ਚਿੰਤਾਵਾਂ ਸਨ ਪਹੁੰਚ ਵਿੱਚ ਦੇਰੀ ਯੂਰਪ ਅਤੇ ਏਸ਼ੀਆ ਤੋਂ ਅਤੇ ਰੁਕਾਵਟਾਂ ਸੇਵਾ ਵਿੱਚ DBMS ਡਾਊਨਟਾਈਮ ਦੇ ਮਾਮਲੇ ਵਿੱਚ.

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਜੰਜੋ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਈ ਡੇਟਾਬੇਸ ਦੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਵਿੱਚ ਵੰਡ ਸਕਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਇੰਨੀ ਜ਼ਿਆਦਾ ਲਿਖਤ ਨਹੀਂ ਸੀ (90% ਤੋਂ ਵੱਧ ਪੜ੍ਹ ਰਿਹਾ ਹੈ)। ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ, ਅਤੇ ਆਮ ਤੌਰ' ਤੇ, ਜੇ ਇਹ ਕਰਨਾ ਸੰਭਵ ਸੀ ਯੂਰਪ ਅਤੇ ਏਸ਼ੀਆ ਵਿੱਚ ਮੁੱਖ ਅਧਾਰ ਦੀ ਰੀਡ-ਰਿਪਲੀਕਾ, ਇਹ ਇੱਕ ਸਮਝੌਤਾ ਹੱਲ ਹੋਵੇਗਾ। ਨਾਲ ਨਾਲ, ਇਸ ਬਾਰੇ ਇੰਨਾ ਗੁੰਝਲਦਾਰ ਕੀ ਹੈ?

ਮੁਸ਼ਕਲ ਇਹ ਸੀ ਕਿ ਗਾਹਕ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਅਤੇ ਕਲਾਉਡ SQL ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਛੱਡਣਾ ਨਹੀਂ ਚਾਹੁੰਦਾ ਸੀ। ਅਤੇ ਕਲਾਉਡ SQL ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵਰਤਮਾਨ ਵਿੱਚ ਸੀਮਤ ਹਨ। ਕਲਾਉਡ SQL ਉੱਚ ਉਪਲਬਧਤਾ (HA) ਅਤੇ ਰੀਡ ਰਿਪਲੀਕਾ (RR) ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਪਰ ਉਹੀ RR ਸਿਰਫ਼ ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਸਮਰਥਿਤ ਹੈ। ਅਮਰੀਕੀ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਡੇਟਾਬੇਸ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ Cloud SQL ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਯੂਰਪੀਅਨ ਖੇਤਰ ਵਿੱਚ ਰੀਡ ਰੀਪਲੀਕਾ ਨਹੀਂ ਬਣਾ ਸਕਦੇ ਹੋ, ਹਾਲਾਂਕਿ ਪੋਸਟਗ੍ਰੇਸ ਖੁਦ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ ਹੈ। ਗੂਗਲ ਦੇ ਕਰਮਚਾਰੀਆਂ ਨਾਲ ਪੱਤਰ ਵਿਹਾਰ ਕਿਧਰੇ ਵੀ ਨਹੀਂ ਪਹੁੰਚਿਆ ਅਤੇ "ਅਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਜਾਣਦੇ ਹਾਂ ਅਤੇ ਇਸ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ, ਕਿਸੇ ਦਿਨ ਇਹ ਮਸਲਾ ਹੱਲ ਹੋ ਜਾਵੇਗਾ" ਦੀ ਸ਼ੈਲੀ ਵਿੱਚ ਵਾਅਦਿਆਂ ਨਾਲ ਖਤਮ ਹੋਇਆ।

ਜੇਕਰ ਅਸੀਂ ਕਲਾਊਡ SQL ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

1. ਉੱਚ ਉਪਲਬਧਤਾ (HA):

• ਇੱਕ ਖੇਤਰ ਦੇ ਅੰਦਰ;
• ਡਿਸਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੁਆਰਾ;
• PostgreSQL ਇੰਜਣਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ;
• ਆਟੋਮੈਟਿਕ ਅਤੇ ਮੈਨੂਅਲ ਕੰਟਰੋਲ ਸੰਭਵ - ਫੇਲਓਵਰ/ਫੇਲਬੈਕ;
• ਸਵਿਚ ਕਰਨ ਵੇਲੇ, DBMS ਕਈ ਮਿੰਟਾਂ ਲਈ ਅਣਉਪਲਬਧ ਹੁੰਦਾ ਹੈ।

2. ਰੀਪਲੀਕਾ (ਆਰਆਰ) ਪੜ੍ਹੋ:

• ਇੱਕ ਖੇਤਰ ਦੇ ਅੰਦਰ;
• ਗਰਮ ਸਟੈਂਡਬਾਏ;
• PostgreSQL ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਿਵੇਂ ਕਿ ਰਿਵਾਜ ਹੈ, ਇੱਕ ਤਕਨਾਲੋਜੀ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਕੁਝ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਪਾਬੰਦੀਆਂ:

• ਗਾਹਕ GKE ਨੂੰ ਛੱਡ ਕੇ, ਇਕਾਈਆਂ ਬਣਾਉਣਾ ਅਤੇ IaaS ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ;
• ਗਾਹਕ ਸਵੈ-ਸੇਵਾ PostgreSQL/MySQL ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਨਹੀਂ ਚਾਹੇਗਾ;
• ਖੈਰ, ਆਮ ਤੌਰ 'ਤੇ, ਗੂਗਲ ਸਪੈਨਰ ਕਾਫ਼ੀ ਢੁਕਵਾਂ ਹੋਵੇਗਾ ਜੇਕਰ ਇਹ ਇਸਦੀ ਕੀਮਤ ਲਈ ਨਾ ਹੁੰਦਾ, ਹਾਲਾਂਕਿ, Django ORM ਇਸਦੇ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪਰ ਇਹ ਇੱਕ ਚੰਗੀ ਗੱਲ ਹੈ.

ਸਥਿਤੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਗਾਹਕ ਨੂੰ ਇੱਕ ਫਾਲੋ-ਅੱਪ ਸਵਾਲ ਪ੍ਰਾਪਤ ਹੋਇਆ: "ਕੀ ਤੁਸੀਂ ਅਜਿਹਾ ਕੁਝ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਇਹ ਗੂਗਲ ਸਪੈਨਰ ਵਰਗਾ ਹੋਵੇ, ਪਰ Django ORM ਨਾਲ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ?"

ਹੱਲ ਵਿਕਲਪ ਨੰਬਰ 0

ਪਹਿਲੀ ਗੱਲ ਜੋ ਮਨ ਵਿੱਚ ਆਈ:

• CloudSQL ਦੇ ਅੰਦਰ ਰਹੋ;
• ਕਿਸੇ ਵੀ ਰੂਪ ਵਿੱਚ ਖੇਤਰਾਂ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਬਿਲਟ-ਇਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਹੀਂ ਹੋਵੇਗੀ;
• PostgreSQL ਦੁਆਰਾ ਇੱਕ ਮੌਜੂਦਾ ਕਲਾਉਡ SQL ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ;
• ਕਿਤੇ ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇੱਕ PostgreSQL ਉਦਾਹਰਣ ਲਾਂਚ ਕਰੋ, ਪਰ ਘੱਟੋ ਘੱਟ ਮਾਸਟਰ ਨੂੰ ਨਾ ਛੂਹੋ।

ਹਾਏ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਹ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਕਿਉਂਕਿ ਹੋਸਟ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਹੈ (ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇੱਕ ਵੱਖਰੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹੈ) - pg_hba ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, ਅਤੇ ਸੁਪਰਯੂਜ਼ਰ ਦੇ ਅਧੀਨ ਵੀ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਹੈ.

ਹੱਲ ਵਿਕਲਪ ਨੰਬਰ 1

ਹੋਰ ਵਿਚਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਪਿਛਲੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਸੋਚ ਦੀ ਰੇਲਗੱਡੀ ਕੁਝ ਬਦਲ ਗਈ:

• ਅਸੀਂ ਅਜੇ ਵੀ CloudSQL ਦੇ ਅੰਦਰ ਰਹਿਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਅਸੀਂ MySQL 'ਤੇ ਸਵਿਚ ਕਰ ਰਹੇ ਹਾਂ, ਕਿਉਂਕਿ MySQL ਦੁਆਰਾ Cloud SQL ਦਾ ਇੱਕ ਬਾਹਰੀ ਮਾਸਟਰ ਹੈ, ਜੋ:

- ਬਾਹਰੀ MySQL ਲਈ ਇੱਕ ਪ੍ਰੌਕਸੀ ਹੈ;
- ਇੱਕ MySQL ਉਦਾਹਰਨ ਵਰਗਾ ਦਿਸਦਾ ਹੈ;
- ਦੂਜੇ ਬੱਦਲਾਂ ਜਾਂ ਆਨ-ਪ੍ਰੀਮਿਸਸ ਤੋਂ ਡੇਟਾ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਲਈ ਖੋਜ ਕੀਤੀ ਗਈ।

ਕਿਉਂਕਿ MySQL ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਿਧਾਂਤ ਵਿੱਚ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਇਹ ਬਹੁਤ ਅਸਥਿਰ ਅਤੇ ਅਸੁਵਿਧਾਜਨਕ ਸੀ। ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਅੱਗੇ ਚਲੇ ਗਏ, ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਰਾਉਣਾ ਬਣ ਗਿਆ, ਕਿਉਂਕਿ ਅਸੀਂ ਪੂਰੇ ਢਾਂਚੇ ਨੂੰ ਟੈਰਾਫਾਰਮ ਨਾਲ ਲਗਾਇਆ, ਅਤੇ ਅਚਾਨਕ ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਬਾਹਰੀ ਮਾਸਟਰ ਟੈਰਾਫਾਰਮ ਦੁਆਰਾ ਸਮਰਥਤ ਨਹੀਂ ਸੀ. ਹਾਂ, ਗੂਗਲ ਕੋਲ ਇੱਕ CLI ਹੈ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇੱਥੇ ਹਰ ਚੀਜ਼ ਕੰਮ ਕਰਦੀ ਹੈ - ਕਦੇ-ਕਦੇ ਇਹ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਕਈ ਵਾਰ ਇਹ ਨਹੀਂ ਬਣਾਈ ਜਾਂਦੀ। ਸ਼ਾਇਦ ਕਿਉਂਕਿ CLI ਦੀ ਖੋਜ ਬਾਹਰੀ ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਕੀਤੀ ਗਈ ਸੀ, ਨਾ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ।

ਦਰਅਸਲ, ਇਸ ਬਿੰਦੂ 'ਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਕਲਾਉਡ SQL ਬਿਲਕੁਲ ਵੀ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ। ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, ਅਸੀਂ ਉਹ ਸਭ ਕੁਝ ਕੀਤਾ ਜੋ ਅਸੀਂ ਕਰ ਸਕਦੇ ਸੀ.

ਹੱਲ ਵਿਕਲਪ ਨੰਬਰ 2

ਕਿਉਂਕਿ ਕਲਾਉਡ SQL ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ ਰਹਿਣਾ ਸੰਭਵ ਨਹੀਂ ਸੀ, ਅਸੀਂ ਸਮਝੌਤਾ ਹੱਲ ਲਈ ਲੋੜਾਂ ਤਿਆਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਲੋੜਾਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ:

• Kubernetes ਵਿੱਚ ਕੰਮ, ਸਰੋਤਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਵਰਤੋਂ ਅਤੇ Kubernetes (DCS, ...) ਅਤੇ GCP (LB, ...);
• ਕਲਾਉਡ ਵਿੱਚ HA ਪ੍ਰੌਕਸੀ ਵਰਗੀਆਂ ਬੇਲੋੜੀਆਂ ਚੀਜ਼ਾਂ ਦੇ ਝੁੰਡ ਤੋਂ ਬੈਲਸਟ ਦੀ ਘਾਟ;
• ਮੁੱਖ HA ਖੇਤਰ ਵਿੱਚ PostgreSQL ਜਾਂ MySQL ਨੂੰ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ; ਦੂਜੇ ਖੇਤਰਾਂ ਵਿੱਚ - ਮੁੱਖ ਖੇਤਰ ਦੇ RR ਤੋਂ HA ਅਤੇ ਇਸਦੀ ਕਾਪੀ (ਭਰੋਸੇਯੋਗਤਾ ਲਈ);
• ਮਲਟੀ ਮਾਸਟਰ (ਮੈਂ ਉਸ ਨਾਲ ਸੰਪਰਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਪਰ ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਸੀ)

.
ਇਨ੍ਹਾਂ ਮੰਗਾਂ ਦੇ ਸਿੱਟੇ ਵਜੋਂ ਪੀਢੁਕਵੇਂ DBMS ਅਤੇ ਬਾਈਡਿੰਗ ਵਿਕਲਪ:

• MySQL ਗਲੇਰਾ;
• ਕਾਕਰੋਚਡੀਬੀ;
• PostgreSQL ਟੂਲ

:
- pgpool-II;
- ਸਰਪ੍ਰਸਤ।

MySQL ਗਲੇਰਾ

MySQL Galera ਤਕਨਾਲੋਜੀ ਕੋਡਰਸ਼ਿਪ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਇਹ InnoDB ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਹੈ। ਵਿਸ਼ੇਸ਼ਤਾ:

• ਮਲਟੀ ਮਾਸਟਰ;
• ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ;
• ਕਿਸੇ ਵੀ ਨੋਡ ਤੋਂ ਪੜ੍ਹਨਾ;
• ਕਿਸੇ ਵੀ ਨੋਡ ਲਈ ਰਿਕਾਰਡਿੰਗ;
• ਬਿਲਟ-ਇਨ HA ਵਿਧੀ;
• ਬਿਟਨਾਮੀ ਤੋਂ ਇੱਕ ਹੈਲਮ ਚਾਰਟ ਹੈ।

ਕਾਕਰੋਚ ਡੀ ਬੀ

ਵੇਰਵਿਆਂ ਦੇ ਅਨੁਸਾਰ, ਚੀਜ਼ ਬਿਲਕੁਲ ਬੰਬ ਹੈ ਅਤੇ ਗੋ ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹੈ। ਮੁੱਖ ਭਾਗੀਦਾਰ ਕਾਕਰੋਚ ਲੈਬਜ਼ (Google ਦੇ ਲੋਕਾਂ ਦੁਆਰਾ ਸਥਾਪਿਤ) ਹੈ। ਇਹ ਰਿਲੇਸ਼ਨਲ DBMS ਅਸਲ ਵਿੱਚ ਵੰਡਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ (ਬਾਕਸ ਦੇ ਬਾਹਰ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਦੇ ਨਾਲ) ਅਤੇ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ। ਕੰਪਨੀ ਦੇ ਇਸ ਦੇ ਲੇਖਕਾਂ ਨੇ "NoSQL ਹੱਲਾਂ ਤੋਂ ਜਾਣੂ ਹਰੀਜੱਟਲ ਅਸੈਸਬਿਲਟੀ ਦੇ ਨਾਲ SQL ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਭਰਪੂਰਤਾ ਨੂੰ ਜੋੜਨ" ਦੇ ਟੀਚੇ ਦੀ ਰੂਪਰੇਖਾ ਦਿੱਤੀ।

ਇੱਕ ਵਧੀਆ ਬੋਨਸ ਪੋਸਟ-ਗਰੈਸ ਕੁਨੈਕਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਸਮਰਥਨ ਹੈ।

Pgpool

ਇਹ PostgreSQL ਲਈ ਇੱਕ ਐਡ-ਆਨ ਹੈ, ਅਸਲ ਵਿੱਚ, ਇੱਕ ਨਵੀਂ ਹਸਤੀ ਜੋ ਸਾਰੇ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕਰਦੀ ਹੈ। ਇਸਦਾ ਆਪਣਾ ਲੋਡ ਬੈਲੈਂਸਰ ਅਤੇ ਪਾਰਸਰ ਹੈ, ਜੋ BSD ਲਾਇਸੰਸ ਦੇ ਅਧੀਨ ਲਾਇਸੰਸਸ਼ੁਦਾ ਹੈ। ਇਹ ਕਾਫ਼ੀ ਮੌਕੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਕੁਝ ਡਰਾਉਣਾ ਲੱਗਦਾ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਨਵੀਂ ਹਸਤੀ ਦੀ ਮੌਜੂਦਗੀ ਕੁਝ ਵਾਧੂ ਸਾਹਸ ਦਾ ਸਰੋਤ ਬਣ ਸਕਦੀ ਹੈ।

ਸਰਪ੍ਰਸਤ

ਇਹ ਆਖਰੀ ਚੀਜ਼ ਹੈ ਜਿਸ 'ਤੇ ਮੇਰੀ ਨਜ਼ਰ ਪਈ, ਅਤੇ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਵਿਅਰਥ ਨਹੀਂ. ਪੈਟਰੋਨੀ ਇੱਕ ਓਪਨ ਸੋਰਸ ਉਪਯੋਗਤਾ ਹੈ, ਜੋ ਕਿ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇੱਕ ਪਾਈਥਨ ਡੈਮਨ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਆਟੋਮੈਟਿਕ ਰੋਲ ਸਵਿਚਿੰਗ ਨਾਲ PostgreSQL ਕਲੱਸਟਰਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਬਣਾਈ ਰੱਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਗੱਲ ਬਹੁਤ ਦਿਲਚਸਪ ਨਿਕਲੀ, ਕਿਉਂਕਿ ਇਹ ਕਿਊਬਰ ਦੇ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਏਕੀਕ੍ਰਿਤ ਹੈ ਅਤੇ ਕੋਈ ਨਵੀਂ ਸੰਸਥਾਵਾਂ ਪੇਸ਼ ਨਹੀਂ ਕਰਦੀ ਹੈ।

ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਕੀ ਚੁਣਿਆ?

ਚੋਣ ਆਸਾਨ ਨਹੀਂ ਸੀ:

1. ਕਾਕਰੋਚ ਡੀ ਬੀ - ਅੱਗ, ਪਰ ਹਨੇਰਾ;
2. MySQL ਗਲੇਰਾ - ਇਹ ਵੀ ਬੁਰਾ ਨਹੀਂ, ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ MySQL;
3. Pgpool - ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਲੋੜੀਆਂ ਹਸਤੀਆਂ, ਕਲਾਉਡ ਅਤੇ K8s ਨਾਲ ਇਸ ਤਰ੍ਹਾਂ ਏਕੀਕਰਣ;
4. ਸਰਪ੍ਰਸਤ - K8s ਨਾਲ ਸ਼ਾਨਦਾਰ ਏਕੀਕਰਣ, ਕੋਈ ਬੇਲੋੜੀ ਸੰਸਥਾਵਾਂ ਨਹੀਂ, GCP LB ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਏਕੀਕ੍ਰਿਤ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਚੋਣ ਪਟਰੋਨੀ 'ਤੇ ਡਿੱਗ ਗਈ।

ਸਿੱਟਾ

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

SQL ਲਈ, SQL ਲਾਈਵ ਹੋਵੇਗਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ PostgreSQL ਅਤੇ MySQL ਨੂੰ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇਸ ਤੋਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਉਹਨਾਂ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਹੈ।

ਸਰੋਤ: www.habr.com