ਸਵਾਲਾਂ ਅਤੇ ਜਵਾਬਾਂ ਵਿੱਚ ਉੱਨਤ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਕਲਿਕ ਹਾਊਸ

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

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

ਸਾਵਧਾਨ ਰਹੋ, ਕੱਟ ਦੇ ਹੇਠਾਂ ਬਹੁਤ ਸਾਰਾ ਟੈਕਸਟ ਹੈ. ਅਸੀਂ ਆਸ ਕਰਦੇ ਹਾਂ ਕਿ ਸਵਾਲਾਂ ਵਾਲੀ ਸਮੱਗਰੀ ਤੁਹਾਨੂੰ ਨੈਵੀਗੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।

ਸਮੱਗਰੀ

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

ਜੇ ਤੁਸੀਂ ਪਾਠ ਨਹੀਂ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਕੱਠਾਂ ਦੀ ਰਿਕਾਰਡਿੰਗ ਦੇਖ ਸਕਦੇ ਹੋ ਸਾਡੇ YouTube ਚੈਨਲ 'ਤੇ. ਟਾਈਮਕੋਡ ਵੀਡੀਓ ਦੇ ਹੇਠਾਂ ਪਹਿਲੀ ਟਿੱਪਣੀ ਵਿੱਚ ਹਨ।

ਕਲਿਕਹਾਊਸ ਨੂੰ ਲਗਾਤਾਰ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਾਡਾ ਡੇਟਾ ਨਹੀਂ ਹੈ। ਇਸ ਬਾਰੇ ਕੀ ਕਰਨਾ ਹੈ?

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

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

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

ਕਲਿਕਹਾਊਸ ਤੋਂ ਡੇਟਾ ਦਾ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਮੌਜੂਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਕੀ ਹਨ?

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

ਅਸੀਂ ਆਪਣਾ ਹੱਲ ਬਣਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਬੈਸ਼ 'ਤੇ ਲਿਖ ਸਕਦੇ ਹਾਂ: ਇਨ੍ਹਾਂ ਬੈਕਅੱਪ ਕਾਪੀਆਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇਕੱਠਾ ਕਰੋ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕੁਝ ਵੀ ਬੈਸਾਖ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਾਈਕਲ ਦੀ ਖੋਜ ਬਹੁਤ ਪਹਿਲਾਂ ਕੀਤੀ ਗਈ ਸੀ?

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

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

ਮੈਂ ਡਾਟਾ ਦੀ ਮਾਤਰਾ ਅਤੇ ਕਲੱਸਟਰ ਦੇ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਸਭ ਤੋਂ ਸਰਲ ਹੱਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗਾ ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਹੱਲਾਂ ਨਾਲ ਸਮਾਪਤ ਕਰਾਂਗਾ। ਕਲੱਸਟਰ ਜਿੰਨਾ ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਹੱਲ ਓਨਾ ਹੀ ਗੁੰਝਲਦਾਰ ਹੁੰਦਾ ਹੈ।

ਜੇ ਡੇਟਾ ਵਾਲੀ ਸਾਰਣੀ ਵਿੱਚ ਸਿਰਫ ਕੁਝ ਗੀਗਾਬਾਈਟ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਬੈਕਅੱਪ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

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

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

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

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

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

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

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

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

ਕੀ ਸ਼ਾਫਟਾਂ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਇੱਕ ਨਿਯੰਤਰਿਤ ਲੈਗ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ ਸੰਭਵ ਹੋਵੇਗਾ?

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

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

ਜੇਕਰ ਕੋਈ ਕਮਾਂਡ ਸਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਆਈ ਅਤੇ ਇਸਨੂੰ ਤੋੜ ਦਿੱਤਾ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਇੱਕ ਘੰਟੇ ਦੇ ਪਛੜ ਦੇ ਨਾਲ ਇੱਕ ਕੰਡੀਸ਼ਨਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ, ਜਿੱਥੇ ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਚਲੋ ਇਸ ਸਮੇਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰੀਏ, ਪਰ ਅਸੀਂ ਪਿਛਲੇ ਦਸ ਮਿੰਟਾਂ ਲਈ ਇਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਾਗੂ ਨਹੀਂ ਕਰਾਂਗੇ?

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

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

