ਪਿਆਰੇ ਮਿਟਾਓ। ਨਿਕੋਲੇ ਸਮੋਖਵਾਲਵ (ਪੋਸਟਗਰੇਸ.ਏ.ਆਈ.)

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

ਵੀਡੀਓ:

• ਮੈਂ ਪਹਿਲੇ ਸਾਲ ਤੋਂ, ਭਾਵ 2007 ਤੋਂ ਹਾਈਲੋਡ ਪ੍ਰੋਗਰਾਮ ਕਮੇਟੀ ਵਿੱਚ ਹਾਂ।

• ਅਤੇ ਮੈਂ 2005 ਤੋਂ ਪੋਸਟਗ੍ਰੇਸ ਨਾਲ ਰਿਹਾ ਹਾਂ। ਕਈ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ।

• RuPostges ਦੇ ਨਾਲ ਗਰੁੱਪ ਵੀ 2007 ਤੋਂ।

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

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

https://postgres.ai/ ਮੇਰੀ ਕੰਪਨੀ ਹੈ। ਅਸੀਂ ਸਵੈਚਲਿਤ ਕਾਰਜਾਂ ਦੇ ਕਾਰੋਬਾਰ ਵਿੱਚ ਹਾਂ ਜੋ ਵਿਕਾਸ ਦੀ ਮੰਦੀ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ।

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

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

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

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

ਜੋ ਪੈਸੇ ਗਿਣ ਸਕਦੇ ਹਨ ਉਹ ਦੋ ਚੀਜ਼ਾਂ ਚਾਹੁੰਦੇ ਹਨ। ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਅਸੀਂ ਮਿਟਾ ਦੇਈਏ, ਇਸ ਲਈ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

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

ਆਮ ਤੌਰ 'ਤੇ, ਕੰਮ ਕੁਝ ਸਾਰਣੀ ਵਿੱਚ ਖਾਸ ਚੀਜ਼ਾਂ, ਖਾਸ ਲਾਈਨਾਂ ਨੂੰ ਮਿਟਾਉਣਾ ਆਟੋਮੈਟਿਕ ਕਰਨਾ ਹੈ.

ਅਤੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਅਜਿਹੀ ਬੇਨਤੀ ਹੈ, ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਅੱਜ ਗੱਲ ਕਰਾਂਗੇ, ਯਾਨੀ ਕੂੜਾ ਹਟਾਉਣ ਬਾਰੇ।

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

ਡਾਟਾਬੇਸ ਵਧਦਾ ਅਤੇ ਵਧਦਾ ਹੈ. ਰੋਜ਼ਾਨਾ DELETE ਥੋੜਾ ਹੋਰ ਹੌਲੀ-ਹੌਲੀ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

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

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

ਉਸਨੇ ਡੇਵ 'ਤੇ, ਸਟੇਜਿੰਗ 'ਤੇ ਜਾਂਚ ਕੀਤੀ - ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਉਸ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਇਕੱਠਾ ਹੋਇਆ ਹੈ. ਉਸਨੇ ਹਰ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕੀਤੀ.

ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ? ਫਿਰ ਸਾਡੇ ਲਈ ਸਭ ਕੁਝ ਟੁੱਟ ਜਾਂਦਾ ਹੈ. ਇਹ ਇਸ ਲਈ ਡਿੱਗਦਾ ਹੈ ਕਿ ਕਿਸੇ ਸਮੇਂ ਸਭ ਕੁਝ ਹੇਠਾਂ ਡਿੱਗ ਜਾਂਦਾ ਹੈ. ਹਰ ਕੋਈ ਸਦਮੇ ਵਿੱਚ ਹੈ, ਕੋਈ ਨਹੀਂ ਸਮਝ ਰਿਹਾ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਅਤੇ ਫਿਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਮਾਮਲਾ ਇਸ DELETE ਵਿੱਚ ਸੀ।

ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ? ਇੱਥੇ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ. ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ?

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

• ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਕੁਝ ਗਲਤ ਚੈੱਕ ਕੀਤਾ ਹੋਵੇ।

• ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਹਾਰਡਵੇਅਰ ਪੁਰਾਣਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇਸ ਅਧਾਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

• ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਕੁਝ ਗਲਤ ਹੋਵੇ।

• ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕੰਮ ਦੇ ਸੰਗਠਨ ਵਿੱਚ ਕੁਝ ਗਲਤੀਆਂ ਹੋਣ ਅਤੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਨੂੰ ਬਰਖਾਸਤ ਕਰਨ ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਲੋਕਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ?

ਕੋਈ DBA ਜਾਂਚ ਨਹੀਂ ਸੀ। ਜੇ ਕੋਈ ਡੀਬੀਏ ਹੁੰਦਾ, ਤਾਂ ਉਹ ਇਹ ਕਈ ਮਿਲੀਅਨ ਲਾਈਨਾਂ ਵੇਖਦਾ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਪ੍ਰਯੋਗ ਦੇ ਵੀ ਕਹਿੰਦਾ: "ਉਹ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ." ਮੰਨ ਲਓ ਜੇਕਰ ਇਹ ਕੋਡ GitLab, GitHub ਵਿੱਚ ਹੁੰਦਾ ਅਤੇ ਇੱਕ ਕੋਡ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਹੁੰਦੀ ਅਤੇ ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਸੀ ਕਿ DBA ਦੀ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਿਨਾਂ ਇਹ ਕਾਰਵਾਈ ਪ੍ਰੋਡ 'ਤੇ ਹੋਵੇਗੀ, ਤਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ DBA ਕਹੇਗਾ: “ਇਹ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। "

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

http://bit.ly/nancy-hl2018-2

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

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

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

ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਾਡਾ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਖਰਾਬ ਹੈ? ਦੇਖਿਆ ਤਾਂ ਲੇਟੈਂਸੀ ਛਾਲ ਮਾਰ ਗਈ। ਅਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਉਪਯੋਗਤਾ 100% ਹੈ। ਬੇਸ਼ੱਕ, ਜੇ ਇਹ ਆਧੁਨਿਕ NVMe ਡਰਾਈਵਾਂ ਸਨ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਸਾਡੇ ਲਈ ਬਹੁਤ ਸੌਖਾ ਹੋਵੇਗਾ. ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਤੋਂ ਲੇਟ ਨਾ ਹੋਵਾਂ.

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਬੱਦਲ ਹਨ, ਤਾਂ ਉੱਥੇ ਅੱਪਗਰੇਡ ਆਸਾਨੀ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਨਵੇਂ ਹਾਰਡਵੇਅਰ 'ਤੇ ਨਵੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤਿਆਰ ਕੀਤੀਆਂ। ਸਵਿੱਚਓਵਰ ਅਤੇ ਸਭ ਠੀਕ ਹੈ. ਪਰੈਟੀ ਆਸਾਨ.

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

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

ਪੋਸਟਗ੍ਰੇਸ ਵਿੱਚ ਸੈਟਿੰਗਾਂ ਪਿੱਛੇ ਹਨ. ਉਹ 10-15 ਸਾਲ ਪੁਰਾਣੇ ਡੇਟਾ ਅਤੇ ਲੈਣ-ਦੇਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ। ਅਤੇ ਚੈਕਪੁਆਇੰਟ ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ ਹੈ.

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

ਇਸਦਾ ਮਤਲੱਬ ਕੀ ਹੈ? ਉੱਥੇ ਦੋ ਸੈਟਿੰਗ ਹਨ. ਚੈਕਪੁਆਇੰਟ ਟਾਈਮਆਊਟ ਦੁਆਰਾ ਆ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 10 ਮਿੰਟ 'ਤੇ। ਜਾਂ ਇਹ ਉਦੋਂ ਆ ਸਕਦਾ ਹੈ ਜਦੋਂ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਭਰਿਆ ਗਿਆ ਹੋਵੇ।

ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ max_wal_saze 1 ਗੀਗਾਬਾਈਟ 'ਤੇ ਸੈੱਟ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਅਸਲ ਵਿੱਚ 300-400 ਮੈਗਾਬਾਈਟ ਦੇ ਬਾਅਦ Postgres ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ. ਤੁਸੀਂ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਬਦਲ ਦਿੱਤਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਜਾਂਚ ਪੁਆਇੰਟ ਹੁੰਦੀ ਹੈ.

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

