ElasticSearch ਦੇ ਨਾਲ ਇੱਕ ਹਾਈਲੋਡ ਪ੍ਰੋਜੈਕਟ ਤੇ ਲੋਡ ਓਪਟੀਮਾਈਜੇਸ਼ਨ

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

ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

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

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

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

ਸੰਖੇਪ ਪਿਛੋਕੜ

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

ਅਸੀਂ ਪੋਸਟਗ੍ਰੇਸ ਵਿੱਚ ਬਿਲਕੁਲ ਸਾਰਾ ਡਾਟਾ ਸਟੋਰ ਕੀਤਾ ਹੈ: ਲੈਣ-ਦੇਣ ਤੋਂ ਲੈ ਕੇ ਖਬਰਾਂ ਤੱਕ। ਪਰ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਗਿਣਤੀ ਵਧੀ, ਅਤੇ ਇਸਦੇ ਨਾਲ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਵੀ ਵਧੀ.

ਸਮਝਣ ਲਈ, ਸਿਰਫ ਡੈਸਕਟੌਪ ਸਾਈਟ 'ਤੇ 2017 ਵਿੱਚ ਸੈਸ਼ਨਾਂ ਦੀ ਸਾਲਾਨਾ ਸੰਖਿਆ 131 ਮਿਲੀਅਨ ਹੈ। 2018 ਵਿੱਚ - 125 ਮਿਲੀਅਨ। 2019 ਵਿੱਚ ਦੁਬਾਰਾ 130 ਮਿਲੀਅਨ। ਸਾਈਟ ਦੇ ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਅਤੇ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਹੋਰ 100-200 ਮਿਲੀਅਨ ਜੋੜੋ, ਅਤੇ ਤੁਸੀਂ ਬੇਨਤੀਆਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਪ੍ਰਾਪਤ ਕਰੇਗਾ.

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

ਅਸੀਂ ਸਮਝ ਗਏ ਕਿ ਹੋਰ ਡੇਟਾ ਸਟੋਰਾਂ ਦੀ ਲੋੜ ਸੀ ਜੋ ਸਾਡੀਆਂ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਨਗੇ ਅਤੇ PostgreSQL ਨੂੰ ਬੰਦ ਕਰ ਦੇਣਗੇ। Elasticsearch ਅਤੇ MongoDB ਨੂੰ ਸੰਭਵ ਵਿਕਲਪ ਮੰਨਿਆ ਗਿਆ ਸੀ। ਬਾਅਦ ਵਾਲੇ ਹੇਠਾਂ ਦਿੱਤੇ ਬਿੰਦੂਆਂ 'ਤੇ ਹਾਰ ਗਏ:

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

ਇਸ ਲਈ ਅਸੀਂ ਆਪਣੇ ਲਈ ਲਚਕੀਲੇ ਨੂੰ ਚੁਣਿਆ ਅਤੇ ਤਬਦੀਲੀ ਲਈ ਤਿਆਰ ਕੀਤਾ।

ਲਚਕੀਲੇ ਵਿੱਚ ਤਬਦੀਲੀ

1. ਅਸੀਂ ਵਿਕਰੀ ਖੋਜ ਸੇਵਾ ਦੇ ਪੁਆਇੰਟ ਤੋਂ ਤਬਦੀਲੀ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ। ਸਾਡੇ ਕਲਾਇੰਟ ਕੋਲ ਵਿਕਰੀ ਦੇ ਕੁੱਲ 70 ਪੁਆਇੰਟ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਸਾਈਟ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕਈ ਕਿਸਮਾਂ ਦੀਆਂ ਖੋਜਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

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

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

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

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

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

ਮਿਆਦ

ਹੁਣ ਅੱਪਡੇਟਾਂ ਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਸ਼ਰਤਾਂ ਦੇ ਅਨੁਸਾਰ, ਇਵੈਂਟ-ਅਧਾਰਿਤ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ:

1. ਵਿਕਰੀ ਅੰਕ. ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਕਿਸੇ ਬਾਹਰੀ ਸਰੋਤ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਤੁਰੰਤ ਅਪਡੇਟ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ।
2. ਖ਼ਬਰਾਂ। ਜਿਵੇਂ ਹੀ ਸਾਈਟ 'ਤੇ ਕੋਈ ਵੀ ਖਬਰ ਐਡਿਟ ਹੁੰਦੀ ਹੈ, ਇਹ ਆਪਣੇ ਆਪ ਈਲਾਸਟਿਕ 'ਤੇ ਭੇਜ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

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

ਏਕੀਕਰਣ ਢੰਗ

ਲਚਕੀਲੇ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੇ 2 ਤਰੀਕੇ ਹਨ:

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

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

ਤੁਲਨਾ ਲਈ ਕੁਝ ਨੰਬਰ:

• ਬਿਨਾਂ ਗਰੁੱਪਿੰਗ ਦੇ 20 ਥਰਿੱਡਾਂ ਵਿੱਚ ਪੋਸਟਗ੍ਰੇਸ ਬਾਉਂਟੀ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ: 460713 ਸਕਿੰਟਾਂ ਵਿੱਚ 42 ਰਿਕਾਰਡ
• 10 ਥਰਿੱਡਾਂ ਲਈ ਲਚਕੀਲੇ + ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲ ਕਲਾਇੰਟ + 1000 ਤੱਤਾਂ ਲਈ ਬੈਚ: 596749 ਸਕਿੰਟਾਂ ਵਿੱਚ 11 ਰਿਕਾਰਡ
• 10 ਥਰਿੱਡਾਂ ਲਈ ਲਚਕੀਲੇ + ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲ ਕਲਾਇੰਟ + 1000 ਤੱਤਾਂ ਲਈ ਬੈਚ: 23801684 ਮਿੰਟਾਂ ਵਿੱਚ 4 ਐਂਟਰੀਆਂ

ਹੁਣ ਅਸੀਂ ਇੱਕ HTTP ਬੇਨਤੀ ਮੈਨੇਜਰ ਲਿਖਿਆ ਹੈ ਜੋ JSON ਨੂੰ ਬੈਚ / ਬੈਚ ਨਹੀਂ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਵੀ HTTP ਕਲਾਇੰਟ ਦੁਆਰਾ ਭੇਜਦਾ ਹੈ, ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ. ਤੁਸੀਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸਮਕਾਲੀ ਜਾਂ ਅਸਿੰਕਰੋਨਸ ਭੇਜਣ ਦੀ ਚੋਣ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।

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

ਵੱਡੀ ਤਰੱਕੀ

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

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

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

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

ਸਿੱਟਾ/ਸੰਕਲਪ

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

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

ਜੇ ਸਾਨੂੰ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਪੂਰੇ-ਪਾਠ ਖੋਜ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਜੇ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਖੋਜ ਮਾਪਦੰਡ ਹਨ, ਤਾਂ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਸਨੂੰ ਲਚਕੀਲੇ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

⌘⌘⌘

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

ਸਰੋਤ: www.habr.com