DBA ਬੋਟ ਜੋ. ਐਨਾਟੋਲੀ ਸਟੈਨਸਲਰ (Postgres.ai)

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

ਵੀਡੀਓ:

ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਐਨਾਟੋਲੀ ਸਟੈਨਸਲਰ ਹੈ। ਮੈਂ ਇੱਕ ਕੰਪਨੀ ਲਈ ਕੰਮ ਕਰਦਾ ਹਾਂ postgres.ai. ਅਸੀਂ ਡਿਵੈਲਪਰਾਂ, DBAs ਅਤੇ QAs ਤੋਂ Postgres ਦੇ ਕੰਮ ਨਾਲ ਜੁੜੀਆਂ ਦੇਰੀਆਂ ਨੂੰ ਦੂਰ ਕਰਕੇ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਵਚਨਬੱਧ ਹਾਂ।

ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਵਧੀਆ ਗਾਹਕ ਹਨ ਅਤੇ ਅੱਜ ਦੀ ਰਿਪੋਰਟ ਦਾ ਹਿੱਸਾ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਸਮਰਪਿਤ ਕੀਤਾ ਜਾਵੇਗਾ ਜੋ ਅਸੀਂ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋਏ ਮਿਲੇ ਸੀ। ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ ਕਿ ਅਸੀਂ ਉਹਨਾਂ ਦੀ ਕਾਫ਼ੀ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕੀਤੀ।

ਜਦੋਂ ਅਸੀਂ ਗੁੰਝਲਦਾਰ ਹਾਈ-ਲੋਡ ਮਾਈਗਰੇਸ਼ਨਾਂ ਨੂੰ ਵਿਕਸਤ ਅਤੇ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਆਪਣੇ ਆਪ ਤੋਂ ਇਹ ਸਵਾਲ ਪੁੱਛਦੇ ਹਾਂ: "ਕੀ ਇਹ ਮਾਈਗ੍ਰੇਸ਼ਨ ਬੰਦ ਹੋ ਜਾਵੇਗਾ?"। ਅਸੀਂ ਸਮੀਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਵਧੇਰੇ ਤਜਰਬੇਕਾਰ ਸਹਿਕਰਮੀਆਂ, ਡੀਬੀਏ ਮਾਹਿਰਾਂ ਦੇ ਗਿਆਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ. ਅਤੇ ਉਹ ਦੱਸ ਸਕਦੇ ਹਨ ਕਿ ਇਹ ਉੱਡੇਗਾ ਜਾਂ ਨਹੀਂ।

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

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

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

ਇਹ ਦੁਖਦਾਈ ਹੈ, ਇਹ ਮਹਿੰਗਾ ਹੈ. ਇਹ ਨਾ ਕਰਨਾ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ।

ਅਤੇ ਅਜਿਹਾ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਕੀ ਹੈ?

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

ਇਹ ਸਾਨੂੰ ਕੁਝ ਤਰੁੱਟੀਆਂ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ, ਭਾਵ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਡ 'ਤੇ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਸਮੱਸਿਆਵਾਂ ਕੀ ਹਨ?

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

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

ਇਹ ਪਿਛਲੀ ਪਹੁੰਚ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਇੱਕ ਉੱਚ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਕਿਸੇ ਕਿਸਮ ਦੀ ਗਲਤੀ ਉਤਪਾਦਨ ਵਿੱਚ ਜਾਵੇਗੀ.

ਸਾਨੂੰ ਹਰੇਕ ਡਿਵੈਲਪਰ ਨੂੰ ਇੱਕ ਟੈਸਟ ਬੈਂਚ, ਇੱਕ ਪੂਰੇ ਆਕਾਰ ਦੀ ਕਾਪੀ ਦੇਣ ਤੋਂ ਕੀ ਰੋਕਦਾ ਹੈ? ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਸਪਸ਼ਟ ਹੈ ਕਿ ਰਸਤੇ ਵਿੱਚ ਕੀ ਆਉਂਦਾ ਹੈ।

ਕਿਸ ਕੋਲ ਇੱਕ ਟੈਰਾਬਾਈਟ ਤੋਂ ਵੱਡਾ ਡੇਟਾਬੇਸ ਹੈ? ਅੱਧੇ ਤੋਂ ਵੱਧ ਕਮਰੇ.

ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਹਰੇਕ ਡਿਵੈਲਪਰ ਲਈ ਮਸ਼ੀਨਾਂ ਨੂੰ ਰੱਖਣਾ, ਜਦੋਂ ਇੰਨਾ ਵੱਡਾ ਉਤਪਾਦਨ ਹੁੰਦਾ ਹੈ, ਬਹੁਤ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ.

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

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

ਪਰ ਉਹ ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਨੂੰ ਉਤਪਾਦ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਅਸੀਂ ਇੱਥੇ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ? ਆਓ ਟੈਸਟ ਬੈਂਚਾਂ ਨੂੰ ਸਸਤੇ ਕਰੀਏ ਅਤੇ ਹਰ ਡਿਵੈਲਪਰ ਨੂੰ ਆਪਣਾ ਟੈਸਟ ਬੈਂਚ ਦੇਈਏ।

ਅਤੇ ਇਹ ਸੰਭਵ ਹੈ.

