ਕੀ ਡੇਟਾਬੇਸ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ?

ਕਿਸੇ ਤਰ੍ਹਾਂ, ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, ਆਈਟੀ ਉਦਯੋਗ ਨੂੰ ਕਿਸੇ ਵੀ ਕਾਰਨ ਕਰਕੇ ਦੋ ਸ਼ਰਤੀਆ ਕੈਂਪਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ: ਉਹ ਜਿਹੜੇ "ਲਈ" ਹਨ ਅਤੇ ਉਹ ਜੋ "ਵਿਰੋਧ" ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਿਵਾਦਾਂ ਦਾ ਵਿਸ਼ਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਨਮਾਨੀ ਹੋ ਸਕਦਾ ਹੈ। ਕਿਹੜਾ OS ਬਿਹਤਰ ਹੈ: ਵਿਨ ਜਾਂ ਲੀਨਕਸ? ਇੱਕ Android ਜਾਂ iOS ਸਮਾਰਟਫੋਨ 'ਤੇ? ਕੀ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਨੂੰ ਬੱਦਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਇਸਨੂੰ ਕੋਲਡ ਰੇਡ ਸਟੋਰੇਜ 'ਤੇ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਪੇਚਾਂ ਨੂੰ ਇੱਕ ਸੇਫ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ? ਕੀ PHP ਲੋਕਾਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮਰ ਕਹਾਉਣ ਦਾ ਅਧਿਕਾਰ ਹੈ? ਇਹ ਵਿਵਾਦ, ਕਦੇ-ਕਦਾਈਂ, ਕੁਦਰਤ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ ਅਤੇ ਖੇਡਾਂ ਦੀ ਦਿਲਚਸਪੀ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੋਈ ਆਧਾਰ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਅਜਿਹਾ ਹੀ ਹੋਇਆ ਕਿ ਡੌਕਰ ਅਤੇ ਕੰਡੀਸ਼ਨਲ k8s ਦੇ ਨਾਲ ਕੰਟੇਨਰਾਂ ਅਤੇ ਇਸ ਸਾਰੇ ਪਿਆਰੇ ਪਕਵਾਨਾਂ ਦੇ ਆਗਮਨ ਦੇ ਨਾਲ, ਬੈਕਐਂਡ ਦੇ ਵੱਖ ਵੱਖ ਖੇਤਰਾਂ ਵਿੱਚ ਨਵੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਵਰਤੋਂ "ਲਈ" ਅਤੇ "ਵਿਰੁਧ" ਬਹਿਸ ਸ਼ੁਰੂ ਹੋ ਗਈ. (ਆਓ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰੀਏ ਕਿ ਹਾਲਾਂਕਿ ਕੁਬਰਨੇਟਸ ਨੂੰ ਅਕਸਰ ਇਸ ਚਰਚਾ ਵਿੱਚ ਇੱਕ ਆਰਕੈਸਟਰੇਟਰ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਵੇਗਾ, ਇਸ ਵਿਸ਼ੇਸ਼ ਸਾਧਨ ਦੀ ਚੋਣ ਬੁਨਿਆਦੀ ਮਹੱਤਤਾ ਦੀ ਨਹੀਂ ਹੈ। ਇਸਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਲਈ ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਜਾਣੂ ਲੱਗਦਾ ਹੈ। .)

