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

ਹੈਲੋ

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

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

ਬੇਦਾਅਵਾ

PostgreSQL ਦਾ ਪ੍ਰਾਇਮਰੀ ਵਰਜਨ ਜਿਸ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰਦਾ ਹਾਂ ਉਹ 10 ਹੈ। ਮੇਰੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਾਰੇ SQL ਸਵਾਲਾਂ ਨੂੰ ਵਰਜਨ 11 'ਤੇ ਵੀ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਘੱਟੋ-ਘੱਟ ਸਮਰਥਿਤ ਵਰਜਨ 9.6 ਹੈ।

prehistory

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

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

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

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

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

ਸਮੱਸਿਆ ਦੋ: ਡੁਪਲੀਕੇਟ ਇੰਡੈਕਸ

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

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

ਸਮੱਸਿਆ ਤਿੰਨ: ਕੱਟਣ ਵਾਲੇ ਸੂਚਕਾਂਕ

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

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

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

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

delete from <table> where id in (…)

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

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

ਸਮੱਸਿਆ ਨੰਬਰ ਪੰਜ: ਸੂਚਕਾਂਕ ਵਿੱਚ ਖਾਲੀ ਮੁੱਲ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਸਰੋਤ: www.habr.com