ਅਤੇ ਇਸ ਪਹੁੰਚ ਵਿੱਚ, ਜਦੋਂ ਅਸੀਂ ਹਰੇਕ ਡਿਵੈਲਪਰ ਲਈ ਪਤਲੇ ਕਲੋਨ ਬਣਾਉਂਦੇ ਹਾਂ, ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ 10TB ਡਾਟਾਬੇਸ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ 10 ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ XNUMX x XNUMXTB ਡਾਟਾਬੇਸ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕ ਮਸ਼ੀਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਡਿਵੈਲਪਰ ਲਈ ਪਤਲੀਆਂ ਆਈਸੋਲੇਟਡ ਕਾਪੀਆਂ ਬਣਾਉਣ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਮਸ਼ੀਨ ਦੀ ਲੋੜ ਹੈ। ਮੈਂ ਤੁਹਾਨੂੰ ਥੋੜੀ ਦੇਰ ਬਾਅਦ ਦੱਸਾਂਗਾ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਅਸਲੀ ਉਦਾਹਰਨ:

• DB - 4,5 ਟੈਰਾਬਾਈਟ।

• ਅਸੀਂ 30 ਸਕਿੰਟਾਂ ਵਿੱਚ ਸੁਤੰਤਰ ਕਾਪੀਆਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।

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

ਇਸ ਮਹਾਨ ਹੈ. ਇੱਥੇ ਅਸੀਂ ਜਾਦੂ ਅਤੇ ਸਮਾਨਾਂਤਰ ਬ੍ਰਹਿਮੰਡ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ।

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ OpenZFS ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਹੋਰ ਵਿਕਲਪ ਹਨ:

• ਐਲਵੀਐਮ,

• ਸਟੋਰੇਜ (ਉਦਾਹਰਨ ਲਈ, ਸ਼ੁੱਧ ਸਟੋਰੇਜ)।

ਮੈਂ ਜਿਸ ਡੇਟਾਬੇਸ ਲੈਬ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਉਹ ਮਾਡਿਊਲਰ ਹੈ। ਇਹਨਾਂ ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਹੁਣ ਲਈ, ਅਸੀਂ OpenZFS 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ ਹੈ, ਕਿਉਂਕਿ ਖਾਸ ਤੌਰ 'ਤੇ LVM ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ।

ਕਿਦਾ ਚਲਦਾ? ਹਰ ਵਾਰ ਜਦੋਂ ਅਸੀਂ ਇਸਨੂੰ ਬਦਲਦੇ ਹਾਂ ਤਾਂ ਡੇਟਾ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਮਾਰਕ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਨਵਾਂ ਡੇਟਾ ਸਮੇਂ ਦੇ ਇੱਕ ਨਵੇਂ ਬਿੰਦੂ, ਇੱਕ ਨਵੇਂ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਹੈ।

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

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

ਅਤੇ ਅਸੀਂ ਸ਼ਾਖਾ ਕਰਾਂਗੇ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਹਰੇਕ ਡਿਵੈਲਪਰ ਕੋਲ ਉਸਦਾ ਆਪਣਾ ਕਲੋਨ ਰੱਖਣ ਦਾ ਮੌਕਾ ਹੋਵੇਗਾ ਜਿਸਨੂੰ ਉਹ ਸੰਪਾਦਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਡੇਟਾ ਸਾਰਿਆਂ ਵਿਚਕਾਰ ਸਾਂਝਾ ਕੀਤਾ ਜਾਵੇਗਾ।

ਘਰ ਵਿੱਚ ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

• ਪਹਿਲਾ ਡੇਟਾ ਦਾ ਸਰੋਤ ਹੈ, ਜਿੱਥੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਲਓਗੇ. ਤੁਸੀਂ ਉਤਪਾਦਨ ਦੇ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਥਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਬੈਕਅਪ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਕੌਂਫਿਗਰ ਕੀਤੇ ਹਨ, ਮੈਨੂੰ ਉਮੀਦ ਹੈ. WAL-E, WAL-G ਜਾਂ ਬਰਮਨ। ਅਤੇ ਭਾਵੇਂ ਤੁਸੀਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਕਲਾਉਡ ਹੱਲ ਜਿਵੇਂ ਕਿ RDS ਜਾਂ Cloud SQL ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲਾਜ਼ੀਕਲ ਡੰਪ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਅਸੀਂ ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਬੈਕਅਪ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਸ ਪਹੁੰਚ ਨਾਲ ਤੁਸੀਂ ਫਾਈਲਾਂ ਦੀ ਭੌਤਿਕ ਬਣਤਰ ਨੂੰ ਵੀ ਬਰਕਰਾਰ ਰੱਖੋਗੇ, ਜੋ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦੇ ਹੋਰ ਵੀ ਨੇੜੇ ਹੋਣ ਦੀ ਆਗਿਆ ਦੇਵੇਗੀ ਜੋ ਤੁਸੀਂ ਮੌਜੂਦ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜਨ ਲਈ ਉਤਪਾਦਨ ਵਿੱਚ ਵੇਖੋਗੇ।

• ਦੂਜਾ ਉਹ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਲੈਬ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ. ਇਹ ਕਲਾਉਡ ਹੋ ਸਕਦਾ ਹੈ, ਇਹ ਆਨ-ਪ੍ਰੀਮਿਸ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਥੇ ਇਹ ਦੱਸਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ZFS ਡਾਟਾ ਕੰਪਰੈਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਅਤੇ ਇਹ ਇਸ ਨੂੰ ਕਾਫ਼ੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ.

