ਜਾਵਾ ਡਿਵੈਲਪਰ ਦੀ ਨਜ਼ਰ ਦੁਆਰਾ PostgreSQL ਵਿੱਚ ਸੂਚਕਾਂਕ ਦੀ ਸਿਹਤ

ਹੈਲੋ

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

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

ਬੇਦਾਅਵਾ

PostgreSQL ਦਾ ਮੁੱਖ ਸੰਸਕਰਣ ਜਿਸ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰਦਾ ਹਾਂ 10 ਹੈ. ਮੇਰੇ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਸਾਰੇ SQL ਸਵਾਲਾਂ ਦੀ ਵੀ ਸੰਸਕਰਣ 11 'ਤੇ ਜਾਂਚ ਕੀਤੀ ਗਈ ਹੈ। ਘੱਟੋ-ਘੱਟ ਸਮਰਥਿਤ ਸੰਸਕਰਣ 9.6 ਹੈ।

prehistory

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

ਸਮੱਸਿਆ ਇੱਕ - ਡਿਫੌਲਟ ਸੰਰਚਨਾ

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

ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਮੇਨਟੇਨੈਂਸ_ਵਰਕ_ਮੇਮ ਡਿਫਾਲਟ 64 MB ਸੀ, ਅਤੇ temp_file_limit 2 GB ਦੇ ਆਸ-ਪਾਸ ਕੁਝ - ਸਾਡੇ ਕੋਲ ਵੱਡੀ ਟੇਬਲ 'ਤੇ ਇੰਡੈਕਸ ਬਣਾਉਣ ਲਈ ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ।

ਇਸ ਲਈ, ਵਿੱਚ pg-ਇੰਡੈਕਸ-ਸਿਹਤ ਮੈਂ ਇੱਕ ਲੜੀ ਇਕੱਠੀ ਕੀਤੀ ਕੁੰਜੀ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਉਹ ਪੈਰਾਮੀਟਰ ਜੋ ਹਰੇਕ ਡੇਟਾਬੇਸ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਸਮੱਸਿਆ ਦੋ - ਡੁਪਲੀਕੇਟ ਸੂਚਕਾਂਕ

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

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

ਸਮੱਸਿਆ ਤਿੰਨ - ਸੂਚਕਾਂਕ ਨੂੰ ਕੱਟਣਾ

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

ਸਮੱਸਿਆ ਚਾਰ - ਸੂਚਕਾਂਕ ਤੋਂ ਬਿਨਾਂ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀਆਂ

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

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

delete from <table> where id in (…)

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

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

ਸਮੱਸਿਆ ਪੰਜ - ਸੂਚਕਾਂਕ ਵਿੱਚ ਨਲ ਮੁੱਲ

ਮੂਲ ਰੂਪ ਵਿੱਚ, Postgres ਵਿੱਚ btree ਸੂਚਕਾਂਕ ਵਿੱਚ ਨਲ ਮੁੱਲ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੀ ਆਮ ਤੌਰ 'ਤੇ ਉੱਥੇ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ, ਮੈਂ ਪੂਰੀ ਲਗਨ ਨਾਲ ਇਹਨਾਂ ਨਲਸ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹਾਂ (ਡਾਇਗਨੌਸਟਿਕਸ indexes_with_null_values), ਕਿਸਮ ਦੁਆਰਾ ਰੱਦ ਕਰਨ ਯੋਗ ਕਾਲਮਾਂ 'ਤੇ ਅੰਸ਼ਕ ਸੂਚਕਾਂਕ ਬਣਾਉਣਾ where <A> is not null. ਇਸ ਤਰ੍ਹਾਂ ਮੈਂ ਸਾਡੇ ਇੱਕ ਸੂਚਕਾਂਕ ਦਾ ਆਕਾਰ 1877 MB ਤੋਂ 16 KB ਤੱਕ ਘਟਾਉਣ ਦੇ ਯੋਗ ਸੀ। ਅਤੇ ਇੱਕ ਸੇਵਾ ਵਿੱਚ, ਸੂਚਕਾਂਕ ਤੋਂ ਨਲ ਮੁੱਲਾਂ ਨੂੰ ਬਾਹਰ ਕਰਨ ਦੇ ਕਾਰਨ ਡੇਟਾਬੇਸ ਦਾ ਆਕਾਰ ਕੁੱਲ ਮਿਲਾ ਕੇ 16% (ਪੂਰਨ ਸੰਖਿਆ ਵਿੱਚ 4.3 GB ਦੁਆਰਾ) ਘਟਿਆ ਹੈ। ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਸੋਧਾਂ ਨਾਲ ਡਿਸਕ ਸਪੇਸ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਬੱਚਤ। 🙂