ਅਤੇ, ਇਹ ਜਾਪਦਾ ਹੈ, ਇਹ ਇੱਕੋ ਸਿੱਕੇ ਦੇ ਦੋ ਪਾਸਿਆਂ ਵਿਚਕਾਰ ਇੱਕ ਸਧਾਰਨ ਵਿਵਾਦ ਹੋਵੇਗਾ. ਵਿਨ ਬਨਾਮ ਲੀਨਕਸ ਵਿਚਕਾਰ ਸਦੀਵੀ ਟਕਰਾਅ ਜਿੰਨਾ ਬੇਸਮਝ ਅਤੇ ਬੇਰਹਿਮ, ਜਿਸ ਵਿੱਚ ਕਾਫ਼ੀ ਲੋਕ ਮੱਧ ਵਿੱਚ ਕਿਤੇ ਮੌਜੂਦ ਹਨ। ਪਰ ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਹਰ ਚੀਜ਼ ਇੰਨੀ ਸਧਾਰਨ ਨਹੀਂ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਵਿਵਾਦਾਂ ਵਿੱਚ ਕੋਈ ਸੱਜੇ ਪਾਸੇ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਡੇਟਾਬੇਸ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਕੰਟੇਨਰਾਂ ਦੀ "ਵਰਤੋਂ" ਜਾਂ "ਵਰਤੋਂ ਨਾ ਕਰੋ" ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਭ ਕੁਝ ਉਲਟ ਹੋ ਜਾਂਦਾ ਹੈ. ਕਿਉਂਕਿ ਇੱਕ ਖਾਸ ਅਰਥਾਂ ਵਿੱਚ, ਇਸ ਪਹੁੰਚ ਦੇ ਸਮਰਥਕ ਅਤੇ ਵਿਰੋਧੀ ਦੋਵੇਂ ਹੀ ਸਹੀ ਹਨ।

ਉੱਜਵਲ ਪੱਖ

ਲਾਈਟ ਸਾਈਡ ਦੀ ਦਲੀਲ ਨੂੰ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਇੱਕ ਵਾਕਾਂਸ਼ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: "ਹੈਲੋ, 2k19 ਵਿੰਡੋ ਦੇ ਬਾਹਰ ਹੈ!" ਇਹ ਲੋਕਪ੍ਰਿਯਤਾ ਦੀ ਤਰ੍ਹਾਂ ਜਾਪਦਾ ਹੈ, ਬੇਸ਼ੱਕ, ਪਰ ਜੇ ਤੁਸੀਂ ਸਥਿਤੀ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਇਸਦੇ ਫਾਇਦੇ ਹਨ. ਆਓ ਹੁਣ ਉਹਨਾਂ ਨੂੰ ਛਾਂਟੀ ਕਰੀਏ।

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

ਇਹ ਸਹੀ ਹੈ, ਡੇਟਾ. ਕਿਸੇ ਵੀ ਪ੍ਰੋਜੈਕਟ ਦਾ ਦਿਲ ਇਸਦਾ ਡੇਟਾ ਹੁੰਦਾ ਹੈ: ਇਹ ਜਾਂ ਤਾਂ ਇੱਕ ਆਮ DBMS - MySQL, Postgre, MongoDB, ਜਾਂ ਖੋਜ (ElasticSearch), ਕੈਚਿੰਗ ਲਈ ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰੇਜ਼ - ਉਦਾਹਰਨ ਲਈ, redis, ਆਦਿ ਲਈ ਵਰਤੀ ਗਈ ਸਟੋਰੇਜ ਹੋ ਸਕਦੀ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ ਅਸੀਂ ਨਹੀਂ ਹਾਂ। ਅਸੀਂ ਟੇਢੇ ਬੈਕਐਂਡ ਲਾਗੂਕਰਨ ਵਿਕਲਪਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਜਦੋਂ ਡਾਟਾਬੇਸ ਖਰਾਬ ਲਿਖਤੀ ਸਵਾਲਾਂ ਕਾਰਨ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਬਜਾਏ ਅਸੀਂ ਕਲਾਇੰਟ ਲੋਡ ਦੇ ਅਧੀਨ ਇਸ ਬਹੁਤ ਹੀ ਡੇਟਾਬੇਸ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ। ਆਖ਼ਰਕਾਰ, ਜਦੋਂ ਅਸੀਂ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੰਟੇਨਰਾਈਜ਼ ਕਰਦੇ ਹਾਂ ਅਤੇ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਕਿਸੇ ਵੀ ਗਿਣਤੀ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਇਸਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਸਕੇਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਡਾਟਾਬੇਸ 'ਤੇ ਲੋਡ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

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

