ਪੋਸਟਗ੍ਰੇਸ: ਬਲੋਟ, pg_repack ਅਤੇ ਮੁਲਤਵੀ ਰੁਕਾਵਟਾਂ

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

ਲੇਖ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਸਿਧਾਂਤ ਸ਼ਾਮਲ ਹੋਵੇਗਾ ਕਿ ਬਲੋਟ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਇਸ ਨਾਲ ਕਿਵੇਂ ਲੜ ਸਕਦੇ ਹੋ, ਮੁਲਤਵੀ ਰੁਕਾਵਟਾਂ ਅਤੇ pg_repack ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਵਰਤੋਂ ਵਿੱਚ ਉਹ ਸਮੱਸਿਆਵਾਂ ਲਿਆਉਂਦੇ ਹਨ।

ਇਹ ਲੇਖ ਆਧਾਰਿਤ ਲਿਖਿਆ ਗਿਆ ਹੈ ਮੇਰਾ ਭਾਸ਼ਣ PgConf.Russia 2020 'ਤੇ।

ਬਲੋਟ ਕਿਉਂ ਹੁੰਦਾ ਹੈ?

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

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

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

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

ਕਦਮ-ਦਰ-ਕਦਮ, ਕਤਾਰ ਦੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਅਤੇ ਮਿਟਾਉਣਾ, ਅਸੀਂ ਇੱਕ ਪੰਨੇ ਦੇ ਨਾਲ ਸਮਾਪਤ ਕੀਤਾ ਜਿਸ ਵਿੱਚ ਲਗਭਗ ਅੱਧਾ ਡੇਟਾ "ਕੂੜਾ" ਹੈ। ਇਹ ਡੇਟਾ ਕਿਸੇ ਵੀ ਲੈਣ-ਦੇਣ ਲਈ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ ਹੈ।

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

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

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

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

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

ਕੀ ਮੈਨੂੰ ਬਲੋਟ ਹੈ?

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

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

ਅਸੀਂ 20% ਤੱਕ, ਇੱਕ ਛੋਟਾ ਬਲੋਟ ਮੁੱਲ ਮੰਨਦੇ ਹਾਂ, ਸਵੀਕਾਰਯੋਗ ਹੈ। ਲਈ ਫਿਲਫੈਕਟਰ ਦਾ ਐਨਾਲਾਗ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਟੇਬਲ и ਸੂਚਕਾਂਕ. 50% ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ, ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

ਬਲੋਟ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਦੇ ਤਰੀਕੇ

ਪੋਸਟਗ੍ਰੇਸ ਕੋਲ ਬਕਸੇ ਦੇ ਬਾਹਰ ਬਲੋਟ ਨਾਲ ਨਜਿੱਠਣ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ, ਪਰ ਉਹ ਹਮੇਸ਼ਾ ਹਰ ਕਿਸੇ ਲਈ ਢੁਕਵੇਂ ਨਹੀਂ ਹੁੰਦੇ।

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

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

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

ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਆਟੋਵੈਕਿਊਮ ਸਥਾਪਤ ਕੀਤਾ ਹੈ, ਪਰ ਬਲੋਟ ਵਧਣਾ ਜਾਰੀ ਹੈ।

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

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

ਦੀ ਟੀਮ REINDEX ਪਿਛਲੇ ਦੋ ਦੇ ਸਮਾਨ, ਪਰ ਇੱਕ ਖਾਸ ਸੂਚਕਾਂਕ ਜਾਂ ਸਾਰਣੀ ਦੇ ਸਾਰੇ ਸੂਚਕਾਂਕ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਤਾਲੇ ਥੋੜ੍ਹੇ ਕਮਜ਼ੋਰ ਹਨ: ਟੇਬਲ 'ਤੇ ShareLock (ਸੋਧਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਪਰ ਚੋਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ) ਅਤੇ ਮੁੜ-ਬਣਾਏ ਜਾ ਰਹੇ ਸੂਚਕਾਂਕ 'ਤੇ AccessExclusiveLock (ਇਸ ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਵਾਲਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ)। ਹਾਲਾਂਕਿ, ਪੋਸਟਗ੍ਰੇਸ ਦੇ 12 ਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਇੱਕ ਪੈਰਾਮੀਟਰ ਪ੍ਰਗਟ ਹੋਇਆ ਸਮਕਾਲੀ, ਜੋ ਤੁਹਾਨੂੰ ਰਿਕਾਰਡਾਂ ਦੇ ਸਮਕਾਲੀ ਜੋੜ, ਸੋਧ, ਜਾਂ ਮਿਟਾਉਣ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਸੂਚਕਾਂਕ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