ਕਲਪਨਾ ਕਰੋ ਕਿ ਅਜਿਹੇ ਹਰੇਕ ਕਲੋਨ ਲਈ, ਉਹਨਾਂ ਓਪਰੇਸ਼ਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਅਸੀਂ ਅਧਾਰ ਨਾਲ ਕਰਦੇ ਹਾਂ, ਕਿਸੇ ਕਿਸਮ ਦਾ ਦੇਵ ਵਧੇਗਾ। ਇਸ ਦੇ ਲਈ ਦੇਵ ਨੂੰ ਵੀ ਜਗ੍ਹਾ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਪਰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਅਸੀਂ 4,5 ਟੇਰਾਬਾਈਟ ਦਾ ਅਧਾਰ ਲਿਆ ਹੈ, ZFS ਇਸਨੂੰ 3,5 ਟੈਰਾਬਾਈਟ ਤੱਕ ਸੰਕੁਚਿਤ ਕਰੇਗਾ। ਇਹ ਸੈਟਿੰਗਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ। ਅਤੇ ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਦੇਵ ਲਈ ਜਗ੍ਹਾ ਹੈ।

ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਵੱਖ-ਵੱਖ ਮਾਮਲਿਆਂ ਲਈ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।

• ਇਹ ਡਿਵੈਲਪਰ ਹਨ, ਪੁੱਛਗਿੱਛ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ, ਅਨੁਕੂਲਤਾ ਲਈ ਡੀ.ਬੀ.ਏ.

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

• ਅਤੇ ਇੱਕ ਹੋਰ ਕੇਸ. ਜੇਕਰ ਕੰਪਨੀ ਕੋਲ ਕੋਈ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਣਾਲੀ ਸਥਾਪਤ ਨਹੀਂ ਹੈ, ਤਾਂ ਅਸੀਂ ਉਤਪਾਦ ਅਧਾਰ ਦੇ ਇੱਕ ਪਤਲੇ ਕਲੋਨ ਨੂੰ ਅਲੱਗ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਲੰਬੇ ਸਵਾਲਾਂ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਸੂਚਕਾਂਕ ਨੂੰ ਦੇ ਸਕਦੇ ਹਾਂ ਜੋ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਇਸ ਪਹੁੰਚ ਨਾਲ:

1. "ਉਤਪਾਦ" 'ਤੇ ਗਲਤੀਆਂ ਦੀ ਘੱਟ ਸੰਭਾਵਨਾ, ਕਿਉਂਕਿ ਅਸੀਂ ਪੂਰੇ-ਆਕਾਰ ਦੇ ਡੇਟਾ 'ਤੇ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਹੈ।

2. ਸਾਡੇ ਕੋਲ ਟੈਸਟਿੰਗ ਦਾ ਸੱਭਿਆਚਾਰ ਹੈ, ਕਿਉਂਕਿ ਹੁਣ ਤੁਹਾਨੂੰ ਆਪਣੇ ਸਟੈਂਡ ਲਈ ਘੰਟਿਆਂ ਦਾ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰਨਾ ਪਵੇਗਾ।

3. ਅਤੇ ਇੱਥੇ ਕੋਈ ਰੁਕਾਵਟ ਨਹੀਂ ਹੈ, ਟੈਸਟਾਂ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਹੈ. ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜਾ ਕੇ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਬਿਹਤਰ ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਅਸੀਂ ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਾਂ।

• ਘੱਟ ਰੀਫੈਕਟਰਿੰਗ ਹੋਵੇਗੀ। ਉਤਪਾਦ ਵਿੱਚ ਘੱਟ ਬੱਗ ਖਤਮ ਹੋਣਗੇ। ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਘੱਟ ਰੀਫੈਕਟਰ ਕਰਾਂਗੇ।

• ਅਸੀਂ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਉਲਟਾ ਸਕਦੇ ਹਾਂ। ਇਹ ਮਿਆਰੀ ਪਹੁੰਚ ਨਹੀਂ ਹੈ।

1. ਇਹ ਲਾਭਦਾਇਕ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਟੈਸਟ ਬੈਂਚਾਂ ਦੇ ਸਰੋਤ ਸਾਂਝੇ ਕਰਦੇ ਹਾਂ।

ਪਹਿਲਾਂ ਹੀ ਚੰਗਾ ਹੈ, ਪਰ ਹੋਰ ਕੀ ਤੇਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?

ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਲਈ ਧੰਨਵਾਦ, ਅਸੀਂ ਅਜਿਹੇ ਟੈਸਟਿੰਗ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਲਈ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਬਹੁਤ ਘਟਾ ਸਕਦੇ ਹਾਂ.

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

ਪਰ ਜੇ ਇਹ ਨਹੀਂ ਹੈ ਤਾਂ ਕਿਵੇਂ ਵਧਣਾ ਹੈ. ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਟੈਸਟ ਡੇਟਾ ਦਾ ਬਹੁਤ ਛੋਟਾ ਸੈੱਟ ਉਪਲਬਧ ਹੈ? ਫਿਰ ਤੁਹਾਨੂੰ ਕੋਈ ਅਸਲੀ ਅਨੁਭਵ ਨਹੀਂ ਮਿਲੇਗਾ।