ਅਤੇ ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਇਹ ਘੱਟ ਵਾਰ ਆਉਂਦਾ ਹੈ। ਭਾਵ, ਅਸੀਂ max_wal_size ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਇਹ ਘੱਟ ਵਾਰ ਆਵੇਗਾ।

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

ਇਸ ਅਨੁਸਾਰ, ਅਸੀਂ ਡੇਟਾਬੇਸ 'ਤੇ ਪ੍ਰਯੋਗਾਂ ਦੀ ਦੋ ਲੜੀ ਕਰ ਰਹੇ ਹਾਂ।

ਪਹਿਲੀ ਲੜੀ - ਅਸੀਂ max_wal_size ਨੂੰ ਬਦਲਦੇ ਹਾਂ। ਅਤੇ ਅਸੀਂ ਇੱਕ ਵਿਸ਼ਾਲ ਕਾਰਵਾਈ ਕਰ ਰਹੇ ਹਾਂ। ਪਹਿਲਾਂ, ਅਸੀਂ ਇਸਨੂੰ 1 ਗੀਗਾਬਾਈਟ ਦੀ ਡਿਫੌਲਟ ਸੈਟਿੰਗ 'ਤੇ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਅਸੀਂ ਲੱਖਾਂ ਲਾਈਨਾਂ ਦਾ ਇੱਕ ਵਿਸ਼ਾਲ DELETE ਕਰਦੇ ਹਾਂ।

ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਸਾਡੇ ਲਈ ਕਿੰਨਾ ਔਖਾ ਹੈ। ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਡਿਸਕ IO ਬਹੁਤ ਖਰਾਬ ਹੈ। ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਕਿੰਨੀਆਂ WALs ਤਿਆਰ ਕੀਤੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਦੇਖਦੇ ਹਾਂ ਕਿ ਕਿੰਨੀ ਵਾਰ ਚੈਕਿੰਗ ਹੋਈ। ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਹ ਚੰਗਾ ਨਹੀਂ ਹੈ।

ਅੱਗੇ ਅਸੀਂ max_wal_size ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ। ਅਸੀਂ ਦੁਹਰਾਉਂਦੇ ਹਾਂ. ਅਸੀਂ ਵਧਾਉਂਦੇ ਹਾਂ, ਅਸੀਂ ਦੁਹਰਾਉਂਦੇ ਹਾਂ. ਅਤੇ ਇਸ ਲਈ ਕਈ ਵਾਰ. ਸਿਧਾਂਤ ਵਿੱਚ, 10 ਅੰਕ ਚੰਗੇ ਹਨ, ਜਿੱਥੇ 1, 2, 4, 8 ਗੀਗਾਬਾਈਟ. ਅਤੇ ਅਸੀਂ ਇੱਕ ਖਾਸ ਪ੍ਰਣਾਲੀ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਦੇਖਦੇ ਹਾਂ. ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇੱਥੇ ਉਪਕਰਨ ਔਨ ਪ੍ਰੋਡ ਵਰਗਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਇੱਕੋ ਜਿਹੀਆਂ ਡਿਸਕਾਂ, ਇੱਕੋ ਜਿਹੀ ਮੈਮੋਰੀ, ਅਤੇ ਉਹੀ ਪੋਸਟਗ੍ਰੇਸ ਸੈਟਿੰਗਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

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

ਰੂਸੀ ਵਿੱਚ ਚੈਕਪੁਆਇੰਟ ਚੈਕਪੁਆਇੰਟ ਹਨ।

ਉਦਾਹਰਨ: ਸੂਚਕਾਂਕ ਦੁਆਰਾ ਕਈ ਮਿਲੀਅਨ ਕਤਾਰਾਂ ਨੂੰ ਮਿਟਾਓ, ਪੰਨਿਆਂ ਵਿੱਚ ਕਤਾਰਾਂ "ਖਿੜੀਆਂ" ਗਈਆਂ ਹਨ।

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

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

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

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