Postgres ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਨਤੀਜੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ REINDEX CONCURRENTLY ਦੇ ਸਮਾਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਇੰਡੈਕਸ ਇੱਕੋ ਸਮੇਂ ਬਣਾਓ. ਇਹ ਤੁਹਾਨੂੰ ਸਖਤ ਲਾਕਿੰਗ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ (ShareUpdateExclusiveLock, ਜੋ ਸਮਾਨਾਂਤਰ ਪੁੱਛਗਿੱਛਾਂ ਵਿੱਚ ਦਖਲ ਨਹੀਂ ਦਿੰਦਾ), ਫਿਰ ਪੁਰਾਣੇ ਸੂਚਕਾਂਕ ਨੂੰ ਇੱਕ ਨਵੇਂ ਨਾਲ ਬਦਲੋ ਅਤੇ ਪੁਰਾਣੇ ਸੂਚਕਾਂਕ ਨੂੰ ਮਿਟਾਓ। ਇਹ ਤੁਹਾਨੂੰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਦਖਲ ਦਿੱਤੇ ਬਿਨਾਂ ਇੰਡੈਕਸ ਬਲੋਟ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਵਿਚਾਰ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਜਦੋਂ ਸੂਚਕਾਂਕ ਨੂੰ ਮੁੜ ਬਣਾਉਣਾ ਹੈ ਤਾਂ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ 'ਤੇ ਇੱਕ ਵਾਧੂ ਲੋਡ ਹੋਵੇਗਾ।

ਇਸ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਸੂਚਕਾਂਕ ਲਈ "ਉੱਡੀ ਉੱਤੇ" ਬਲੌਟ ਨੂੰ ਖਤਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਹਨ, ਤਾਂ ਟੇਬਲ ਲਈ ਕੋਈ ਵੀ ਨਹੀਂ ਹੈ. ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਬਾਹਰੀ ਐਕਸਟੈਂਸ਼ਨਾਂ ਖੇਡ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ: pg_repack (ਪਹਿਲਾਂ pg_reorg), pgcompact, pgcompacttable ਅਤੇ ਹੋਰ. ਇਸ ਲੇਖ ਵਿਚ, ਮੈਂ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਨਹੀਂ ਕਰਾਂਗਾ ਅਤੇ ਸਿਰਫ pg_repack ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ, ਜੋ ਕਿ ਕੁਝ ਸੋਧਾਂ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਵਰਤਦੇ ਹਾਂ.

pg_repack ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

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

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

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

ਸਿਧਾਂਤ ਵਿੱਚ ਸਭ ਕੁਝ ਵਧੀਆ ਲੱਗਦਾ ਹੈ, ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ? ਅਸੀਂ ਬਿਨਾਂ ਲੋਡ ਅਤੇ ਲੋਡ ਦੇ ਹੇਠਾਂ pg_repack ਦੀ ਜਾਂਚ ਕੀਤੀ, ਅਤੇ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇਸਦੀ ਕਾਰਵਾਈ ਦੀ ਜਾਂਚ ਕੀਤੀ (ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, Ctrl+C ਦੀ ਵਰਤੋਂ ਕਰਕੇ)। ਸਾਰੇ ਟੈਸਟ ਸਕਾਰਾਤਮਕ ਸਨ.

ਅਸੀਂ ਖਾਣੇ ਦੀ ਦੁਕਾਨ 'ਤੇ ਗਏ - ਅਤੇ ਫਿਰ ਸਭ ਕੁਝ ਸਾਡੀ ਉਮੀਦ ਅਨੁਸਾਰ ਨਹੀਂ ਹੋਇਆ।