ਪਹਿਲਾਂ, ਉਹ ਉਦੋਂ ਤੱਕ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਗੈਰ-ਬਲੌਕਿੰਗ ਓਪਰੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਚੋਣਵੇਂ ਸਵਾਲ ਹਨ। ਪੁਰਾਣੇ ਭਾਗਾਂ ਵਿੱਚੋਂ ਚੁਣੇ ਗਏ ਸਵਾਲ ਆਸਾਨੀ ਨਾਲ ਪੜ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ।

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

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

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

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

ਕੀ ਜੇ ਟੇਬਲ ਬਣਤਰ ਬਦਲ ਗਿਆ ਹੈ?

ਪੁਰਾਣੀ ਸਕੀਮ ਨਾਲ ਬਣਾਏ ਗਏ ਬੈਕਅੱਪ ਨੂੰ ਕਿਵੇਂ ਰੀਸਟੋਰ ਕਰਨਾ ਹੈ? ਅਤੇ ਦੂਜਾ ਸਵਾਲ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਫਾਈਲ ਸਿਸਟਮ ਟੂਲਸ ਦੇ ਮਾਮਲੇ ਬਾਰੇ ਹੈ. ਕੀ Linux LVM 'ਤੇ ZFS ਦੀ ਬਜਾਏ Btrfs ਇੱਥੇ ਵਧੀਆ ਹੈ?

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

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

ਡੇਟਾ ਰੀਸ਼ਾਰਡਿੰਗ ਵਿੱਚ ਮੌਜੂਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਕੀ ਹਨ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yandex.Metrica ਇਵੈਂਟਸ ਦੇ ਨਾਲ ਇੱਕ ਮੁੱਖ ਕਲੱਸਟਰ ਹੈ। ਇਵੈਂਟਸ ਪੇਜ ਵਿਯੂਜ਼, ਕਲਿਕਸ ਅਤੇ ਪਰਿਵਰਤਨ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਬੇਨਤੀਆਂ ਕਿਸੇ ਖਾਸ ਵੈੱਬਸਾਈਟ 'ਤੇ ਜਾਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ Yandex.Metrica ਸੇਵਾ ਖੋਲ੍ਹਦੇ ਹੋ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵੈਬਸਾਈਟ ਹੈ - avito.ru, ਰਿਪੋਰਟ 'ਤੇ ਜਾਓ, ਅਤੇ ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਲਈ ਇੱਕ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਹੈ.

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

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

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

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

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

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

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

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

ਨਵੀਂ ਸਕੀਮ ਵਿੱਚ, ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨੂੰ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ - ਵੱਡੀ ਅਤੇ ਛੋਟੀ। ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਕਿਵੇਂ ਚੁਣਿਆ ਗਿਆ ਸੀ, ਪਰ ਨਤੀਜਾ ਇਹ ਨਿਕਲਿਆ ਕਿ ਵੱਡੀਆਂ ਸਾਈਟਾਂ ਇੱਕ ਕਲੱਸਟਰ 'ਤੇ ਰਿਕਾਰਡ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਜਿੱਥੇ 120 ਸ਼ਾਰਡ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਨ - ਯਾਨੀ 360 ਸਰਵਰ। ਅਤੇ ਸ਼ਾਰਡਿੰਗ ਸਕੀਮ ਅਜਿਹੀ ਹੈ ਕਿ ਕੋਈ ਵੀ ਬੇਨਤੀ ਇੱਕੋ ਸਮੇਂ ਸਾਰੇ ਸ਼ਾਰਡਾਂ ਨੂੰ ਜਾਂਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਹੁਣ Yandex.Metrica ਵਿੱਚ avito.ru ਲਈ ਕੋਈ ਰਿਪੋਰਟ ਪੰਨਾ ਖੋਲ੍ਹਦੇ ਹੋ, ਤਾਂ ਬੇਨਤੀ 120 ਸਰਵਰਾਂ 'ਤੇ ਜਾਵੇਗੀ। RuNet ਵਿੱਚ ਕੁਝ ਵੱਡੀਆਂ ਸਾਈਟਾਂ ਹਨ। ਅਤੇ ਬੇਨਤੀਆਂ ਇੱਕ ਹਜ਼ਾਰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਨਹੀਂ ਹਨ, ਪਰ ਸੌ ਤੋਂ ਵੀ ਘੱਟ ਹਨ. ਇਹ ਸਭ ਕੁਝ ਚੁੱਪਚਾਪ ਵਿਤਰਿਤ ਟੇਬਲ ਦੁਆਰਾ ਚਬਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿਸਨੂੰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ 120 ਸਰਵਰਾਂ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ।