ਅਜਿਹਾ ਕਿਉਂ ਹੈ

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

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

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

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

ਫਾਰਵਰਡ ਲੌਗ ਦੇ WAL ਨੂੰ ਲਿਖਣ ਦਾ ਵਿਵਹਾਰ ਅਜਿਹਾ ਹੈ ਕਿ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਇੱਕ ਚੈਕਪੁਆਇੰਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ ਪੰਨਾ ਬਦਲਦੇ ਹਾਂ, ਤਾਂ ਪੂਰਾ ਪੰਨਾ, ਭਾਵ, ਸਾਰੇ 8 ਕਿਲੋਬਾਈਟ, ਫਾਰਵਰਡ ਲੌਗ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਅਸੀਂ ਸਿਰਫ ਬਦਲਿਆ ਹੈ. ਲਾਈਨ, ਜਿਸਦਾ ਭਾਰ 100 ਬਾਈਟ ਹੈ। ਅਤੇ ਸਾਨੂੰ ਪੂਰਾ ਪੰਨਾ ਲਿਖਣਾ ਪਵੇਗਾ।

ਬਾਅਦ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਖਾਸ ਟੂਪਲ ਹੋਵੇਗਾ, ਪਰ ਪਹਿਲੀ ਵਾਰ ਅਸੀਂ ਸਭ ਕੁਝ ਲਿਖਦੇ ਹਾਂ।

ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਜੇਕਰ ਚੈਕਪੁਆਇੰਟ ਦੁਬਾਰਾ ਹੋਇਆ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਤੋਂ ਸਭ ਕੁਝ ਸ਼ੁਰੂ ਕਰਨਾ ਪਵੇਗਾ ਅਤੇ ਪੂਰੇ ਪੰਨੇ ਨੂੰ ਧੱਕਣਾ ਪਵੇਗਾ. ਵਾਰ-ਵਾਰ ਚੈਕਪੁਆਇੰਟਾਂ ਦੇ ਨਾਲ, ਜਦੋਂ ਅਸੀਂ ਇੱਕੋ ਪੰਨਿਆਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਾਂ, ਤਾਂ full_page_writes = on ਹੋ ਸਕਦਾ ਹੈ ਨਾਲੋਂ ਵੱਧ ਹੋਵੇਗਾ, ਭਾਵ ਅਸੀਂ ਹੋਰ WAL ਤਿਆਰ ਕਰਦੇ ਹਾਂ। ਹੋਰ ਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਆਰਕਾਈਵ, ਡਿਸਕ ਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

ਅਤੇ, ਇਸ ਅਨੁਸਾਰ, ਸਾਡੇ ਕੋਲ ਦੋ ਫਾਲਤੂਤਾ ਹਨ.

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

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

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

ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਹ ਇਸ ਉਪਕਰਣ 'ਤੇ ਕਿੰਨਾ ਚਿਰ ਚੜ੍ਹੇਗਾ, ਯਾਨੀ ਕਿ ਇਹ ਇਸ ਮਾੜੀ ਸਥਿਤੀ ਵਿੱਚ ਕਿੰਨਾ ਕੁ REDO ਕਰੇਗਾ।

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

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

ਅਤੇ ਇੱਥੇ ਇੱਕ ਦਿਲਚਸਪ ਬਿੰਦੂ ਹੈ. ਸਾਡੇ ਕੋਲ ਕਾਨਫਰੰਸ ਵਿਚ ਪੈਟਰੋਨੀ ਬਾਰੇ ਕੁਝ ਰਿਪੋਰਟਾਂ ਹਨ. ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤ ਰਹੇ ਹੋ. ਇਹ Postgres ਲਈ ਇੱਕ ਆਟੋਫੇਲਓਵਰ ਹੈ। GitLab ਅਤੇ Data Egret ਨੇ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ।

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

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

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

