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

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

ਪੁਰਾਣੇ ਸਕੂਲ ਦੀ ਸ਼ਕਤੀ

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

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

ਇਸ ਲੇਖ ਤੋਂ ਮੁੱਖ ਵਿਚਾਰ:

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

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

ਬਰੂਟ ਫੋਰਸ ਵਿਧੀ

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

ਮੈਂ ਗੂਗਲ 'ਤੇ ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਅਤੇ ਇਹ ਵਧੀਆ ਕੰਮ ਕੀਤਾ. ਪਰ Scalyr ਵਿੱਚ ਅਸੀਂ ਬਾਈਟ ਦੁਆਰਾ ਲੌਗਸ ਦੀ ਖੋਜ ਕਰਦੇ ਹਾਂ।

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

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

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

ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਵਿਰਾਮ ਚਿੰਨ੍ਹ ਹੈ। ਕੀ ਤੁਸੀਂ ਇਸ ਤੋਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਲੱਭਣਾ ਚਾਹੁੰਦੇ ਹੋ 50.168.29.7? ਡੀਬੱਗਿੰਗ ਲੌਗਸ ਬਾਰੇ ਕੀ [error]? ਸਬਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਵਿਰਾਮ ਚਿੰਨ੍ਹ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ।

ਅੰਤ ਵਿੱਚ, ਇੰਜੀਨੀਅਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਾਧਨਾਂ ਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਸਿਰਫ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕੀਵਰਡ ਇੰਡੈਕਸ ਇਸ ਲਈ ਬਹੁਤ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ.

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

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

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

ਬਰੂਟ ਫੋਰਸ ਕੰਮ ਕਰਦੀ ਹੈ ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੋਈ ਵਹਿਸ਼ੀ ਸਮੱਸਿਆ ਹੈ (ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤਾਕਤ)

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

ਸਾਡੇ ਖੋਜ ਕੋਡ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਇੱਕ ਕਾਫ਼ੀ ਵੱਡਾ ਅੰਦਰੂਨੀ ਲੂਪ ਸੀ। ਅਸੀਂ 4K 'ਤੇ ਪੰਨਿਆਂ 'ਤੇ ਸੁਨੇਹੇ ਸਟੋਰ ਕਰਦੇ ਹਾਂ; ਹਰੇਕ ਪੰਨੇ ਵਿੱਚ ਹਰੇਕ ਸੁਨੇਹੇ ਲਈ ਕੁਝ ਸੁਨੇਹੇ (UTF-8 ਵਿੱਚ) ਅਤੇ ਮੈਟਾਡੇਟਾ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਮੈਟਾਡੇਟਾ ਇੱਕ ਢਾਂਚਾ ਹੈ ਜੋ ਮੁੱਲ ਦੀ ਲੰਬਾਈ, ਅੰਦਰੂਨੀ ਸੁਨੇਹਾ ID, ਅਤੇ ਹੋਰ ਖੇਤਰਾਂ ਨੂੰ ਏਨਕੋਡ ਕਰਦਾ ਹੈ। ਖੋਜ ਚੱਕਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

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

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

ਸ਼ੁਰੂ ਵਿੱਚ, ਅਜਿਹਾ ਲਗਦਾ ਸੀ ਕਿ ਅਜਿਹਾ ਕੋਡ ਬਰੂਟ ਫੋਰਸ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਲਈ ਬਹੁਤ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ। "ਅਸਲ ਕੰਮ" ਵਿੱਚ String.indexOf() CPU ਪ੍ਰੋਫਾਈਲ 'ਤੇ ਵੀ ਹਾਵੀ ਨਹੀਂ ਸੀ। ਭਾਵ, ਇਕੱਲੇ ਇਸ ਵਿਧੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਭਾਵ ਨਹੀਂ ਲਿਆਏਗਾ।

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

ਇਹ ਸੰਸਕਰਣ ਸਿੱਧੇ ਦ੍ਰਿਸ਼ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ raw byte[] ਅਤੇ ਪੂਰੇ 4K ਪੰਨੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਾਰੇ ਸੁਨੇਹਿਆਂ ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ।

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

ਸਾਡਾ ਅਸਲ ਖੋਜ ਐਲਗੋਰਿਦਮ 'ਤੇ ਆਧਾਰਿਤ ਹੈ Leonid Volnitsky ਦੇ ਮਹਾਨ ਵਿਚਾਰ. ਇਹ Boyer-Moore ਐਲਗੋਰਿਦਮ ਦੇ ਸਮਾਨ ਹੈ, ਹਰ ਪੜਾਅ 'ਤੇ ਖੋਜ ਸਤਰ ਦੀ ਲਗਭਗ ਲੰਬਾਈ ਨੂੰ ਛੱਡ ਕੇ। ਮੁੱਖ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਇਹ ਝੂਠੇ ਮੈਚਾਂ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਲਈ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਦੋ ਬਾਈਟਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।