ਅਤੇ ਦੂਜਾ ਕਲੱਸਟਰ ਛੋਟੀਆਂ ਸਾਈਟਾਂ ਲਈ ਹੈ। ਇੱਥੇ ਸਾਈਟ ID 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਸ਼ਾਰਡਿੰਗ ਸਕੀਮ ਹੈ, ਅਤੇ ਹਰੇਕ ਬੇਨਤੀ ਬਿਲਕੁਲ ਇੱਕ ਸ਼ਾਰਡ 'ਤੇ ਜਾਂਦੀ ਹੈ।

ਕਲਿਕਹਾਊਸ ਕੋਲ ਇੱਕ ਕਲਿੱਕਹਾਊਸ-ਕਾਪੀਅਰ ਉਪਯੋਗਤਾ ਹੈ। ਕੀ ਤੁਸੀਂ ਸਾਨੂੰ ਉਸਦੇ ਬਾਰੇ ਦੱਸ ਸਕਦੇ ਹੋ?

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

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

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

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

ਤੁਹਾਡੇ ਕੋਲ ਰੀਸ਼ਾਰਡਿੰਗ ਨਾਮਕ ਇੱਕ ਪਾਇਲਟ ਚੀਜ਼ ਸੀ। ਉਸ ਨਾਲ ਕੀ?

2017 ਵਿੱਚ, ਤੁਹਾਡੇ ਕੋਲ ਰੀਸ਼ਾਰਡਿੰਗ ਨਾਮਕ ਇੱਕ ਪਾਇਲਟ ਚੀਜ਼ ਸੀ। ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਇੱਕ ਵਿਕਲਪ ਵੀ ਹੈ. ਜਿਵੇਂ ਕਿ ਮੈਂ ਇਸਨੂੰ ਸਮਝਦਾ ਹਾਂ, ਇਹ ਬੰਦ ਨਹੀਂ ਹੋਇਆ. ਕੀ ਤੁਸੀਂ ਮੈਨੂੰ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਅਜਿਹਾ ਕਿਉਂ ਹੋਇਆ? ਇਹ ਬਹੁਤ ਢੁਕਵਾਂ ਜਾਪਦਾ ਹੈ.

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

ਕੀ ਇਸ ਨੂੰ ਹੌਲੀ ਡਿਸਕ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਡਾਟਾ ਦੇ ਸਾਰੇ ਟੁਕੜਿਆਂ ਨੂੰ ਮਿਲਾਉਣਾ ਸੰਭਵ ਹੈ?

ਰਲੇਵੇਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਹੌਲੀ ਡਿਸਕ ਵਿਕਲਪ ਵੱਲ ਜਾਣ ਦੇ ਨਾਲ TTL ਬਾਰੇ ਸਵਾਲ। ਕੀ ਕੋਈ ਤਰੀਕਾ ਹੈ, ਕ੍ਰੋਨ ਰਾਹੀਂ, ਹੌਲੀ ਡਿਸਕਾਂ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੇ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕ ਵਿੱਚ ਮਿਲਾਉਣ ਦਾ?

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

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

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

ਜੇਕਰ ਪਹਿਲਾਂ ਤੋਂ ਅਨੁਕੂਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਤਾਂ ਕਲਿਕਹਾਊਸ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਨੂੰ ਕਿਵੇਂ ਮਾਈਗਰੇਟ ਕਰਨਾ ਹੈ?

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

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

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

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

