ਬਿਲਡਰਾਂ ਲਈ B2B ਸੇਵਾ ਦੀ ਉਦਾਹਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਡਾਟਾਬੇਸ ਸਵਾਲਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨਾ

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

ਮੈਂ ਉਸਾਰੀ ਕੰਪਨੀਆਂ ਵਿੱਚ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਸੇਵਾ ਬਣਾਉਂਦਾ ਹਾਂ। ਸਾਡੇ ਨਾਲ ਲਗਭਗ 3 ਹਜ਼ਾਰ ਕੰਪਨੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। 10 ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਲੋਕ ਸਾਡੇ ਸਿਸਟਮ ਨਾਲ ਹਰ ਰੋਜ਼ 4-10 ਘੰਟੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਹ ਯੋਜਨਾਬੰਦੀ, ਸੂਚਨਾ, ਚੇਤਾਵਨੀ, ਪ੍ਰਮਾਣਿਕਤਾ ਦੀਆਂ ਕਈ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ... ਅਸੀਂ PostgreSQL 9.6 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਗਭਗ 300 ਟੇਬਲ ਹਨ ਅਤੇ ਹਰ ਰੋਜ਼ 200 ਮਿਲੀਅਨ ਸਵਾਲ (10 ਹਜ਼ਾਰ ਵੱਖ-ਵੱਖ) ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ। ਔਸਤਨ ਸਾਡੇ ਕੋਲ ਪ੍ਰਤੀ ਸਕਿੰਟ 3-4 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ ਹਨ, ਸਭ ਤੋਂ ਵੱਧ ਸਰਗਰਮ ਪਲਾਂ ਵਿੱਚ ਪ੍ਰਤੀ ਸਕਿੰਟ 10 ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਸਵਾਲ OLAP ਹਨ। ਇੱਥੇ ਬਹੁਤ ਘੱਟ ਜੋੜ, ਸੋਧਾਂ ਅਤੇ ਮਿਟਾਏ ਗਏ ਹਨ, ਭਾਵ OLTP ਲੋਡ ਮੁਕਾਬਲਤਨ ਹਲਕਾ ਹੈ। ਮੈਂ ਇਹ ਸਾਰੇ ਨੰਬਰ ਪ੍ਰਦਾਨ ਕੀਤੇ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਪੈਮਾਨੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕੋ ਅਤੇ ਸਮਝ ਸਕੋ ਕਿ ਸਾਡਾ ਅਨੁਭਵ ਤੁਹਾਡੇ ਲਈ ਕਿੰਨਾ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।

ਤਸਵੀਰ ਇੱਕ. ਗੀਤਕਾਰੀ

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

ਤਸਵੀਰ ਦੋ. ਅੰਕੜਾ

ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਲਗਭਗ 10 ਹਜ਼ਾਰ ਵੱਖ-ਵੱਖ ਸਵਾਲ ਹਨ ਜੋ ਪ੍ਰਤੀ ਦਿਨ ਸਾਡੇ ਡੇਟਾਬੇਸ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਹਨਾਂ 10 ਹਜ਼ਾਰਾਂ ਵਿੱਚੋਂ, ਅਜਿਹੇ ਰਾਖਸ਼ ਹਨ ਜੋ 2-3 ms ਦੇ ਔਸਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮੇਂ ਦੇ ਨਾਲ 0.1-0.3 ਮਿਲੀਅਨ ਵਾਰ ਚਲਾਏ ਜਾਂਦੇ ਹਨ, ਅਤੇ 30 ਸਕਿੰਟਾਂ ਦੇ ਔਸਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮੇਂ ਦੇ ਨਾਲ ਸਵਾਲ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਦਿਨ ਵਿੱਚ 100 ਵਾਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

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