ਸਾਡੇ ਲਾਗੂਕਰਨ ਲਈ ਹਰੇਕ ਖੋਜ ਲਈ ਇੱਕ 64K ਲੁੱਕਅਪ ਟੇਬਲ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਇਹ ਸਾਡੇ ਦੁਆਰਾ ਖੋਜ ਰਹੇ ਗੀਗਾਬਾਈਟ ਡੇਟਾ ਦੇ ਮੁਕਾਬਲੇ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ। ਅੰਦਰੂਨੀ ਲੂਪ ਇੱਕ ਸਿੰਗਲ ਕੋਰ 'ਤੇ ਕਈ ਗੀਗਾਬਾਈਟ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ। ਅਭਿਆਸ ਵਿੱਚ, ਹਰੇਕ ਕੋਰ 'ਤੇ ਸਥਿਰ ਪ੍ਰਦਰਸ਼ਨ ਲਗਭਗ 1,25 GB ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੈ, ਅਤੇ ਸੁਧਾਰ ਲਈ ਜਗ੍ਹਾ ਹੈ। ਅੰਦਰੂਨੀ ਲੂਪ ਦੇ ਬਾਹਰ ਕੁਝ ਓਵਰਹੈੱਡ ਨੂੰ ਖਤਮ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਅਤੇ ਅਸੀਂ Java ਦੀ ਬਜਾਏ C ਵਿੱਚ ਅੰਦਰੂਨੀ ਲੂਪ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ।

ਅਸੀਂ ਤਾਕਤ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

ਅਸੀਂ ਚਰਚਾ ਕੀਤੀ ਹੈ ਕਿ ਲੌਗ ਖੋਜ ਨੂੰ "ਮੋਟੇ ਤੌਰ 'ਤੇ" ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਾਡੇ ਕੋਲ ਕਿੰਨੀ "ਸ਼ਕਤੀ" ਹੈ? ਕੁੱਝ ਜਿਆਦਾ ਹੀ.

1 ਕੋਰ: ਜਦੋਂ ਸਹੀ ਢੰਗ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਆਧੁਨਿਕ ਪ੍ਰੋਸੈਸਰ ਦਾ ਇੱਕ ਸਿੰਗਲ ਕੋਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ।

8 ਕੋਰ: ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਐਮਾਜ਼ਾਨ hi1.4xlarge ਅਤੇ i2.4xlarge SSD ਸਰਵਰਾਂ 'ਤੇ ਚੱਲ ਰਹੇ ਹਾਂ, ਹਰੇਕ 8 ਕੋਰ (16 ਥ੍ਰੈਡਸ) ਦੇ ਨਾਲ। ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ ਕੋਰ ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਗ੍ਰਾਉਂਡ ਓਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਰੁੱਝੇ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਉਪਭੋਗਤਾ ਖੋਜ ਕਰਦਾ ਹੈ, ਤਾਂ ਬੈਕਗ੍ਰਾਉਂਡ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਮੁਅੱਤਲ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਖੋਜ ਲਈ ਸਾਰੇ 8 ਕੋਰਾਂ ਨੂੰ ਖਾਲੀ ਕਰਦਾ ਹੈ। ਖੋਜ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਪਲਿਟ ਸਕਿੰਟ ਵਿੱਚ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਬੈਕਗ੍ਰਾਉਂਡ ਦਾ ਕੰਮ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ (ਥਰੋਟਲਿੰਗ ਪ੍ਰੋਗਰਾਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਖੋਜ ਸਵਾਲਾਂ ਦਾ ਬੈਰਾਜ ਮਹੱਤਵਪੂਰਨ ਪਿਛੋਕੜ ਦੇ ਕੰਮ ਵਿੱਚ ਦਖਲ ਨਹੀਂ ਦਿੰਦਾ)।