ਵਰਜਨ 20.3.4 ਹੈ। ਨੰਬਰ 20 ਨਿਰਮਾਣ ਦੇ ਸਾਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ - 2020. ਅੰਦਰ ਕੀ ਹੈ, ਇਸ ਗੱਲ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ, ਇਸ ਲਈ ਅਸੀਂ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦੇਵਾਂਗੇ। ਅੱਗੇ - 20.3. ਅਸੀਂ ਦੂਜੇ ਨੰਬਰ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ - ਇਸ ਕੇਸ ਵਿੱਚ 3 - ਹਰ ਵਾਰ ਜਦੋਂ ਅਸੀਂ ਕੁਝ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਨਾਲ ਇੱਕ ਰੀਲੀਜ਼ ਜਾਰੀ ਕਰਦੇ ਹਾਂ. ਜੇਕਰ ਅਸੀਂ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇਸ ਨੰਬਰ ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਭਾਵ, ਵਰਜਨ 20.4 ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਹੋਰ ਵੀ ਵਧੀਆ ਕੰਮ ਕਰੇਗਾ। ਤੀਜਾ ਅੰਕ 20.3.4 ਹੈ। ਇੱਥੇ 4 ਪੈਚ ਰੀਲੀਜ਼ਾਂ ਦੀ ਗਿਣਤੀ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਹੀਂ ਜੋੜੀਆਂ, ਪਰ ਕੁਝ ਬੱਗ ਫਿਕਸ ਕੀਤੇ ਹਨ। ਅਤੇ 4 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਚਾਰ ਵਾਰ ਕੀਤਾ।

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

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

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

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

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

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

ਅਲੈਕਸੀ ਮਿਲੋਵਿਡੋਵ: ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ Yandex.Metrica ਤੋਂ ਸਾਡੇ ਦੋਸਤਾਂ ਦਾ ਟੈਸਟ ਵਾਤਾਵਰਨ ਕਿਹੋ ਜਿਹਾ ਹੈ। ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ 600 ਸਰਵਰ ਸਨ, ਦੂਜੇ ਵਿੱਚ 360 ਸਨ, ਅਤੇ ਇੱਕ ਤੀਜਾ ਅਤੇ ਕਈ ਕਲੱਸਟਰ ਹਨ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲਈ ਟੈਸਟ ਵਾਤਾਵਰਨ ਸਿਰਫ਼ ਦੋ ਸ਼ਾਰਡਸ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਹਰੇਕ ਵਿੱਚ ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਨ। ਦੋ ਟੁਕੜੇ ਕਿਉਂ? ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਕੱਲੇ ਨਾ ਹੋਵੋ। ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ. ਸਿਰਫ਼ ਇੱਕ ਨਿਸ਼ਚਿਤ ਘੱਟੋ-ਘੱਟ ਰਕਮ ਜੋ ਤੁਸੀਂ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹੋ।

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

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

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

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

ਕਿੱਲ ਪੁੱਛਗਿੱਛ ਨੂੰ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ। ਕਿਉਂ?

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

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

ਹੁਣ ਇੱਕ ਅਜੀਬ ਜਵਾਬ ਹੋਵੇਗਾ. ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਕਿਲ ਪੁੱਛਗਿੱਛ ਸਵਾਲਾਂ ਨੂੰ ਨਹੀਂ ਮਾਰਦੀ।

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

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

ਰੀਡਿੰਗ ਲੋਡ ਦੇ ਅਧੀਨ ਜਵਾਬ ਸਮੇਂ ਦੀ ਗਣਨਾ ਕਿਵੇਂ ਕਰੀਏ?

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

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

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

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

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

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

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

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

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

ਮੈਂ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਕੀ ਟਵੀਕ ਕਰ ਸਕਦਾ ਹਾਂ ਤਾਂ ਕਿ ਹੋਰ ਡੇਟਾ ਕੈਸ਼ ਵਿੱਚ ਹੋਵੇ?