ਚੋਟੀ ਦੀਆਂ ਬੇਨਤੀਆਂ

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

ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਦਾ ਆਮ ਅਭਿਆਸ ਚੋਟੀ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਘੱਟ ਹਨ; ਇੱਕ ਪੁੱਛਗਿੱਛ ਨੂੰ ਵੀ ਅਨੁਕੂਲ ਬਣਾਉਣ ਨਾਲ 5-10% ਸਰੋਤ ਖਾਲੀ ਹੋ ਸਕਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਪ੍ਰੋਜੈਕਟ ਪਰਿਪੱਕ ਹੁੰਦਾ ਹੈ, ਚੋਟੀ ਦੇ ਸਵਾਲਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਇੱਕ ਵਧਦੀ ਗੈਰ-ਮਾਮੂਲੀ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ। ਸਾਰੀਆਂ ਸਧਾਰਨ ਵਿਧੀਆਂ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਕੀਤੀਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ "ਭਾਰੀ" ਬੇਨਤੀ "ਸਿਰਫ਼" 3-5% ਸਰੋਤ ਲੈਂਦੀ ਹੈ। ਜੇਕਰ ਕੁੱਲ ਮਿਲਾ ਕੇ ਚੋਟੀ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ 30-40% ਤੋਂ ਘੱਟ ਸਮਾਂ ਲੈਂਦੀਆਂ ਹਨ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰ ਲਈਆਂ ਹਨ ਅਤੇ ਅਗਲੇ ਸਮੂਹ ਤੋਂ ਸਵਾਲਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਅੱਗੇ ਵਧਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ।
ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਬਾਕੀ ਹੈ ਕਿ ਇਸ ਸਮੂਹ ਵਿੱਚ ਕਿੰਨੇ ਪ੍ਰਮੁੱਖ ਸਵਾਲ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਮੈਂ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ 10 ਲੈਂਦਾ ਹਾਂ, ਪਰ 20 ਤੋਂ ਵੱਧ ਨਹੀਂ। ਮੈਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹਾਂ ਕਿ TOP ਸਮੂਹ ਵਿੱਚ ਪਹਿਲੇ ਅਤੇ ਆਖਰੀ ਦਾ ਸਮਾਂ 10 ਤੋਂ ਵੱਧ ਵਾਰ ਵੱਖ ਨਾ ਹੋਵੇ। ਭਾਵ, ਜੇਕਰ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ 1st ਸਥਾਨ ਤੋਂ 10 ਵੇਂ ਸਥਾਨ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਹੈ, ਤਾਂ ਮੈਂ TOP-10 ਲੈਂਦਾ ਹਾਂ, ਜੇਕਰ ਡ੍ਰੌਪ ਵਧੇਰੇ ਹੌਲੀ ਹੈ, ਤਾਂ ਮੈਂ ਸਮੂਹ ਦੇ ਆਕਾਰ ਨੂੰ 15 ਜਾਂ 20 ਤੱਕ ਵਧਾ ਦਿੰਦਾ ਹਾਂ.

ਮੱਧ ਕਿਸਾਨ

ਇਹ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਹਨ ਜੋ TOP ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਆਉਂਦੀਆਂ ਹਨ, ਪਿਛਲੇ 5-10% ਨੂੰ ਛੱਡ ਕੇ। ਆਮ ਤੌਰ 'ਤੇ, ਇਹਨਾਂ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਵਿੱਚ ਸਰਵਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਹੁਤ ਵਧਾਉਣ ਦਾ ਮੌਕਾ ਹੁੰਦਾ ਹੈ। ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਦਾ ਭਾਰ 80% ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਫਿਰ ਵੀ ਜੇਕਰ ਉਹਨਾਂ ਦਾ ਹਿੱਸਾ 50% ਤੋਂ ਵੱਧ ਗਿਆ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਧਿਆਨ ਨਾਲ ਦੇਖਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ।

ਪੂਛ

ਜਿਵੇਂ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ ਸਵਾਲ ਅੰਤ ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਅਤੇ 5-10% ਸਮਾਂ ਲੈਂਦੇ ਹਨ। ਤੁਸੀਂ ਉਹਨਾਂ ਬਾਰੇ ਸਿਰਫ ਤਾਂ ਹੀ ਭੁੱਲ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਆਟੋਮੈਟਿਕ ਪੁੱਛਗਿੱਛ ਵਿਸ਼ਲੇਸ਼ਣ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਵੀ ਸਸਤਾ ਹੋ ਸਕਦਾ ਹੈ.