ਨਾ ਸਿਰਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ, ਸਗੋਂ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਸੇਵਾਵਾਂ ਨੂੰ ਵੀ ਕਲੱਸਟਰ ਕਰਨਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤਰਕਪੂਰਨ ਹੈ। ਕਲੱਸਟਰਿੰਗ ਅਤੇ ਵੈਬ ਸਰਵਰਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਕੇ ਜੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ k8s ਵਿੱਚ ਲੋਡ ਨੂੰ ਆਪਸ ਵਿੱਚ ਵੰਡਦੇ ਹਨ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਡੇਟਾ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ - ਪੋਸਟਾਂ 'ਤੇ ਉਹੀ ਟਿੱਪਣੀਆਂ, ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਕੁਝ ਮੀਡੀਆ ਜਾਂ ਬਲੌਗ ਪਲੇਟਫਾਰਮ ਲੈਂਦੇ ਹਾਂ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਇੰਟਰਾ-ਕਲੱਸਟਰ ਹੈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਵਰਚੁਅਲ, ਇੱਕ ExternalService ਦੇ ਰੂਪ ਵਿੱਚ ਡੇਟਾਬੇਸ ਦੀ ਨੁਮਾਇੰਦਗੀ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਖੁਦ ਅਜੇ ਕਲੱਸਟਰ ਨਹੀਂ ਹੈ - ਕਿਊਬ ਵਿੱਚ ਤੈਨਾਤ ਵੈਬ ਸਰਵਰ ਸਾਡੇ ਸਥਿਰ ਲੜਾਈ ਡੇਟਾਬੇਸ ਤੋਂ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਲੈਂਦੇ ਹਨ, ਜੋ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਘੁੰਮਦਾ ਹੈ।

ਕੀ ਤੁਸੀਂ ਇੱਕ ਕੈਚ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ? ਅਸੀਂ ਲੋਡ ਨੂੰ ਵੰਡਣ ਅਤੇ ਮੁੱਖ ਵੈੱਬ ਸਰਵਰ ਨੂੰ ਕਰੈਸ਼ ਹੋਣ ਤੋਂ ਬਚਣ ਲਈ k8s ਜਾਂ Swarm ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਡੇਟਾਬੇਸ ਲਈ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਪਰ ਜੇਕਰ ਡੇਟਾਬੇਸ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਡੇ ਪੂਰੇ ਕਲੱਸਟਰਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ ਹੁੰਦਾ - ਖਾਲੀ ਵੈਬ ਪੇਜ ਕੀ ਚੰਗੇ ਹਨ ਜੋ ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਗਲਤੀ ਨੂੰ ਵਾਪਸ ਕਰਦੇ ਹਨ?

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਡੇਟਾਬੇਸ ਮਾਡਲ ਤੁਹਾਨੂੰ ਇਸ ਡੇਟਾਬੇਸ ਨੂੰ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਹੈ ਉੱਥੇ ਲਿਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ; ਜੇ ਅਸੀਂ ਇੱਕ ਗਲੋਬਲ ਸੇਵਾ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਸੈਨ ਫ੍ਰਾਂਸਿਸਕੋ ਖੇਤਰ ਵਿੱਚ ਕਿਤੇ ਇੱਕ ਵੈਬ ਕਲੱਸਟਰ ਨੂੰ ਸਪਿਨ ਕਰਨਾ ਅਤੇ ਉਸੇ ਸਮੇਂ ਮਾਸਕੋ ਖੇਤਰ ਅਤੇ ਪਿੱਛੇ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਵੇਲੇ ਪੈਕੇਟ ਭੇਜਣਾ ਕਾਫ਼ੀ ਤਰਕਹੀਣ ਹੈ।

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

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

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

ਅਤੇ ਹੁਣ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰਿੰਗ ਦੇ ਵਿਰੋਧੀਆਂ ਵਿੱਚ ਬਦਲਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ.

ਹਨੇਰਾ ਪਾਸਾ