ਆਓ ਇੱਕ ਸਥਿਤੀ ਦੀ ਕਲਪਨਾ ਕਰੀਏ - ਸਰਵਰਾਂ ਕੋਲ 256 GB RAM ਹੈ, ਰੋਜ਼ਾਨਾ ਰੁਟੀਨ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਲਗਭਗ 60-80 GB ਲੈਂਦਾ ਹੈ, ਸਿਖਰ 'ਤੇ - 130 ਤੱਕ। ਕੀ ਸਮਰਥਿਤ ਅਤੇ ਟਵੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਵਧੇਰੇ ਡੇਟਾ ਕੈਸ਼ ਵਿੱਚ ਹੋਵੇ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਡਿਸਕ 'ਤੇ ਘੱਟ ਯਾਤਰਾਵਾਂ ਹਨ?

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

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

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

ਮੈਂ RAM ਵਿੱਚ ਸਟੋਰੇਜ ਲਈ ਸਟੋਰੇਜ_ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰ ਸਕਦਾ ਹਾਂ?

ਨਵੇਂ ਕਲਿਕਹਾਊਸ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਮੈਂ ਸੰਬੰਧਿਤ ਭਾਗ ਨੂੰ ਪੜ੍ਹਦਾ ਹਾਂ ਡਾਟਾ ਸਟੋਰੇਜ਼ ਦੇ ਨਾਲ. ਵਰਣਨ ਵਿੱਚ ਤੇਜ਼ SSD ਨਾਲ ਇੱਕ ਉਦਾਹਰਨ ਸ਼ਾਮਲ ਹੈ।

ਮੈਂ ਹੈਰਾਨ ਹਾਂ ਕਿ ਵੌਲਯੂਮ ਹੌਟ ਮੈਮੋਰੀ ਨਾਲ ਇੱਕੋ ਚੀਜ਼ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਅਤੇ ਇੱਕ ਹੋਰ ਸਵਾਲ. ਇਸ ਡੇਟਾ ਸੰਗਠਨ ਨਾਲ ਚੋਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਕੀ ਇਹ ਪੂਰੇ ਸੈੱਟ ਨੂੰ ਪੜ੍ਹੇਗਾ ਜਾਂ ਸਿਰਫ ਇੱਕ ਜੋ ਕਿ ਡਿਸਕ 'ਤੇ ਹੈ, ਅਤੇ ਕੀ ਇਹ ਡੇਟਾ ਮੈਮੋਰੀ ਵਿੱਚ ਸੰਕੁਚਿਤ ਹੈ? ਅਤੇ ਪ੍ਰੀਵੀਅਰ ਸੈਕਸ਼ਨ ਅਜਿਹੇ ਡੇਟਾ ਸੰਗਠਨ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

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

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

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

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

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

ਵਿਲੱਖਣ ਮੁੱਲਾਂ ਦੀ ਕਿੰਨੀ ਸੰਖਿਆ ਤੱਕ ਲੋਅ ਕਾਰਡੀਨਲਿਟੀ ਪ੍ਰਭਾਵੀ ਹੈ?

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

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

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

ਵੱਖ-ਵੱਖ ਜਵਾਬ ਹਨ. ਪਹਿਲਾ ਇਹ ਕਹਿਣਾ ਹੈ ਕਿ ਕਲਿਕਹਾਊਸ ਇੱਕ ਫੁੱਲ-ਟੈਕਸਟ ਖੋਜ ਇੰਜਨ ਨਹੀਂ ਹੈ. ਇਸਦੇ ਲਈ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਣਾਲੀਆਂ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਲਲਸੀ ਖੋਜ и sphinx. ਹਾਲਾਂਕਿ, ਮੈਂ ਤੇਜ਼ੀ ਨਾਲ ਲੋਕਾਂ ਨੂੰ ਇਹ ਕਹਿੰਦੇ ਹੋਏ ਵੇਖਦਾ ਹਾਂ ਕਿ ਉਹ ਇਲਾਸਟਿਕ ਖੋਜ ਤੋਂ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਬਦਲ ਰਹੇ ਹਨ.

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

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

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

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

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