ਇਸ ਦਾਇਰੇ ਵਿੱਚੋਂ ਕਿਵੇਂ ਨਿਕਲੀਏ? ਪਹਿਲੇ ਇੰਟਰਫੇਸ ਵਜੋਂ, ਕਿਸੇ ਵੀ ਪੱਧਰ ਦੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ, ਅਸੀਂ ਸਲੈਕ ਬੋਟ ਨੂੰ ਚੁਣਿਆ ਹੈ। ਪਰ ਇਹ ਕੋਈ ਹੋਰ ਇੰਟਰਫੇਸ ਹੋ ਸਕਦਾ ਹੈ।

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

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

ਪਰ, ਬੇਸ਼ੱਕ, ਸਮੱਸਿਆਵਾਂ ਹਨ. ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਸੰਸਾਰ ਹੈ, ਅਤੇ ਅਸੀਂ ਇੱਕ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਕਲੋਨਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰ ਰਿਹਾ ਹੈ, ਸਾਨੂੰ ਕਲੋਨਾਂ ਲਈ ਉਪਲਬਧ ਮੈਮੋਰੀ ਅਤੇ CPU ਪਾਵਰ ਦੀ ਮਾਤਰਾ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨਾ ਹੋਵੇਗਾ।

ਪਰ ਇਹਨਾਂ ਟੈਸਟਾਂ ਨੂੰ ਮੰਨਣਯੋਗ ਹੋਣ ਲਈ, ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਮਹੱਤਵਪੂਰਨ ਬਿੰਦੂ ਇੱਕੋ ਡੇਟਾ ਹੈ. ਪਰ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ। ਅਤੇ ਅਸੀਂ ਉਸੇ ਸੰਰਚਨਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ. ਅਤੇ ਅਸੀਂ ਅਜਿਹੀ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀ ਸੰਰਚਨਾ ਦੇ ਸਕਦੇ ਹਾਂ।

ਉਤਪਾਦਨ ਵਿੱਚ ਸਮਾਨ ਹਾਰਡਵੇਅਰ ਹੋਣਾ ਵਧੀਆ ਹੋਵੇਗਾ, ਪਰ ਇਹ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ।

ਆਓ ਯਾਦ ਰੱਖੋ ਕਿ ਪੋਸਟਗ੍ਰੇਸ ਮੈਮੋਰੀ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ. ਸਾਡੇ ਕੋਲ ਦੋ ਕੈਚ ਹਨ। ਇੱਕ ਫਾਈਲ ਸਿਸਟਮ ਤੋਂ ਅਤੇ ਇੱਕ ਨੇਟਿਵ ਪੋਸਟਗ੍ਰੇਸ, ਭਾਵ ਸ਼ੇਅਰਡ ਬਫਰ ਕੈਸ਼।

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

ਅਤੇ ਦੂਜਾ ਕੈਸ਼ ਸਾਰੀ ਉਪਲਬਧ ਸਪੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਮਸ਼ੀਨ ਤੇ ਕਈ ਕਲੋਨ ਬਣਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅਸੀਂ ਹੌਲੀ ਹੌਲੀ ਮੈਮੋਰੀ ਭਰਦੇ ਹਾਂ. ਅਤੇ ਇੱਕ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ, ਸ਼ੇਅਰਡ ਬਫਰ ਕੈਸ਼ ਮਸ਼ੀਨ 'ਤੇ ਉਪਲਬਧ ਮੈਮੋਰੀ ਦੀ ਕੁੱਲ ਮਾਤਰਾ ਦਾ 25% ਹੈ।

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

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

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਪ੍ਰੋਡ 'ਤੇ ਇੱਕ ਵੱਡਾ ਕੈਸ਼ ਹੈ, ਤਾਂ ਪੋਸਟਗ੍ਰੇਸ ਇੱਕ ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਪਸੰਦ ਕਰੇਗਾ। ਅਤੇ ਜੇਕਰ ਨਹੀਂ, ਤਾਂ SeqScan ਹੋਵੇਗਾ। ਅਤੇ ਜੇਕਰ ਸਾਡੀਆਂ ਯੋਜਨਾਵਾਂ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?

ਪਰ ਇੱਥੇ ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਦੇ ਹਾਂ ਕਿ ਅਸਲ ਵਿੱਚ ਪੋਸਟਗ੍ਰੇਸ ਵਿੱਚ ਯੋਜਨਾ ਯੋਜਨਾ ਵਿੱਚ ਸ਼ੇਅਰਡ ਬਫਰ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਖਾਸ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੀ, ਇਹ ਪ੍ਰਭਾਵੀ_ਕੈਸ਼_ਸਾਈਜ਼ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

Effective_cache_size ਕੈਸ਼ ਦੀ ਅੰਦਾਜ਼ਨ ਮਾਤਰਾ ਹੈ ਜੋ ਸਾਡੇ ਲਈ ਉਪਲਬਧ ਹੈ, ਜਿਵੇਂ ਕਿ ਬਫਰ ਕੈਸ਼ ਅਤੇ ਫਾਈਲ ਸਿਸਟਮ ਕੈਸ਼ ਦਾ ਜੋੜ। ਇਹ ਸੰਰਚਨਾ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ. ਅਤੇ ਇਹ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ.