ਵਿਕਰੀ 'ਤੇ ਪਹਿਲਾ ਪੈਨਕੇਕ

ਪਹਿਲੇ ਕਲੱਸਟਰ 'ਤੇ ਸਾਨੂੰ ਇੱਕ ਵਿਲੱਖਣ ਪਾਬੰਦੀ ਦੀ ਉਲੰਘਣਾ ਬਾਰੇ ਇੱਕ ਤਰੁੱਟੀ ਪ੍ਰਾਪਤ ਹੋਈ:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ਇਸ ਸੀਮਾ ਵਿੱਚ ਇੱਕ ਸਵੈ-ਤਿਆਰ ਨਾਮ index_16508 ਸੀ - ਇਹ pg_repack ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਇਸਦੀ ਰਚਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਗੁਣਾਂ ਦੇ ਅਧਾਰ 'ਤੇ, ਅਸੀਂ "ਸਾਡੀ" ਰੁਕਾਵਟ ਨਿਰਧਾਰਤ ਕੀਤੀ ਹੈ ਜੋ ਇਸਦੇ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਨਿਕਲੀ ਕਿ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਮ ਸੀਮਾ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਮੁਲਤਵੀ (ਮੁਲਤਵੀ ਪਾਬੰਦੀ), i.e. ਇਸਦੀ ਤਸਦੀਕ sql ਕਮਾਂਡ ਤੋਂ ਬਾਅਦ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਅਚਾਨਕ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ।

ਮੁਲਤਵੀ ਪਾਬੰਦੀਆਂ: ਉਹਨਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਅਤੇ ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ

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

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

ਮੰਨ ਲਓ ਕਿ ਸਾਨੂੰ ਪਹਿਲੀ ਅਤੇ ਦੂਜੀ ਕਾਰਾਂ ਨੂੰ ਸਵੈਪ ਕਰਨ ਦੀ ਲੋੜ ਸੀ। ਸਿੱਧਾ ਹੱਲ ਹੈ ਪਹਿਲੇ ਮੁੱਲ ਨੂੰ ਦੂਜੇ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨਾ, ਅਤੇ ਦੂਜੇ ਨੂੰ ਪਹਿਲੇ ਵਿੱਚ:

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

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

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

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

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

ਵਿਕਲਪ ਤਿੰਨ: ਰੁਕਾਵਟ ਨੂੰ ਮੁਲਤਵੀ ਕਰੋ ਤਾਂ ਜੋ ਇਸ ਦੀ ਜਾਂਚ ਸਿਰਫ ਪ੍ਰਤੀਬੱਧਤਾ ਦੇ ਸਮੇਂ ਕੀਤੀ ਜਾ ਸਕੇ:

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

ਕਿਉਂਕਿ ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਬੇਨਤੀ ਦਾ ਤਰਕ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਵਚਨਬੱਧਤਾ ਦੇ ਸਮੇਂ ਸਾਰੇ ਮੁੱਲ ਵਿਲੱਖਣ ਹਨ, ਇਹ ਸਫਲ ਹੋਵੇਗਾ.

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

ਆਮ ਤੌਰ 'ਤੇ, ਰੁਕਾਵਟ ਦੀ ਕਿਸਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਪੋਸਟਗ੍ਰੇਸ ਕੋਲ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਗ੍ਰੈਨਿਊਲਰਿਟੀ ਦੇ ਤਿੰਨ ਪੱਧਰ ਹਨ: ਕਤਾਰ, ਲੈਣ-ਦੇਣ, ਅਤੇ ਸਮੀਕਰਨ ਪੱਧਰ।

ਸਰੋਤ: begriffs

CHECK ਅਤੇ NOT NULL ਨੂੰ ਹਮੇਸ਼ਾ ਕਤਾਰ ਪੱਧਰ 'ਤੇ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਹੋਰ ਪਾਬੰਦੀਆਂ ਲਈ, ਜਿਵੇਂ ਕਿ ਸਾਰਣੀ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਵੱਖ-ਵੱਖ ਵਿਕਲਪ ਹਨ। ਤੁਸੀਂ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ.

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