ਹਰੇਕ ਸਮੂਹ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰੀਏ?

ਮੈਂ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ ਜੋ PostgreSQL ਲਈ ਅਜਿਹਾ ਮੁਲਾਂਕਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ (ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਕਈ ਹੋਰ DBMSs ਲਈ ਇੱਕ ਸਮਾਨ ਪੁੱਛਗਿੱਛ ਲਿਖੀ ਜਾ ਸਕਦੀ ਹੈ)

TOP-MEDIUM-TAIL ਸਮੂਹਾਂ ਦੇ ਆਕਾਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ SQL ਪੁੱਛਗਿੱਛ

SELECT sum(time_top) AS sum_top, sum(time_medium) AS sum_medium, sum(time_tail) AS sum_tail
FROM
(
  SELECT CASE WHEN rn <= 20              THEN tt_percent ELSE 0 END AS time_top,
         CASE WHEN rn > 20 AND rn <= 800 THEN tt_percent ELSE 0 END AS time_medium,
         CASE WHEN rn > 800              THEN tt_percent ELSE 0 END AS time_tail
  FROM (
    SELECT total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query,
    ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn
    FROM pg_stat_statements
    ORDER BY total_time DESC
  ) AS t
)
AS ts

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

ਇਸ ਤਰ੍ਹਾਂ ਬੇਨਤੀਆਂ ਦੇ ਸ਼ੇਅਰ ਮੋਟੇ ਤੌਰ 'ਤੇ ਉਸ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਨ ਜਦੋਂ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਕੰਮ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ ਅਤੇ ਹੁਣ।

ਚਿੱਤਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਚੋਟੀ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਹਿੱਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਿਆ ਹੈ, ਪਰ "ਮੱਧ ਕਿਸਾਨ" ਵਧਿਆ ਹੈ।
ਪਹਿਲਾਂ-ਪਹਿਲਾਂ, ਚੋਟੀ ਦੀਆਂ ਬੇਨਤੀਆਂ ਵਿੱਚ ਸਪੱਸ਼ਟ ਗਲਤੀਆਂ ਸ਼ਾਮਲ ਸਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਬਚਪਨ ਦੀਆਂ ਬਿਮਾਰੀਆਂ ਅਲੋਪ ਹੋ ਗਈਆਂ, TOP ਬੇਨਤੀਆਂ ਦਾ ਹਿੱਸਾ ਘਟ ਗਿਆ, ਅਤੇ ਮੁਸ਼ਕਲ ਬੇਨਤੀਆਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਯਤਨ ਕਰਨੇ ਪਏ।

ਬੇਨਤੀਆਂ ਦਾ ਪਾਠ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਬੇਨਤੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

SELECT * FROM (
  SELECT ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn, total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query
  FROM pg_stat_statements
  ORDER BY total_time DESC
) AS T
WHERE
rn <= 20 -- TOP
-- rn > 20 AND rn <= 800 -- MEDIUM
-- rn > 800  -- TAIL

ਇੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਤਕਨੀਕਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਚੋਟੀ ਦੇ ਸਵਾਲਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕੀਤੀ:

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

ਕਈ ਵਾਰ ਤਬਦੀਲੀਆਂ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੀਡਿਜ਼ਾਈਨ ਦੇ ਬਰਾਬਰ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੇ ਸਿਸਟਮ ਲੋਡ ਦਾ 5-10% ਪ੍ਰਦਾਨ ਕੀਤਾ ਅਤੇ ਜਾਇਜ਼ ਸਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਨਿਕਾਸ ਛੋਟਾ ਅਤੇ ਛੋਟਾ ਹੋ ਗਿਆ, ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਗੰਭੀਰ ਰੀਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਸੀ.

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

