VKontakte ਸੁਨੇਹਾ ਡੇਟਾਬੇਸ ਨੂੰ ਸਕ੍ਰੈਚ ਤੋਂ ਦੁਬਾਰਾ ਲਿਖੋ ਅਤੇ ਬਚੋ

ਸਾਡੇ ਉਪਭੋਗਤਾ ਥਕਾਵਟ ਨੂੰ ਜਾਣੇ ਬਿਨਾਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਸੰਦੇਸ਼ ਲਿਖਦੇ ਹਨ।

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

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

ਸਾਡੇ ਲਈ, ਇਹ ਪਲ ਡੇਢ ਸਾਲ ਪਹਿਲਾਂ ਆਇਆ ਸੀ. ਅਸੀਂ ਇਸ ਤੱਕ ਕਿਵੇਂ ਆਏ ਅਤੇ ਅੰਤ ਵਿੱਚ ਕੀ ਹੋਇਆ - ਅਸੀਂ ਤੁਹਾਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਦੱਸਦੇ ਹਾਂ.

ਪਿਛੋਕੜ

ਪਹਿਲੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ, VKontakte ਸੁਨੇਹਿਆਂ ਨੇ PHP ਬੈਕਐਂਡ ਅਤੇ MySQL ਦੇ ਸੁਮੇਲ 'ਤੇ ਕੰਮ ਕੀਤਾ। ਇਹ ਇੱਕ ਛੋਟੇ ਵਿਦਿਆਰਥੀ ਦੀ ਵੈਬਸਾਈਟ ਲਈ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਧਾਰਨ ਹੱਲ ਹੈ. ਹਾਲਾਂਕਿ, ਇਹ ਸਾਈਟ ਬੇਕਾਬੂ ਹੋ ਗਈ ਅਤੇ ਆਪਣੇ ਲਈ ਡੇਟਾ ਢਾਂਚੇ ਦੇ ਅਨੁਕੂਲਨ ਦੀ ਮੰਗ ਕਰਨ ਲੱਗੀ।

2009 ਦੇ ਅੰਤ ਵਿੱਚ, ਪਹਿਲਾ ਟੈਕਸਟ-ਇੰਜਣ ਰਿਪੋਜ਼ਟਰੀ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ 2010 ਵਿੱਚ ਸੁਨੇਹੇ ਇਸ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤੇ ਗਏ ਸਨ।

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

ਇਹ ਦੋ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਪੱਤਰ ਵਿਹਾਰ ਲਈ ਕਾਫ਼ੀ ਸੀ। ਅੰਦਾਜ਼ਾ ਲਗਾਓ ਕਿ ਅੱਗੇ ਕੀ ਹੋਇਆ?

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

"PHP, ਆਓ ਚੈਟ ਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜੀਏ," ਉਪਭੋਗਤਾ ਕਹਿੰਦਾ ਹੈ।
"ਚਲੋ, {username}," PHP ਕਹਿੰਦਾ ਹੈ।

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

2015 ਦੇ ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਕਮਿਊਨਿਟੀ ਸੁਨੇਹੇ ਲਾਂਚ ਕੀਤੇ, ਅਤੇ 2016 ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਅਸੀਂ ਉਹਨਾਂ ਲਈ ਇੱਕ API ਲਾਂਚ ਕੀਤਾ। ਭਾਈਚਾਰਿਆਂ ਵਿੱਚ ਵੱਡੇ ਚੈਟਬੋਟਸ ਦੇ ਆਗਮਨ ਦੇ ਨਾਲ, ਲੋਡ ਵੰਡ ਨੂੰ ਵੀ ਭੁੱਲਣਾ ਸੰਭਵ ਸੀ।

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