pg_repack ਦਾ ਸੁਧਾਰ

ਅਸੀਂ ਕਵਰ ਕੀਤਾ ਹੈ ਕਿ ਮੁਲਤਵੀ ਰੁਕਾਵਟਾਂ ਕੀ ਹਨ, ਪਰ ਉਹ ਸਾਡੀ ਸਮੱਸਿਆ ਨਾਲ ਕਿਵੇਂ ਸਬੰਧਤ ਹਨ? ਆਓ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਲਤੀ ਨੂੰ ਯਾਦ ਕਰੀਏ:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਸਮੱਸਿਆ ਦਾ ਸਾਰ ਚੈੱਕ ਦੀ "ਦੇਰੀ" ਵਿੱਚ ਹੈ: ਅਸਲ ਸਾਰਣੀ ਵਿੱਚ ਇਹ ਪ੍ਰਤੀਬੱਧਤਾ ਦੇ ਸਮੇਂ ਵਾਪਰਦਾ ਹੈ, ਅਤੇ ਨਵੀਂ ਸਾਰਣੀ ਵਿੱਚ ਜਦੋਂ sql ਕਮਾਂਡ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਜਾਂਚਾਂ ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: ਜਾਂ ਤਾਂ ਹਮੇਸ਼ਾ ਦੇਰੀ ਨਾਲ, ਜਾਂ ਹਮੇਸ਼ਾ ਤੁਰੰਤ।

ਤਾਂ ਸਾਡੇ ਕੋਲ ਕਿਹੜੇ ਵਿਚਾਰ ਸਨ?

ਮੁਲਤਵੀ ਦੇ ਸਮਾਨ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਓ

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

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

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

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

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

ਇਹ ਵਿਚਾਰ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ। ਉਸ ਸਮੇਂ, ਅਸੀਂ ਦੋ ਹੋਰ ਹੱਲ ਵੇਖੇ: ਮੁਲਤਵੀ ਰੁਕਾਵਟਾਂ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਸਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ, ਜਾਂ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ pg_repack ਨੂੰ "ਸਿੱਖਾਓ"। ਅਸੀਂ ਦੂਜਾ ਚੁਣਿਆ.

ਨਵੀਂ ਸਾਰਣੀ ਵਿੱਚ ਸੂਚਕਾਂਕ ਨੂੰ ਮੂਲ ਸਾਰਣੀ ਤੋਂ ਮੁਲਤਵੀ ਪਾਬੰਦੀਆਂ ਨਾਲ ਬਦਲੋ

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

ਸਾਡੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਲਿਖਿਆ:

• ਇੱਕ ਮੁਲਤਵੀ ਰੁਕਾਵਟ ਅਤੇ ਇੱਕ ਰਿਕਾਰਡ ਦੇ ਨਾਲ ਸਾਰਣੀ;
• ਇੱਕ ਲੂਪ ਵਿੱਚ ਡੇਟਾ ਪਾਓ ਜੋ ਮੌਜੂਦਾ ਰਿਕਾਰਡ ਨਾਲ ਟਕਰਾਅ ਕਰਦਾ ਹੈ;
• ਇੱਕ ਅੱਪਡੇਟ ਕਰੋ - ਡੇਟਾ ਹੁਣ ਵਿਵਾਦ ਨਹੀਂ ਕਰੇਗਾ;
• ਤਬਦੀਲੀਆਂ ਕਰੋ।

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

pg_repack ਦਾ ਅਸਲ ਸੰਸਕਰਣ ਹਮੇਸ਼ਾਂ ਪਹਿਲੀ ਸੰਮਿਲਿਤ ਕਰਨ 'ਤੇ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਸੋਧਿਆ ਹੋਇਆ ਸੰਸਕਰਣ ਗਲਤੀਆਂ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਮਹਾਨ।