ਦੁਹਰਾਓ ਕਰਨ ਲਈ, ਉਦਾਹਰਨ ਲਈ, max_wal_size =1, 8, ਤੁਹਾਨੂੰ ਪੁੰਜ ਕਾਰਵਾਈ ਨੂੰ ਕਈ ਵਾਰ ਦੁਹਰਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਬਣਾਇਆ ਹੈ। ਅਤੇ ਉਸੇ ਅਧਾਰ 'ਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਭ ਕੁਝ ਮਿਟਾ ਦਿੱਤਾ ਹੈ. ਮੈਂ ਕੀ ਕਰਾਂ?

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

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

ROLLBACK ਨਾਲ ਇਹ DELETE ਚੈੱਕਪੁਆਇੰਟ ਟਿਊਨਿੰਗ ਲਈ ਆਦਰਸ਼ ਹੈ, ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਸਹੀ ਢੰਗ ਨਾਲ ਤੈਨਾਤ ਡਾਟਾਬੇਸ ਲੈਬਾਂ ਨਾ ਹੋਣ।

ਅਸੀਂ ਇੱਕ ਕਾਲਮ "i" ਨਾਲ ਇੱਕ ਪਲੇਟ ਬਣਾਈ. Postgres ਵਿੱਚ ਉਪਯੋਗਤਾ ਕਾਲਮ ਹਨ। ਉਹ ਅਦਿੱਖ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਖਾਸ ਤੌਰ 'ਤੇ ਨਹੀਂ ਮੰਗਿਆ ਜਾਂਦਾ. ਇਹ ਹਨ: ctid, xmid, xmax.

Ctid ਇੱਕ ਭੌਤਿਕ ਪਤਾ ਹੈ। ਜ਼ੀਰੋ ਪੰਨਾ, ਪੰਨੇ ਵਿੱਚ ਪਹਿਲਾ ਟੂਪਲ।

ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਰੂਲਬੈਕ ਤੋਂ ਬਾਅਦ ਟੂਪਲ ਉਸੇ ਥਾਂ 'ਤੇ ਰਿਹਾ। ਯਾਨੀ ਅਸੀਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ, ਇਹ ਉਸੇ ਤਰ੍ਹਾਂ ਦਾ ਵਿਵਹਾਰ ਕਰੇਗਾ। ਇਹ ਮੁੱਖ ਗੱਲ ਹੈ।

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

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

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

ਤੋੜਨਾ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ?

• ਜੇਕਰ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਡਿਸਕ ਸਖ਼ਤ ਹੈ, ਤਾਂ ਆਓ ਇਸਨੂੰ ਹੌਲੀ ਕਰੀਏ। ਅਤੇ ਜੇ ਅਸੀਂ ਟੁੱਟ ਗਏ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਵਿਰਾਮ ਜੋੜ ਸਕਦੇ ਹਾਂ, ਅਸੀਂ ਥ੍ਰੋਟਲਿੰਗ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦੇ ਹਾਂ.

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

https://postgres.ai/products/joe/

ਇਹ ਦਿਲਚਸਪ ਹੈ। ਮੈਂ ਅਕਸਰ ਦੇਖਦਾ ਹਾਂ ਕਿ ਡਿਵੈਲਪਰ ਪੁੱਛਦੇ ਹਨ: "ਮੈਨੂੰ ਕਿਹੜਾ ਪੈਕ ਆਕਾਰ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ?".

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

ਮੇਰੇ ਕੋਲ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਨਿਯਮ ਹੈ: ਜਿੰਨਾ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਲਓ, ਪਰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਐਗਜ਼ੀਕਿਊਟੇਬਲਜ਼ ਤੋਂ ਵੱਧ ਨਾ ਜਾਓ।

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

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

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

ਤਰੀਕੇ ਨਾਲ, ਜੋ ਵੀ ਮੈਂ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਉਹ ਸਿਰਫ਼ ਮਿਟਾਉਣ ਬਾਰੇ ਹੀ ਨਹੀਂ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਇਆ ਹੈ, ਇਹ ਡੇਟਾ 'ਤੇ ਕੋਈ ਵੀ ਬਲਕ ਓਪਰੇਸ਼ਨ ਹਨ।

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