ਸਮੱਸਿਆ ਛੇ - ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀਆਂ ਦੀ ਘਾਟ

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

ਇੱਕ ਦਿਨ, ਇੱਕ ਸ਼ਾਨਦਾਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੇ ਇੱਕ ਵਿਸ਼ਾਲ ਅਤੇ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੀ ਗਈ ਸਾਰਣੀ ਵਿੱਚ ਸਾਰੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਲਿਆ ਅਤੇ ਅਪਡੇਟ ਕੀਤਾ. ਸਾਨੂੰ ਨੀਲੇ ਤੋਂ ਬਾਹਰ ਸਾਰਣੀ ਦੇ ਆਕਾਰ ਲਈ +100 GB ਮਿਲਿਆ ਹੈ। ਇਹ ਇੱਕ ਸ਼ਰਮਨਾਕ ਗੱਲ ਸੀ, ਪਰ ਸਾਡੇ ਦੁਰਵਿਹਾਰ ਇੱਥੇ ਖਤਮ ਨਹੀਂ ਹੋਏ. ਇਸ ਟੇਬਲ 'ਤੇ ਆਟੋਵੈਕਿਊਮ 15 ਘੰਟਿਆਂ ਬਾਅਦ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਭੌਤਿਕ ਸਥਾਨ ਵਾਪਸ ਨਹੀਂ ਆਵੇਗਾ। ਅਸੀਂ ਸੇਵਾ ਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸੀ ਅਤੇ ਵੈਕਿਊਮ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸੀ, ਇਸ ਲਈ ਅਸੀਂ ਵਰਤਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ pg_repack. ਅਤੇ ਫਿਰ ਇਸ ਨੂੰ ਬਾਹਰ ਕਰ ਦਿੱਤਾ ਹੈ, ਜੋ ਕਿ pg_repack ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਜਾਂ ਹੋਰ ਵਿਲੱਖਣਤਾ ਸੀਮਾ ਤੋਂ ਬਿਨਾਂ ਟੇਬਲਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕਰਨਾ ਹੈ, ਅਤੇ ਸਾਡੀ ਸਾਰਣੀ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਨਹੀਂ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਡਾਇਗਨੌਸਟਿਕਸ ਦਾ ਜਨਮ ਹੋਇਆ ਸੀ ਟੇਬਲ_ਬਿਨਾਂ_ਪ੍ਰਾਇਮਰੀ_ਕੁੰਜੀ.

ਲਾਇਬ੍ਰੇਰੀ ਸੰਸਕਰਣ ਵਿੱਚ 0.1.5 ਟੇਬਲ ਅਤੇ ਸੂਚਕਾਂਕ ਦੇ ਬਲੋਟ ਤੋਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਸਮੇਂ ਸਿਰ ਇਸ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਯੋਗਤਾ ਜੋੜੀ ਗਈ ਹੈ।

ਸੱਤ ਅਤੇ ਅੱਠ ਸਮੱਸਿਆਵਾਂ - ਨਾਕਾਫ਼ੀ ਸੂਚਕਾਂਕ ਅਤੇ ਨਾ ਵਰਤੇ ਸੂਚਕਾਂਕ

ਹੇਠਾਂ ਦਿੱਤੇ ਦੋ ਨਿਦਾਨ ਹਨ: ਟੇਬਲ_ਵਿਦ_ਗੁੰਮ_ਸੂਚਕਾਂਕ и unused_indexes - ਮੁਕਾਬਲਤਨ ਹਾਲ ਹੀ ਵਿੱਚ ਆਪਣੇ ਅੰਤਮ ਰੂਪ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ. ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ ਲਿਆ ਅਤੇ ਜੋੜਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ.

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

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

ਇਕ ਸਿੱਟਾ ਹੋਣ ਦੇ ਨਾਤੇ

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

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

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

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

ਸਰੋਤ: www.habr.com