ਅਤੇ ਇਸ ਪੈਰਾਮੀਟਰ ਦੇ ਕਾਰਨ, ਅਸੀਂ ਪੋਸਟਗ੍ਰੇਸ ਦੀ ਕਿਸਮ ਦੀ ਚਾਲ ਕਰ ਸਕਦੇ ਹਾਂ, ਇਹ ਕਹਿੰਦੇ ਹੋਏ ਕਿ ਸਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਉਪਲਬਧ ਹੈ, ਭਾਵੇਂ ਸਾਡੇ ਕੋਲ ਇਹ ਡੇਟਾ ਨਹੀਂ ਹੈ. ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, ਯੋਜਨਾਵਾਂ ਉਤਪਾਦਨ ਦੇ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ.

ਪਰ ਇਹ ਸਮੇਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਸਮੇਂ ਦੁਆਰਾ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਦੇ ਹਾਂ, ਪਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸਮਾਂ ਕਈ ਕਾਰਕਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ:

• ਇਹ ਉਸ ਲੋਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਉਤਪਾਦ 'ਤੇ ਹੈ।

• ਇਹ ਮਸ਼ੀਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.

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

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

ਆਉ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ ਕਿ ਜੋਅ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ।

ਆਓ ਇੱਕ ਅਸਲੀ ਸਿਸਟਮ ਤੋਂ ਇੱਕ ਬੇਨਤੀ ਕਰੀਏ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਡੇਟਾਬੇਸ 1 ਟੈਰਾਬਾਈਟ ਹੈ. ਅਤੇ ਅਸੀਂ 10 ਤੋਂ ਵੱਧ ਪਸੰਦਾਂ ਵਾਲੀਆਂ ਤਾਜ਼ਾ ਪੋਸਟਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਅਸੀਂ ਚੈਨਲ ਨੂੰ ਸੁਨੇਹਾ ਲਿਖ ਰਹੇ ਹਾਂ, ਸਾਡੇ ਲਈ ਇੱਕ ਕਲੋਨ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਤੇ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਅਜਿਹੀ ਬੇਨਤੀ 2,5 ਮਿੰਟਾਂ ਵਿੱਚ ਪੂਰੀ ਹੋ ਜਾਵੇਗੀ। ਇਹ ਪਹਿਲੀ ਚੀਜ਼ ਹੈ ਜੋ ਅਸੀਂ ਨੋਟਿਸ ਕਰਦੇ ਹਾਂ.

B Joe ਤੁਹਾਨੂੰ ਯੋਜਨਾ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਆਧਾਰ 'ਤੇ ਸਵੈਚਲਿਤ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦਿਖਾਏਗਾ।

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

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

ਅਤੇ, ਇਹ ਜਾਪਦਾ ਹੈ, ਸਾਡੇ ਕੋਲ ਇੱਥੇ ਇੱਕ ਸੂਚਕਾਂਕ ਸਕੈਨ ਹੈ ਅਤੇ ਜਲਦੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ, ਪਰ ਕਿਉਂਕਿ ਅਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰ ਲਿਆ ਹੈ (ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨੀ ਪਈ ਹੈ), ਬੇਨਤੀ ਹੌਲੀ ਹੌਲੀ ਕੰਮ ਕਰਦੀ ਹੈ।

ਅਤੇ ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਯੋਜਨਾ ਵਿੱਚ ਹੋਇਆ ਹੈ ਕਿ ਪੁੱਛਗਿੱਛ ਦੀਆਂ ਸ਼ਰਤਾਂ ਅਤੇ ਸੂਚਕਾਂਕ ਦੀਆਂ ਸ਼ਰਤਾਂ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ.

ਆਉ ਇੰਡੈਕਸ ਨੂੰ ਹੋਰ ਸਟੀਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਉਸ ਤੋਂ ਬਾਅਦ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕਿਵੇਂ ਬਦਲਦੀ ਹੈ।

ਸੂਚਕਾਂਕ ਨੂੰ ਬਣਾਉਣ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮਾਂ ਲੱਗਿਆ, ਪਰ ਹੁਣ ਅਸੀਂ ਪੁੱਛਗਿੱਛ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਮਾਂ 2,5 ਮਿੰਟ ਦੀ ਬਜਾਏ ਸਿਰਫ 156 ਮਿਲੀਸਕਿੰਟ ਹੈ, ਜੋ ਕਿ ਕਾਫ਼ੀ ਚੰਗਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਸਿਰਫ 6 ਮੈਗਾਬਾਈਟ ਡੇਟਾ ਪੜ੍ਹਦੇ ਹਾਂ।

ਅਤੇ ਹੁਣ ਅਸੀਂ ਸਿਰਫ਼ ਇੰਡੈਕਸ ਸਕੈਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਇੱਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਕਹਾਣੀ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਯੋਜਨਾ ਨੂੰ ਕੁਝ ਹੋਰ ਸਮਝਣ ਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪੇਸ਼ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਅਸੀਂ ਫਲੇਮ ਗ੍ਰਾਫ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ।

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

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

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