ਵਿਭਾਗੀਕਰਨ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਕੀ ਹਨ? ਮੈਂ 3 ਵੱਖ-ਵੱਖ ਵਿਭਾਗੀਕਰਨ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਦੇਖਦਾ ਹਾਂ ਜੋ ਪੈਕ 'ਤੇ ਡਿਵੈਲਪਰ ਵਰਤ ਰਹੇ ਹਨ।

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

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

ਪਹਿਲੀ ਰਣਨੀਤੀ ਵਿੱਚ, ਵੀ, ਤਰੀਕੇ ਨਾਲ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਈ ਥਰਿੱਡਾਂ ਵਿੱਚ ਕਰ ਸਕਦੇ ਹੋ. ਇਹ ਔਖਾ ਨਹੀਂ ਹੈ।

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

ਆਮ ਤੌਰ 'ਤੇ, ਸਿਰਫ਼ ਇੰਡੈਕਸ ਸਕੈਨ ਇੰਡੈਕਸ ਸਕੈਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।

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

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

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

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

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

ਲੰਬੇ ਲੈਣ-ਦੇਣ https://gitlab.com/snippets/1890447

ਬਲੌਕ ਕੀਤਾ ਆਟੋਵੈਕਿਊਮ - https://gitlab.com/snippets/1889668

ਬਲਾਕਿੰਗ ਮੁੱਦਾ - https://gitlab.com/snippets/1890428

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

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

ਜੇ ਕੋਈ ਵੱਡਾ IO ਹੈ, ਤਾਂ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਚੰਗਾ ਨਹੀਂ ਹੈ.

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

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

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

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

ਕਈ ਵਾਰ ਇਹ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਜੋੜ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ।

ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇੱਥੇ ਮੁੱਖ ਗਲਤੀ ਸੰਗਠਨਾਤਮਕ ਹੈ. ਇਹ ਸੰਗਠਨਾਤਮਕ ਹੈ, ਕਿਉਂਕਿ ਤਕਨੀਕ ਨਹੀਂ ਖਿੱਚਦੀ. ਇਹ ਨੰਬਰ 2 ਹੈ - ਉਹਨਾਂ ਨੇ ਗਲਤ ਜਗ੍ਹਾ 'ਤੇ ਜਾਂਚ ਕੀਤੀ.

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

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

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

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

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

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

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

ਉਦਾਹਰਨ: 5 ਟੈਰਾਬਾਈਟ ਡੇਟਾਬੇਸ, 30 ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਵਿੱਚ ਇੱਕ ਕਾਪੀ ਪ੍ਰਾਪਤ ਕਰਨਾ। ਅਤੇ ਇਹ ਆਕਾਰ 'ਤੇ ਵੀ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਯਾਨੀ ਕਿ, ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਕਿੰਨੇ ਟੈਰਾਬਾਈਟ ਹਨ.

ਅੱਜ ਤੁਸੀਂ ਜਾ ਸਕਦੇ ਹੋ postgres.ai ਅਤੇ ਸਾਡੇ ਸਾਧਨਾਂ ਵਿੱਚ ਖੋਦਣ। ਤੁਸੀਂ ਇਹ ਦੇਖਣ ਲਈ ਰਜਿਸਟਰ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਉੱਥੇ ਕੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਬੋਟ ਨੂੰ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਮੁਫ਼ਤ ਹੈ. ਲਿਖੋ।

ਤੁਹਾਡੇ ਸਵਾਲ

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

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

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