• COUNT ਅਤੇ ਇੱਕ ਪੂਰੇ ਟੇਬਲ ਸਕੈਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰਿਕਾਰਡਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਬਜਾਏ, EXISTS ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣ ਲੱਗੀ
• DISTINCT ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਇਆ (ਕੋਈ ਆਮ ਨੁਸਖਾ ਨਹੀਂ ਹੈ, ਪਰ ਕਈ ਵਾਰ ਤੁਸੀਂ ਬੇਨਤੀ ਨੂੰ 10-100 ਵਾਰ ਤੇਜ਼ ਕਰਕੇ ਆਸਾਨੀ ਨਾਲ ਇਸ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਸਕਦੇ ਹੋ)।

  ਉਦਾਹਰਨ ਲਈ, ਡਿਲੀਵਰੀ ਦੀ ਇੱਕ ਵੱਡੀ ਸਾਰਣੀ (ਡਿਲੀਵਰੀ) ਤੋਂ ਸਾਰੇ ਡਰਾਈਵਰਾਂ ਨੂੰ ਚੁਣਨ ਲਈ ਇੱਕ ਪੁੱਛਗਿੱਛ ਦੀ ਬਜਾਏ

  SELECT DISTINCT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM DELIVERY D JOIN PERSON P ON D.DRIVER_ID = P.ID
  

  ਇੱਕ ਮੁਕਾਬਲਤਨ ਛੋਟੀ ਮੇਜ਼ PERSON 'ਤੇ ਇੱਕ ਪੁੱਛਗਿੱਛ ਕੀਤੀ

  SELECT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM PERSON
  WHERE EXISTS(SELECT D.ID FROM DELIVERY WHERE D.DRIVER_ID = P.ID)
  

  ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਸੰਬੰਧਤ ਸਬਕਵੇਰੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ, ਪਰ ਇਹ 10 ਗੁਣਾ ਤੋਂ ਵੱਧ ਦੀ ਗਤੀ ਦਿੰਦਾ ਹੈ।

• ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, COUNT ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ ਅਤੇ
  ਅਨੁਮਾਨਿਤ ਮੁੱਲ ਦੀ ਗਣਨਾ ਦੁਆਰਾ ਬਦਲਿਆ ਗਿਆ
• ਦੀ ਬਜਾਏ

  UPPER(s) LIKE JOHN%’ 
  

  ਵਰਤੋਂ

  s ILIKE “John%”
  

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

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਹੁਣ ਤਿੰਨ ਸਾਲਾਂ ਤੋਂ ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ। ਔਸਤ ਰੋਜ਼ਾਨਾ ਲੋਡ ਲਗਭਗ 30% ਹੈ, ਸਿਖਰਾਂ ਵਿੱਚ ਇਹ 70% ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ. ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ, ਅਤੇ ਨਾਲ ਹੀ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਗਿਣਤੀ, ਲਗਭਗ 10 ਗੁਣਾ ਵਧ ਗਈ ਹੈ. ਅਤੇ ਇਹ ਸਭ TOP-MEDIUM ਬੇਨਤੀਆਂ ਦੇ ਇਹਨਾਂ ਸਮੂਹਾਂ ਦੀ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਲਈ ਧੰਨਵਾਦ. ਜਿਵੇਂ ਹੀ TOP ਸਮੂਹ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਬੇਨਤੀ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ, ਅਸੀਂ ਤੁਰੰਤ ਇਸਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਤੇਜ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਪੁੱਛਗਿੱਛ ਵਿਸ਼ਲੇਸ਼ਣ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਮੱਧਮ ਸਮੂਹ ਦੀ ਸਮੀਖਿਆ ਕਰਦੇ ਹਾਂ। ਜੇਕਰ ਸਾਨੂੰ ਨਵੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਮਿਲਦੀਆਂ ਹਨ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਾਂ ਕਿ ਕਿਵੇਂ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਬਦਲ ਦਿੰਦੇ ਹਾਂ। ਕਈ ਵਾਰ ਅਸੀਂ ਨਵੇਂ ਅਨੁਕੂਲਨ ਢੰਗ ਲੱਭਦੇ ਹਾਂ ਜੋ ਇੱਕੋ ਸਮੇਂ ਕਈ ਸਵਾਲਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

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

ਸਰੋਤ: www.habr.com