ਇਹ ਦਲੀਲ ਦਿੰਦੇ ਹੋਏ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਕੰਟੇਨਰ ਬਣਾਉਣਾ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਸਰਵਰ 'ਤੇ ਚਲਾਉਣਾ ਜਾਰੀ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਣ ਕਿਉਂ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਕੱਟੜਪੰਥੀਆਂ ਦੀ ਬਿਆਨਬਾਜ਼ੀ ਅਤੇ "ਦਾਦਾ-ਦਾਦੀਆਂ ਨੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਡਾਟਾਬੇਸ ਚਲਾਇਆ, ਅਤੇ ਅਸੀਂ ਵੀ ਕਰਾਂਗੇ!" ਵਰਗੇ ਬਿਆਨਾਂ ਵੱਲ ਨਹੀਂ ਝੁਕਵਾਂਗੇ! ਇਸਦੀ ਬਜਾਏ, ਆਓ ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਦੇ ਨਾਲ ਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਜਿਸ ਵਿੱਚ ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਠੋਸ ਲਾਭਅੰਸ਼ਾਂ ਦਾ ਭੁਗਤਾਨ ਕਰੇਗੀ।

ਸਹਿਮਤ ਹੋਵੋ, ਜਿਨ੍ਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਅਧਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਹ ਸਭ ਤੋਂ ਵਧੀਆ ਮਿਲਿੰਗ ਮਸ਼ੀਨ ਆਪਰੇਟਰ ਦੁਆਰਾ ਇੱਕ ਹੱਥ ਦੀਆਂ ਉਂਗਲਾਂ 'ਤੇ ਗਿਣੇ ਜਾ ਸਕਦੇ ਹਨ. ਜ਼ਿਆਦਾਤਰ ਹਿੱਸੇ ਲਈ, ਇੱਥੋਂ ਤੱਕ ਕਿ k8s ਜਾਂ Docker Swarm ਦੀ ਵਰਤੋਂ ਵੀ ਬੇਲੋੜੀ ਹੈ - ਅਕਸਰ ਇਹਨਾਂ ਸਾਧਨਾਂ ਦਾ ਸਹਾਰਾ ਤਕਨਾਲੋਜੀ ਦੇ ਆਮ ਪ੍ਰਚਾਰ ਅਤੇ ਲਿੰਗ ਦੇ ਵਿਅਕਤੀ ਵਿੱਚ "ਸਰਬਸ਼ਕਤੀਮਾਨ" ਦੇ ਰਵੱਈਏ ਕਾਰਨ ਹਰ ਚੀਜ਼ ਵਿੱਚ ਧੱਕਣ ਲਈ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਬੱਦਲ ਅਤੇ ਕੰਟੇਨਰ. ਠੀਕ ਹੈ, ਕਿਉਂਕਿ ਹੁਣ ਇਹ ਫੈਸ਼ਨੇਬਲ ਹੈ ਅਤੇ ਹਰ ਕੋਈ ਇਸ ਨੂੰ ਕਰਦਾ ਹੈ.

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

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

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

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

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

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

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

ਇਹਨਾਂ ਸਾਰੇ "ਰੋਮਾਂਚਾਂ" ਦੀ ਰੋਸ਼ਨੀ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਰੱਖਣਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਅਤੇ ਆਸਾਨ ਹੈ, ਅਤੇ ਭਾਵੇਂ ਤੁਹਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੰਟੇਨਰਾਈਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਨੂੰ ਆਪਣੇ ਆਪ ਚੱਲਣ ਦਿਓ ਅਤੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਗੇਟਵੇ ਦੁਆਰਾ ਨਾਲ ਨਾਲ ਸੰਚਾਰ ਪ੍ਰਾਪਤ ਕਰੋ। ਡਾਟਾਬੇਸ, ਜਿਸ ਨੂੰ ਸਿਰਫ ਇੱਕ ਵਾਰ ਅਤੇ ਇੱਕ ਥਾਂ 'ਤੇ ਪੜ੍ਹਿਆ ਅਤੇ ਲਿਖਿਆ ਜਾਵੇਗਾ। ਇਹ ਪਹੁੰਚ ਗਲਤੀਆਂ ਅਤੇ ਡੀਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰ ਦਿੰਦੀ ਹੈ।

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

ਆਉਟਪੁੱਟ ਦੀ ਬਜਾਏ

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

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

ਸਰੋਤ: www.habr.com