ਅਤੇ ਡਿਵੈਲਪਰ ਜਿਨ੍ਹਾਂ ਨੇ ਅਜੇ ਤੱਕ ਇਸ ਵਿਸ਼ੇ ਵਿੱਚ ਖੋਜ ਨਹੀਂ ਕੀਤੀ ਹੈ, ਉਹ ਵੀ explain.depesz.com ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਲਈ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਮੈਟ੍ਰਿਕਸ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਕਿਹੜੀਆਂ ਨਹੀਂ।

ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਇੱਕ ਨਵੀਂ ਪਹੁੰਚ ਹੈ - ਇਹ ਹੈ explain.dalibo.com। ਉਹ ਇੱਕ ਟ੍ਰੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਕਰਦੇ ਹਨ, ਪਰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਨੋਡਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਬਹੁਤ ਔਖਾ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਢਾਂਚੇ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝ ਸਕਦੇ ਹੋ, ਹਾਲਾਂਕਿ, ਜੇਕਰ ਕੋਈ ਵੱਡੀ ਬੇਨਤੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅੱਗੇ ਅਤੇ ਪਿੱਛੇ ਸਕ੍ਰੋਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਪਰ ਇੱਕ ਵਿਕਲਪ ਵੀ.

ਸਹਿਯੋਗ

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

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

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

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮੈਂ ਖਤਮ ਹੁੰਦਾ ਹਾਂ. ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

ਤੁਹਾਡੇ ਸਵਾਲ

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਬਹੁਤ ਦਿਲਚਸਪ, ਖਾਸ ਕਰਕੇ ਮੇਰੇ ਲਈ, ਕਿਉਂਕਿ ਮੈਂ ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ ਉਸੇ ਸਮੱਸਿਆ ਬਾਰੇ ਹੱਲ ਕੀਤਾ ਸੀ. ਅਤੇ ਇਸ ਲਈ ਮੇਰੇ ਕੋਲ ਕਈ ਸਵਾਲ ਹਨ। ਉਮੀਦ ਹੈ ਕਿ ਮੈਂ ਇਸਦਾ ਘੱਟੋ ਘੱਟ ਹਿੱਸਾ ਪ੍ਰਾਪਤ ਕਰਾਂਗਾ.

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

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

ਹਾਂ, ਮੇਰੇ ਕੋਲ ਇੱਕ ਨੇਸਟਡ ਸਵਾਲ ਹੈ। ਭਾਵ, ਤੁਸੀਂ ਇਹਨਾਂ ਮੋਡੀਊਲਾਂ ਦੇ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋ? ਸਾਡੇ ਕੋਲ ਇਹ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਇੱਕ ਪੂਰੀ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ। ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ?

ਹਰੇਕ ਕਲੋਨ ਲਈ ਕੁਝ ttl ਹੈ। ਅਸਲ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਥਿਰ ttl ਹੈ.

ਕੀ, ਜੇ ਕੋਈ ਰਾਜ਼ ਨਹੀਂ?

1 ਘੰਟਾ, ਭਾਵ ਵਿਹਲਾ - 1 ਘੰਟਾ। ਜੇ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਮਾਰਦੇ ਹਾਂ. ਪਰ ਇੱਥੇ ਕੋਈ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਕਲੋਨ ਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਵਧਾ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਜੇਕਰ ਤੁਹਾਨੂੰ ਇਸਦੀ ਦੁਬਾਰਾ ਲੋੜ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ.

ਮੈਂ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਚੋਣ ਵਿੱਚ ਵੀ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹਾਂ, ਕਿਉਂਕਿ, ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਜਾਂ ਕਿਸੇ ਹੋਰ ਕਾਰਨ ਕਰਕੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕਈ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ. ZFS ਕਿਉਂ? ਤੁਸੀਂ LVM ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ? ਤੁਸੀਂ ਦੱਸਿਆ ਹੈ ਕਿ LVM ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ। ਸਮੱਸਿਆਵਾਂ ਕੀ ਸਨ? ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਸਟੋਰੇਜ ਦੇ ਨਾਲ ਹੈ.

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

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

ਨਿਕੋਲਾਈ ਸਮੋਕਵਾਲਵ: ਕੀ ਮੈਂ ਹੋਰ ਟਿੱਪਣੀ ਕਰ ਸਕਦਾ ਹਾਂ? ਮੇਰਾ ਨਾਮ ਨਿਕੋਲੇ ਹੈ, ਅਸੀਂ ਅਨਾਟੋਲੀ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਮੈਂ ਸਹਿਮਤ ਹਾਂ ਕਿ ਸਟੋਰੇਜ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਅਤੇ ਸਾਡੇ ਕੁਝ ਗਾਹਕਾਂ ਕੋਲ ਸ਼ੁੱਧ ਸਟੋਰੇਜ ਆਦਿ ਹੈ।

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