16 ਕੋਰ: ਭਰੋਸੇਯੋਗਤਾ ਲਈ, ਅਸੀਂ ਸਰਵਰਾਂ ਨੂੰ ਮਾਸਟਰ/ਸਲੇਵ ਸਮੂਹਾਂ ਵਿੱਚ ਵਿਵਸਥਿਤ ਕਰਦੇ ਹਾਂ। ਹਰੇਕ ਮਾਸਟਰ ਕੋਲ ਉਸਦੀ ਕਮਾਂਡ ਹੇਠ ਇੱਕ SSD ਅਤੇ ਇੱਕ EBS ਸਰਵਰ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਮੁੱਖ ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ SSD ਸਰਵਰ ਤੁਰੰਤ ਇਸਦੀ ਥਾਂ ਲੈ ਲੈਂਦਾ ਹੈ। ਲਗਭਗ ਹਰ ਸਮੇਂ, ਮਾਸਟਰ ਅਤੇ ਸਲੇਵ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਹਰੇਕ ਡੇਟਾ ਬਲਾਕ ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਸਰਵਰਾਂ 'ਤੇ ਖੋਜਿਆ ਜਾ ਸਕੇ (ਈਬੀਐਸ ਸਲੇਵ ਸਰਵਰ ਦਾ ਇੱਕ ਕਮਜ਼ੋਰ ਪ੍ਰੋਸੈਸਰ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਇਸ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਦੇ)। ਅਸੀਂ ਉਹਨਾਂ ਵਿਚਕਾਰ ਕੰਮ ਨੂੰ ਵੰਡਦੇ ਹਾਂ, ਤਾਂ ਜੋ ਸਾਡੇ ਕੋਲ ਕੁੱਲ 16 ਕੋਰ ਉਪਲਬਧ ਹੋਣ।

ਬਹੁਤ ਸਾਰੇ ਕੋਰ: ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ, ਅਸੀਂ ਸਰਵਰਾਂ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵੰਡਾਂਗੇ ਕਿ ਉਹ ਸਾਰੇ ਹਰ ਗੈਰ-ਮਾਮੂਲੀ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ। ਹਰ ਕੋਰ ਕੰਮ ਕਰੇਗਾ. [ਨੋਟ: ਅਸੀਂ ਯੋਜਨਾ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ ਅਤੇ ਖੋਜ ਦੀ ਗਤੀ ਨੂੰ 1 TB/s ਤੱਕ ਵਧਾ ਦਿੱਤਾ ਹੈ, ਲੇਖ ਦੇ ਅੰਤ ਵਿੱਚ ਨੋਟ ਦੇਖੋ].

ਸਾਦਗੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ

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

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

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

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

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

ਕਾਰਵਾਈ ਵਿੱਚ ਲੌਗ ਖੋਜ

ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਐਨੀਮੇਸ਼ਨ ਹੈ ਜੋ Scalyr ਖੋਜ ਨੂੰ ਐਕਸ਼ਨ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਡੈਮੋ ਖਾਤਾ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਹਰੇਕ ਜਨਤਕ ਗਿਥਬ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹਰ ਇਵੈਂਟ ਨੂੰ ਆਯਾਤ ਕਰਦੇ ਹਾਂ. ਇਸ ਡੈਮੋ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹਾਂ: ਲਗਭਗ 600 MB ਕੱਚੇ ਲੌਗਸ।

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

ਅੰਤ ਵਿੱਚ

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

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

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

ਸੰਪਾਦਿਤ ਕਰੋ: ਸਿਰਲੇਖ ਅਤੇ ਟੈਕਸਟ ਨੂੰ "20 GB ਪ੍ਰਤੀ ਸਕਿੰਟ 'ਤੇ ਖੋਜ" ਤੋਂ "1 TB ਪ੍ਰਤੀ ਸਕਿੰਟ 'ਤੇ ਖੋਜ" ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ ਤਾਂ ਜੋ ਪਿਛਲੇ ਕੁਝ ਸਾਲਾਂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵਾਧਾ ਦਰਸਾਇਆ ਜਾ ਸਕੇ। ਗਤੀ ਵਿੱਚ ਇਹ ਵਾਧਾ ਮੁੱਖ ਤੌਰ 'ਤੇ EC2 ਸਰਵਰਾਂ ਦੀ ਕਿਸਮ ਅਤੇ ਸੰਖਿਆ ਵਿੱਚ ਬਦਲਾਅ ਦੇ ਕਾਰਨ ਹੈ ਜੋ ਅਸੀਂ ਅੱਜ ਆਪਣੇ ਵਧੇ ਹੋਏ ਗਾਹਕ ਅਧਾਰ ਦੀ ਸੇਵਾ ਕਰਨ ਲਈ ਰੱਖ ਰਹੇ ਹਾਂ। ਜਲਦੀ ਹੀ ਅਜਿਹੀਆਂ ਤਬਦੀਲੀਆਂ ਆ ਰਹੀਆਂ ਹਨ ਜੋ ਸੰਚਾਲਨ ਕੁਸ਼ਲਤਾ ਵਿੱਚ ਇੱਕ ਹੋਰ ਨਾਟਕੀ ਵਾਧਾ ਪ੍ਰਦਾਨ ਕਰਨਗੀਆਂ, ਅਤੇ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਲਈ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਸਰੋਤ: www.habr.com