ਅਸੀਂ ਉਤਪਾਦਨ 'ਤੇ ਜਾਂਦੇ ਹਾਂ ਅਤੇ ਲੌਗ ਟੇਬਲ ਤੋਂ ਇੱਕ ਨਵੇਂ ਵਿੱਚ ਡੇਟਾ ਦੀ ਨਕਲ ਕਰਨ ਦੇ ਉਸੇ ਪੜਾਅ 'ਤੇ ਦੁਬਾਰਾ ਇੱਕ ਗਲਤੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ਕਲਾਸਿਕ ਸਥਿਤੀ: ਹਰ ਚੀਜ਼ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਨਹੀਂ?!

APPLY_COUNT ਅਤੇ ਦੋ ਬੈਚਾਂ ਦਾ ਜੰਕਸ਼ਨ

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

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

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

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

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

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

ਬੈਚਿੰਗ ਤੋਂ ਇਨਕਾਰ

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

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

ਇਸ ਲਈ, ਅਸੀਂ ਪਹਿਲੇ ਵਿਕਲਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਕਿਉਂਕਿ ਇਹ ਸੌਖਾ ਹੈ. ਪਹਿਲਾਂ, ਇਹ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਸੀ ਕਿ ਕੀ ਇੱਕ ਲੰਮਾ ਲੈਣ-ਦੇਣ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਹੋਵੇਗੀ. ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਟੇਬਲ ਤੋਂ ਨਵੇਂ ਵਿੱਚ ਡੇਟਾ ਦਾ ਮੁੱਖ ਟ੍ਰਾਂਸਫਰ ਵੀ ਇੱਕ ਲੰਬੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਵਾਲ "ਅਸੀਂ ਇਸ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਕਿੰਨਾ ਵਧਾਵਾਂਗੇ?" ਵਿੱਚ ਬਦਲ ਗਿਆ। ਪਹਿਲੇ ਲੈਣ-ਦੇਣ ਦੀ ਮਿਆਦ ਮੁੱਖ ਤੌਰ 'ਤੇ ਟੇਬਲ ਦੇ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਨਵੇਂ ਦੀ ਮਿਆਦ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਦੌਰਾਨ ਸਾਰਣੀ ਵਿੱਚ ਕਿੰਨੀਆਂ ਤਬਦੀਲੀਆਂ ਇਕੱਠੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਯਾਨੀ. ਲੋਡ ਦੀ ਤੀਬਰਤਾ 'ਤੇ. pg_repack ਰਨ ਘੱਟੋ-ਘੱਟ ਸੇਵਾ ਲੋਡ ਦੇ ਸਮੇਂ ਦੌਰਾਨ ਹੋਇਆ, ਅਤੇ ਟੇਬਲ ਦੇ ਅਸਲ ਆਕਾਰ ਦੇ ਮੁਕਾਬਲੇ ਬਦਲਾਵਾਂ ਦੀ ਮਾਤਰਾ ਬਹੁਤ ਘੱਟ ਸੀ। ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਨਵੇਂ ਲੈਣ-ਦੇਣ ਦੇ ਸਮੇਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੇ ਹਾਂ (ਤੁਲਨਾ ਲਈ, ਔਸਤਨ ਇਹ 1 ਘੰਟਾ ਅਤੇ 2-3 ਮਿੰਟ ਹੈ)।

ਪ੍ਰਯੋਗ ਸਕਾਰਾਤਮਕ ਸਨ. ਉਤਪਾਦਨ 'ਤੇ ਵੀ ਲਾਂਚ ਕਰੋ. ਸਪਸ਼ਟਤਾ ਲਈ, ਇੱਥੇ ਚੱਲਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਡੇਟਾਬੇਸ ਦੇ ਆਕਾਰ ਦੇ ਨਾਲ ਇੱਕ ਤਸਵੀਰ ਹੈ:

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

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

ਸਿੱਟਾ

ਅਸੀਂ ਆਪਣੇ ਤਜ਼ਰਬੇ ਦੇ ਆਧਾਰ 'ਤੇ ਕੀ ਸਿਫ਼ਾਰਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ:

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

ਸਰੋਤ: www.habr.com