ਪਰ ZFS ਹਰ ਕਿਸੇ ਲਈ ਉਪਲਬਧ ਹੈ। DelPhix ਪਹਿਲਾਂ ਹੀ ਕਾਫੀ ਹੈ, ਉਹਨਾਂ ਕੋਲ 300 ਗਾਹਕ ਹਨ. ਇਹਨਾਂ ਵਿੱਚੋਂ, ਕਿਸਮਤ 100 ਦੇ ਕੋਲ 50 ਗਾਹਕ ਹਨ, ਯਾਨੀ ਉਹ ਨਾਸਾ, ਆਦਿ ਦੇ ਉਦੇਸ਼ ਹਨ। ਹਰ ਕਿਸੇ ਲਈ ਇਹ ਤਕਨਾਲੋਜੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਇੱਕ ਓਪਨ ਸੋਰਸ ਕੋਰ ਹੈ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਇੰਟਰਫੇਸ ਹਿੱਸਾ ਹੈ ਜੋ ਓਪਨ ਸੋਰਸ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਅਸੀਂ ਦਿਖਾਵਾਂਗੇ। ਪਰ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਪਹੁੰਚਯੋਗ ਹੋਵੇ। ਅਸੀਂ ਇੱਕ ਕ੍ਰਾਂਤੀ ਲਿਆਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਸਾਰੇ ਟੈਸਟਰ ਲੈਪਟਾਪਾਂ 'ਤੇ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਬੰਦ ਕਰ ਦੇਣ। ਸਾਨੂੰ SELECT ਲਿਖਣਾ ਪਵੇਗਾ ਅਤੇ ਤੁਰੰਤ ਦੇਖੋ ਕਿ ਇਹ ਹੌਲੀ ਹੈ. ਇਸ ਬਾਰੇ ਤੁਹਾਨੂੰ ਦੱਸਣ ਲਈ DBA ਦੀ ਉਡੀਕ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਇੱਥੇ ਮੁੱਖ ਟੀਚਾ ਹੈ. ਅਤੇ ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਸਾਰੇ ਇਸ ਵੱਲ ਆਵਾਂਗੇ. ਅਤੇ ਅਸੀਂ ਹਰ ਕਿਸੇ ਲਈ ਇਹ ਚੀਜ਼ ਬਣਾਉਂਦੇ ਹਾਂ. ਇਸ ਲਈ ZFS, ਕਿਉਂਕਿ ਇਹ ਹਰ ਜਗ੍ਹਾ ਉਪਲਬਧ ਹੋਵੇਗਾ. ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਅਤੇ ਇੱਕ ਓਪਨ ਸੋਰਸ ਲਾਇਸੰਸ ਆਦਿ ਲੈਣ ਲਈ ਭਾਈਚਾਰੇ ਦਾ ਧੰਨਵਾਦ।*

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

ਅਤੇ ਦੂਜਾ ਸਵਾਲ ਸਟੈਂਡਾਂ ਦੀ ਅਸਮਾਨਤਾ ਬਾਰੇ ਹੈ. ਮੰਨ ਲਓ ਕਿ ਮੇਰੇ ਕੋਲ ਇੱਥੇ ZFS ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਵਧੀਆ ਹੈ, ਪਰ ਪ੍ਰੋਡ 'ਤੇ ਕਲਾਇੰਟ ਕੋਲ ZFS ਨਹੀਂ ਹੈ, ਪਰ ext4, ਉਦਾਹਰਨ ਲਈ. ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕਿਵੇਂ?

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

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

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

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

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

ਪਰ ਕਿਉਂਕਿ ਸਿਸਟਮ ਵਿਸਤ੍ਰਿਤ ਹੈ, ਇਸ ਨੂੰ MySQL ਲਈ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਅਜਿਹੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ. ਯਾਂਡੇਕਸ ਕੋਲ ਇੱਕ ਸਮਾਨ ਚੀਜ਼ ਹੈ, ਪਰ ਉਹ ਇਸਨੂੰ ਕਿਤੇ ਵੀ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੇ ਹਨ. ਉਹ ਇਸਨੂੰ Yandex.Metrica ਦੇ ਅੰਦਰ ਵਰਤਦੇ ਹਨ। ਅਤੇ MySQL ਬਾਰੇ ਸਿਰਫ ਇੱਕ ਕਹਾਣੀ ਹੈ. ਪਰ ਤਕਨਾਲੋਜੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਹਨ, ZFS.

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੇਰੇ ਕੋਲ ਵੀ ਇੱਕ ਦੋ ਸਵਾਲ ਹਨ। ਤੁਸੀਂ ਦੱਸਿਆ ਹੈ ਕਿ ਕਲੋਨਿੰਗ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਉੱਥੇ ਵਾਧੂ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਲਈ। ਕੀ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਥੋੜਾ ਹੋਰ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

ਅਤੇ ਮੈਂ ਤੁਰੰਤ ਸਟੈਂਡਾਂ ਦੀ ਸਮਾਨਤਾ, ਯੋਜਨਾਵਾਂ ਦੀ ਸਮਾਨਤਾ ਬਾਰੇ ਦੂਜਾ ਸਵਾਲ ਪੁੱਛਾਂਗਾ. ਯੋਜਨਾ ਪੋਸਟਗ੍ਰੇਸ ਦੁਆਰਾ ਇਕੱਠੇ ਕੀਤੇ ਅੰਕੜਿਆਂ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਦੇ ਹੋ?

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

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

ਇੰਡੈਕਸ ਹਰ ਵਾਰ ਬਣਾਇਆ ਜਾਵੇਗਾ?

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

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