2016 ਵਿੱਚ ਸੁਨੇਹਾ ਇੰਜਣ ਚੈਟ-ਮੈਂਬਰਾਂ ਅਤੇ ਮੈਂਬਰ-ਚੈਟਾਂ ਦੀਆਂ 100 ਉਦਾਹਰਣਾਂ, ਅਤੇ 8000 ਟੈਕਸਟ-ਇੰਜਣ ਹਨ। ਉਹ ਇੱਕ ਹਜ਼ਾਰ ਸਰਵਰਾਂ 'ਤੇ ਹੋਸਟ ਕੀਤੇ ਗਏ ਸਨ, ਹਰ ਇੱਕ 64 GB ਮੈਮੋਰੀ ਦੇ ਨਾਲ। ਪਹਿਲੇ ਐਮਰਜੈਂਸੀ ਉਪਾਅ ਵਜੋਂ, ਅਸੀਂ ਮੈਮੋਰੀ ਨੂੰ ਹੋਰ 32 GB ਤੱਕ ਵਧਾਇਆ ਹੈ। ਅਸੀਂ ਪੂਰਵ ਅਨੁਮਾਨਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਹੈ। ਸਖ਼ਤ ਤਬਦੀਲੀਆਂ ਦੇ ਬਿਨਾਂ, ਇਹ ਇੱਕ ਹੋਰ ਸਾਲ ਲਈ ਕਾਫ਼ੀ ਹੋਵੇਗਾ। ਤੁਹਾਨੂੰ ਜਾਂ ਤਾਂ ਹਾਰਡਵੇਅਰ ਨੂੰ ਫੜਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਡੇਟਾਬੇਸ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ.

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

ਨਵਾਂ ਸੰਕਲਪ

ਨਵੀਂ ਪਹੁੰਚ ਦਾ ਕੇਂਦਰੀ ਤੱਤ ਗੱਲਬਾਤ ਹੈ। ਇੱਕ ਚੈਟ ਵਿੱਚ ਸੁਨੇਹਿਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੁੰਦੀ ਹੈ ਜੋ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦੇ ਹਨ। ਉਪਭੋਗਤਾ ਕੋਲ ਚੈਟਾਂ ਦੀ ਸੂਚੀ ਹੈ।

ਲੋੜੀਂਦੇ ਘੱਟੋ-ਘੱਟ ਦੋ ਨਵੇਂ ਡੇਟਾਬੇਸ ਹਨ:

• ਚੈਟ-ਇੰਜਣ. ਇਹ ਚੈਟ ਵੈਕਟਰਾਂ ਦਾ ਭੰਡਾਰ ਹੈ। ਹਰੇਕ ਚੈਟ ਵਿੱਚ ਸੁਨੇਹਿਆਂ ਦਾ ਇੱਕ ਵੈਕਟਰ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦਾ ਹੈ। ਹਰੇਕ ਸੁਨੇਹੇ ਵਿੱਚ ਇੱਕ ਟੈਕਸਟ ਅਤੇ ਚੈਟ ਦੇ ਅੰਦਰ ਇੱਕ ਵਿਲੱਖਣ ਸੁਨੇਹਾ ਪਛਾਣਕਰਤਾ ਹੁੰਦਾ ਹੈ - chat_local_id.
• ਉਪਭੋਗਤਾ-ਇੰਜਣ. ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਵੈਕਟਰਾਂ ਦੀ ਸਟੋਰੇਜ ਹੈ - ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਲਿੰਕ. ਹਰੇਕ ਉਪਭੋਗਤਾ ਕੋਲ peer_id (ਇੰਟਰਲੋਕਿਊਟਰ - ਹੋਰ ਉਪਭੋਗਤਾ, ਮਲਟੀ-ਚੈਟ ਜਾਂ ਸਮੁਦਾਏ) ਅਤੇ ਸੰਦੇਸ਼ਾਂ ਦਾ ਇੱਕ ਵੈਕਟਰ ਹੁੰਦਾ ਹੈ। ਹਰੇਕ ਪੀਅਰ_ਆਈਡੀ ਵਿੱਚ ਸੁਨੇਹਿਆਂ ਦਾ ਇੱਕ ਵੈਕਟਰ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦਾ ਹੈ। ਹਰੇਕ ਸੁਨੇਹੇ ਵਿੱਚ ਇੱਕ ਚੈਟ_ਲੋਕਲ_ਆਈਡੀ ਅਤੇ ਉਸ ਉਪਭੋਗਤਾ ਲਈ ਇੱਕ ਵਿਲੱਖਣ ਸੁਨੇਹਾ ID ਹੈ - user_local_id।

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

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

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

ਨਵੀਂ ਸਕੀਮ ਵਿੱਚ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਣਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

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

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

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

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

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

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

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

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

ਡਾਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ

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

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

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

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

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

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

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

ਅਸੀਂ ਆਯਾਤ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਡੇਟਾ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

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

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

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

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

Результаты

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

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

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

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

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

ਸਰੋਤ: www.habr.com