ਹਾਲ ਹੀ ਵਿੱਚ, ਕਲਿਕਹਾਊਸ ਨੇ ਫੁੱਲ-ਟੈਕਸਟ ਖੋਜ ਲਈ ਹੋਰ ਵੀ ਉੱਨਤ ਫੰਕਸ਼ਨ ਸ਼ਾਮਲ ਕੀਤੇ ਹਨ। ਇਹ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, UTF-8 ਲਈ ਜਾਂ ਸਿਰਫ਼ ASCII ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ, ਕੇਸ-ਸੰਵੇਦਨਸ਼ੀਲ, ਕੇਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਵਿਕਲਪਾਂ ਸਮੇਤ, ਇੱਕੋ ਪਾਸ ਵਿੱਚ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਬਸਟਰਿੰਗਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੀ ਖੋਜ ਹੈ। ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਇੱਕ ਚੁਣੋ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ।

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

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

ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਕਲਿਕਹਾਊਸ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਕੀ ਹੈ?

ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਖਪਤਕਾਰਾਂ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਲਈ ਪਹੁੰਚ ਨੂੰ ਕਿਵੇਂ ਵਿਵਸਥਿਤ ਕਰਨਾ ਹੈ। ਇੱਕ ਕਤਾਰ ਕਿਵੇਂ ਬਣਾਈਏ, ਅਧਿਕਤਮ ਸਮਕਾਲੀ ਸਵਾਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਅਤੇ ਕਿਹੜੇ ਸਾਧਨਾਂ ਨਾਲ?

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

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

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਲਿਕਹਾਊਸ ਦੀਆਂ ਦੋ ਤਰਜੀਹੀ ਸੈਟਿੰਗਾਂ ਹਨ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਉਹ ਬਹੁਤ ਹੀ ਮੁੱਢਲੇ ਹਨ. ਇੱਕ ਨੂੰ ਸਿਰਫ਼ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਤਰਜੀਹ. ਜੇਕਰ ਪ੍ਰਾਥਮਿਕਤਾ ≠ 0, ਅਤੇ ਕੁਝ ਤਰਜੀਹ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਪਰ ਇਸ ਤੋਂ ਘੱਟ ਦੇ ਤਰਜੀਹੀ ਮੁੱਲ ਵਾਲੀ ਬੇਨਤੀ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਉੱਚ ਤਰਜੀਹ, ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਵੱਧ ਤਰਜੀਹੀ ਮੁੱਲ ਵਾਲੀ ਬੇਨਤੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਤਰਜੀਹ , ਬਸ ਮੁਅੱਤਲ ਹੈ ਅਤੇ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਬਿਲਕੁਲ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ।

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

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

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

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

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

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

ਕੀ ਦਸ ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਪੁੱਛਗਿੱਛ ਦੇ ਨਤੀਜੇ ਦੇਣਾ ਸੰਭਵ ਹੈ?

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

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

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

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

ਇੱਥੇ ਇੱਕ ਵਿਕਲਪਿਕ ਹੱਲ ਹੈ ਜੋ ਕਲਿਕਹਾਊਸ ਦੇ ਅੱਗੇ ਇੱਕ ਸਾਈਡਕਾਰ ਵਜੋਂ ਰੱਖਿਆ ਗਿਆ ਹੈ - ਹਾਊਸ ਪ੍ਰੌਕਸੀ 'ਤੇ ਕਲਿੱਕ ਕਰੋ.

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

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

ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨਾਂ ਅਤੇ ਪਦਾਰਥਕ ਦ੍ਰਿਸ਼ਾਂ ਬਾਰੇ ਕੀ?

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

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