ਇੱਥੇ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਹੈ. ਜੇ ਤੁਸੀਂ ਕਲਾਉਡ ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਉੱਥੇ ਸਿਰਫ ਲਾਜ਼ੀਕਲ ਡੰਪ ਉਪਲਬਧ ਹਨ, ਕਿਉਂਕਿ ਗੂਗਲ, ​​​​ਐਮਾਜ਼ਾਨ ਤੁਹਾਨੂੰ ਭੌਤਿਕ ਕਾਪੀ ਲੈਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ ਹਨ. ਕੋਈ ਸਮੱਸਿਆ ਹੋਵੇਗੀ।

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

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

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

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅੱਪਡੇਟ ਇੱਕ ਵਾਧੂ ਪਰਤ ਦੇ ਰੂਪ ਵਿੱਚ ਵਾਪਰੇਗਾ, ਅਤੇ ਸਾਰੀਆਂ ਨਵੀਆਂ ਤਸਵੀਰਾਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਲੇਅਰ ਦੇ ਅਧਾਰ ਤੇ, ਠੀਕ ਹਨ?

ਪਿਛਲੀਆਂ ਪਰਤਾਂ ਤੋਂ ਜੋ ਪਿਛਲੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੋਂ ਸਨ।

ਪਿਛਲੀਆਂ ਲੇਅਰਾਂ ਡਿੱਗ ਜਾਣਗੀਆਂ, ਪਰ ਉਹ ਪੁਰਾਣੀ ਪਰਤ ਦਾ ਹਵਾਲਾ ਦੇਣਗੇ, ਅਤੇ ਕੀ ਉਹ ਅੱਪਡੇਟ ਵਿੱਚ ਪ੍ਰਾਪਤ ਹੋਈ ਆਖਰੀ ਲੇਅਰ ਤੋਂ ਨਵੀਆਂ ਤਸਵੀਰਾਂ ਲੈਣਗੇ?

ਆਮ ਤੌਰ 'ਤੇ, ਹਾਂ।

ਫਿਰ ਨਤੀਜੇ ਵਜੋਂ ਸਾਡੇ ਕੋਲ ਲੇਅਰਾਂ ਦੀ ਇੱਕ ਅੰਜੀਰ ਤੱਕ ਹੋਵੇਗੀ। ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਪਵੇਗੀ?

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

ਹੈਲੋ, ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਜੋਅ ਬਾਰੇ ਸਵਾਲ. ਤੁਸੀਂ ਕਿਹਾ ਸੀ ਕਿ ਗਾਹਕ ਹਰ ਕਿਸੇ ਨੂੰ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਦੇਣਾ ਚਾਹੁੰਦਾ ਸੀ। ਸਖਤੀ ਨਾਲ ਕਹਾਂ ਤਾਂ, ਜੇਕਰ ਕਿਸੇ ਵਿਅਕਤੀ ਕੋਲ ਐਕਸਪਲੇਨ ਐਨਾਲਾਈਜ਼ ਦਾ ਨਤੀਜਾ ਹੈ, ਤਾਂ ਉਹ ਡੇਟਾ ਨੂੰ ਪੀਪ ਕਰ ਸਕਦਾ ਹੈ.

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

ਨਮਸਕਾਰ ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੇਰੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਸਵਾਲ ਹੈ। ਜੇਕਰ ਕੰਪਨੀ ਸਲੈਕ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਕੀ ਹੁਣ ਇਸਦੇ ਲਈ ਕੋਈ ਬਾਈਡਿੰਗ ਹੈ, ਜਾਂ ਕੀ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਟੈਸਟ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਡੇਟਾਬੇਸ ਨਾਲ ਜੋੜਨ ਲਈ ਉਦਾਹਰਣਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਸੰਭਵ ਹੈ?

ਹੁਣ ਸਲੈਕ ਦਾ ਇੱਕ ਲਿੰਕ ਹੈ, ਭਾਵ ਕੋਈ ਹੋਰ ਮੈਸੇਂਜਰ ਨਹੀਂ ਹੈ, ਪਰ ਮੈਂ ਅਸਲ ਵਿੱਚ ਹੋਰ ਮੈਸੇਂਜਰਾਂ ਲਈ ਵੀ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ? ਤੁਸੀਂ ਜੋਏ ਤੋਂ ਬਿਨਾਂ DB ਲੈਬ ਨੂੰ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ, REST API ਦੀ ਮਦਦ ਨਾਲ ਜਾਂ ਸਾਡੇ ਪਲੇਟਫਾਰਮ ਦੀ ਮਦਦ ਨਾਲ ਜਾ ਸਕਦੇ ਹੋ ਅਤੇ ਕਲੋਨ ਬਣਾ ਸਕਦੇ ਹੋ ਅਤੇ PSQL ਨਾਲ ਜੁੜ ਸਕਦੇ ਹੋ। ਪਰ ਅਜਿਹਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਦੇਣ ਲਈ ਤਿਆਰ ਹੋ, ਕਿਉਂਕਿ ਹੁਣ ਕੋਈ ਸਕ੍ਰੀਨ ਨਹੀਂ ਹੋਵੇਗੀ।

ਮੈਨੂੰ ਇਸ ਪਰਤ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਮੈਨੂੰ ਅਜਿਹੇ ਮੌਕੇ ਦੀ ਲੋੜ ਹੈ।

ਫਿਰ ਹਾਂ, ਇਹ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

ਸਰੋਤ: www.habr.com