ਜੇਕਰ ਤੁਸੀਂ GitHub 'ਤੇ pg_repack ਨੂੰ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਉੱਥੇ, ਜਦੋਂ ਇੱਕ ID ਨੂੰ int 4 ਤੋਂ int 8 ਵਿੱਚ ਬਦਲਣ ਦਾ ਕੰਮ ਸੀ, ਤਾਂ ਉੱਥੇ pg_repack ਨੂੰ ਖੁਦ ਵਰਤਣ ਦਾ ਵਿਚਾਰ ਸੀ. ਇਹ ਵੀ ਸੰਭਵ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਹੈਕ ਦਾ ਇੱਕ ਬਿੱਟ ਹੈ, ਪਰ ਇਹ ਇਸ ਲਈ ਵੀ ਕੰਮ ਕਰੇਗਾ. ਤੁਸੀਂ ਉਸ ਟਰਿੱਗਰ ਵਿੱਚ ਦਖਲ ਦੇ ਸਕਦੇ ਹੋ ਜੋ pg_repack ਵਰਤਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਕਹਿ ਸਕਦਾ ਹੈ: "ਸਾਨੂੰ ਇਸ ਡੇਟਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ", ਭਾਵ ਅਸੀਂ ਸਿਰਫ ਉਹੀ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਫਿਰ ਉਹ ਸਿਰਫ ਸਵਿੱਚ ਕਰਦਾ ਹੈ ਅਤੇ ਬੱਸ.

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

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

ਮੈਂ MySQL ਦੀ ਦੁਨੀਆ ਤੋਂ ਥੋੜ੍ਹਾ ਜਿਹਾ ਹਾਂ, ਇਸ ਲਈ ਮੈਂ ਸੁਣਨ ਲਈ ਆਇਆ ਹਾਂ. ਅਤੇ ਅਸੀਂ ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ.

ਪਰ ਇਹ ਤਾਂ ਹੀ ਹੈ ਜੇਕਰ ਸਾਡੇ ਕੋਲ 90% ਹੈ। ਜੇ ਸਾਡੇ ਕੋਲ 5% ਹੈ, ਤਾਂ ਇਸਦਾ ਉਪਯੋਗ ਕਰਨਾ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ.

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਜੇਕਰ ਉਤਪਾਦ ਦੀ ਪੂਰੀ ਕਾਪੀ ਬਣਾਉਣ ਲਈ ਕੋਈ ਸਰੋਤ ਨਹੀਂ ਹਨ, ਤਾਂ ਕੀ ਲੋਡ ਜਾਂ ਆਕਾਰ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਕੋਈ ਐਲਗੋਰਿਦਮ ਜਾਂ ਫਾਰਮੂਲਾ ਹੈ?

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

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

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

ਸੂਚਕਾਂਕ ਨਾਲ ਕੀਤਾ।

ਮੈਂ ਇਹ ਮੰਨ ਸਕਦਾ ਹਾਂ ਕਿ ਉਹੀ ਚੈਕਪੁਆਇੰਟ ਟਿਊਨਿੰਗ ਆਟੋਮੈਟਿਕ ਹੋ ਸਕਦੀ ਹੈ. ਕਿਸੇ ਦਿਨ ਇਹ ਹੋ ਸਕਦਾ ਹੈ. ਪਰ ਫਿਰ ਮੈਂ ਅਸਲ ਵਿੱਚ ਸਵਾਲ ਨੂੰ ਨਹੀਂ ਸਮਝਦਾ.

ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਵਿਕਾਸ ਦਾ ਅਜਿਹਾ ਕੋਈ ਵੈਕਟਰ ਹੈ ਜੋ ਇਧਰ-ਉਧਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਥੇ ਤੁਹਾਡਾ ਸਮਾਨਾਂਤਰ ਚਲਦਾ ਹੈ? ਉਹ. ਕੀ ਉਨ੍ਹਾਂ ਨੇ ਅਜੇ ਤੱਕ ਇਸ ਬਾਰੇ ਨਹੀਂ ਸੋਚਿਆ?

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

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

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

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

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

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

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

ਪੋਸਟਗ੍ਰੇਸ ਵਿੱਚ ਆਟੋਵੈਕਿਊਮ ਆਪਣੇ ਆਪ ਹੀ ਇਹੀ ਕਰਦਾ ਹੈ।

ਓਹ, ਕੀ ਉਹ ਇਹ ਕਰਦਾ ਹੈ?

ਆਟੋਵੈਕਿਊਮ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲਾ ਹੈ।

ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

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

ਬੇਸ਼ੱਕ ਹੈ.

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

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

ਸਰੋਤ: www.habr.com