ਇਹ ਸਮਝਣ ਯੋਗ ਹੈ ਕਿ ਡੁਪਲੀਕੇਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੋ ਮੈਂ ਤੁਹਾਨੂੰ ਹੁਣ ਦੱਸਾਂਗਾ, ਉਹ ਸਵਾਲ ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੈ, ਪਰ ਜੇ ਇਹ ਯਾਦ ਰੱਖਣ ਯੋਗ ਹੈ।

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

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

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

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

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

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

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

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

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

ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਲੌਗ ਹਨ। ਮੈਂ ਸਰਵਰ ਨਾਲ ਵਾਪਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਕਿਵੇਂ ਦੇਖ ਸਕਦਾ ਹਾਂ?

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

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

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

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

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

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

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

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

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

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

ਅਭੇਦ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਸਰਵਰ OOM ਵਿੱਚ ਕ੍ਰੈਸ਼ ਨਾ ਹੋ ਜਾਵੇ?

ਮੇਰੇ ਕੋਲ ਇੱਕ ਟੇਬਲ ਹੈ, ਟੇਬਲ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਭਾਗ ਹੈ, ਉਹ ਹੈ ReplaceingMergeTree. ਮੈਂ ਚਾਰ ਸਾਲਾਂ ਤੋਂ ਇਸ ਵਿੱਚ ਡੇਟਾ ਲਿਖ ਰਿਹਾ ਹਾਂ। ਮੈਨੂੰ ਇਸ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਕਰਨ ਅਤੇ ਕੁਝ ਡੇਟਾ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਸੀ।

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

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

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

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

ਵਲਾਦੀਮੀਰ ਕੋਲੋਬਾਏਵ: ਜੁਰਮਾਨਾ. ਇੱਥੇ ਪਲ ਅਜਿਹਾ ਹੈ ਕਿ ਬੱਗ ਫਿਕਸ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਆਪਣੇ ਲਈ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਡਾਉਨਲੋਡ ਕੀਤਾ, ਅਤੇ ਇੱਕ ਹੋਰ ਟੇਬਲ 'ਤੇ, ਇੱਕ ਛੋਟਾ, ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ ਭਾਗ ਹਨ, ਮੈਂ ਇੱਕ ਸਮਾਨ ਕਾਰਵਾਈ ਕੀਤੀ. ਅਤੇ ਮਰਜ ਦੇ ਦੌਰਾਨ, ਸਰਵਰ 'ਤੇ ਲਗਭਗ 100 GB RAM ਬਰਨ ਹੋ ਗਈ ਸੀ। ਮੇਰੇ ਕੋਲ 150 ਨੇ ਕਬਜ਼ਾ ਕਰ ਲਿਆ ਸੀ, 100 ਖਾਧੇ ਸਨ, ਅਤੇ ਇੱਕ 50 GB ਵਿੰਡੋ ਬਚੀ ਸੀ, ਇਸਲਈ ਮੈਂ OOM ਵਿੱਚ ਨਹੀਂ ਆਇਆ।

ਜੇਕਰ ਇਹ ਅਸਲ ਵਿੱਚ 100 GB RAM ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ ਤਾਂ ਇਸ ਵੇਲੇ ਮੈਨੂੰ OOM ਵਿੱਚ ਡਿੱਗਣ ਤੋਂ ਕੀ ਬਚਾਉਂਦਾ ਹੈ? ਕੀ ਕਰਨਾ ਹੈ ਜੇਕਰ ਅਚਾਨਕ ਰਲੇਵੇਂ 'ਤੇ RAM ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ?

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

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

ਕਲਿਕਹਾਊਸ ਲਈ ਗੋਲੰਗ ਡ੍ਰਾਈਵਰ ਕਿਵੇਂ ਵਿਕਸਤ ਕੀਤਾ ਜਾਵੇਗਾ?

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

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

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

ਕਿਰਿਲ ਸ਼ਵਾਕੋਵ: ਪਹਿਲਾ ਇਹ ਹੈ ਕਿ ਕਿਵੇਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਨੌਕਰਸ਼ਾਹੀ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਨੁਕਤੇ 'ਤੇ ਚਰਚਾ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ, ਇਸ ਲਈ ਮੇਰੇ ਕੋਲ ਜਵਾਬ ਦੇਣ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ.

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

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

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

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

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

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

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

ਸਾਡੇ ਕੋਲ ਇਹਨਾਂ ਡਰਾਈਵਰਾਂ ਲਈ ਕੋਈ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਨਹੀਂ ਹੈ. ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਅਸੀਂ ਇਸ ਖਾਸ ਡਰਾਈਵਰ ਲਈ ਨਹੀਂ, ਸਗੋਂ ਸਾਰੇ ਕਮਿਊਨਿਟੀ ਡਰਾਈਵਰਾਂ ਦੇ ਵਿਕਾਸ ਲਈ ਇੱਕ ਵਿਅਕਤੀਗਤ ਵਿਅਕਤੀ ਨੂੰ ਨੌਕਰੀ 'ਤੇ ਰੱਖ ਸਕਦੇ ਹਾਂ, ਜਾਂ ਕੀ ਅਸੀਂ ਬਾਹਰੋਂ ਕਿਸੇ ਨੂੰ ਲੱਭ ਸਕਦੇ ਹਾਂ।

ਬਾਹਰੀ ਸ਼ਬਦਕੋਸ਼ ਆਲਸੀ_ਲੋਡ ਸੈਟਿੰਗ ਨੂੰ ਸਮਰੱਥ ਹੋਣ ਨਾਲ ਰੀਬੂਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਮੈਂ ਕੀ ਕਰਾਂ?

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

ਸ਼ਾਇਦ ਸਾਡੇ ਕੋਲ ਕਲਿਕਹਾਊਸ ਦਾ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਹੈ, ਇਸ ਲਈ ਸ਼ਬਦਕੋਸ਼ ਆਪਣੇ ਆਪ ਲੋਡ ਨਹੀਂ ਹੋਇਆ ਹੈ। ਕੀ ਇਹ ਕੇਸ ਹੋ ਸਕਦਾ ਹੈ?

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

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

ਆਖਰੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਜਾਂ ਤਾਂ ਸੰਸਕਰਣ ਪੁਰਾਣਾ ਹੈ ਜਾਂ ਇਸਨੂੰ ਡੀਬੱਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

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

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

ਕੀ ਕਲਿਕਹਾਊਸ ਕੌਂਫਿਗਰ ਵਿੱਚ ਵੇਰਵਿਆਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਹੈ, ਪਰ ਗਲਤੀਆਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕਰਨਾ?

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

ਅਸੀਂ ODBC ਡਰਾਈਵਰ ਸੰਰਚਨਾ ਵਿੱਚ ਵੇਰਵੇ ਜੋੜ ਕੇ ਇਸ ਗਲਤੀ ਨੂੰ ਹੱਲ ਕੀਤਾ ਹੈ। ਕੀ ਕਲਿਕਹਾਊਸ ਸੰਰਚਨਾ ਵਿੱਚ ਵੇਰਵਿਆਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਹੈ, ਪਰ ਗਲਤੀਆਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇਹਨਾਂ ਵੇਰਵਿਆਂ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦੇ?

ਇੱਥੇ ਅਸਲ ਹੱਲ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ odbc.ini ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਕਰੋ, ਅਤੇ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਹੀ ਸਿਰਫ ODBC ਡੇਟਾ ਸਰੋਤ ਨਾਮ ਦਿਓ। ਇਹ ਹੋਰ ਡਿਕਸ਼ਨਰੀ ਸਰੋਤਾਂ ਲਈ ਨਹੀਂ ਹੋਵੇਗਾ - ਨਾ ਹੀ MySQL ਵਾਲੇ ਡਿਕਸ਼ਨਰੀ ਲਈ, ਨਾ ਹੀ ਹੋਰਾਂ ਲਈ, ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਗਲਤੀ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਪਾਸਵਰਡ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। ODBC ਲਈ, ਮੈਂ ਇਹ ਵੀ ਦੇਖਾਂਗਾ - ਜੇਕਰ ਇਹ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ।

ਬੋਨਸ: ਇਕੱਠਾਂ ਤੋਂ ਜ਼ੂਮ ਲਈ ਪਿਛੋਕੜ

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

ਸਰੋਤ: www.habr.com