Redis ਲਈ [ਸੰਭਾਵੀ] ਬਦਲ ਵਜੋਂ KeyDB

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

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

ਮੁੱਦੇ

ਆਮ ਤੌਰ 'ਤੇ Redis ਬਾਰੇ

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

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

ਮੈਂ ਇਸ ਜਾਂ ਉਸ ਰਾਏ ਦਾ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕਰਾਂਗਾ। ਇਸਦੀ ਬਜਾਏ, ਮੈਂ ਆਪਣਾ ਖਾਸ ਕੇਸ ਸਾਂਝਾ ਕਰਾਂਗਾ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ ਹੈ।

ਸਾਡਾ ਕੇਸ

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

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

ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਸੀ:

ਨਵੀਂ ਰੀਲੀਕ ਨੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕੀਤੀ:

ਇੱਥੇ ਓਪਰੇਸ਼ਨ ਲਈ ਅੰਕੜੇ ਹਨ: get Redis ਵਿੱਚ:

ਸਮੱਸਿਆ ਦੀ ਵਿਕਾਸ ਟੀਮ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਰਿਪੋਰਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ "ਇਸ ਸਮੇਂ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।" ਇਸ ਤਰ੍ਹਾਂ ਓਪਰੇਸ਼ਨ ਵਾਲੇ ਪਾਸੇ ਇੱਕ ਹੱਲ ਦੀ ਖੋਜ ਸ਼ੁਰੂ ਹੋਈ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤਾ KeyDB ਜਵਾਬ ਸੀ।

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

KeyDB 'ਤੇ ਇੱਕ ਤੁਰੰਤ ਨਜ਼ਰ

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

ਉਹਨਾਂ ਲਈ ਜੋ KeyDB ਨਾਲ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਣੂ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਇੱਕ ਚੰਗਾ ਹੈ ਮੀਡੀਅਮ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਲੇਖ, ਜੋ ਕਿ DBMS ਪੇਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦੇ "ਮਾਪਿਆਂ" - Redis ਨਾਲ ਤੁਲਨਾ ਕਰਦੇ ਹੋਏ ਸੰਖੇਪ ਮਾਪਦੰਡ ਪੇਸ਼ ਕਰਦਾ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ ਸਾਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਸੰਭਾਵੀ ਹੱਲ ਦੁਆਰਾ KeyDB ਵੱਲ ਆਕਰਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਸਾਨੂੰ ਕੁਝ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਸੀ. ਕੀਡੀਬੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਹੇਠਾਂ ਦਿੱਤੇ ਫਾਇਦਿਆਂ ਦਾ ਵਾਅਦਾ ਕੀਤਾ ਗਿਆ ਹੈ:

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

GitHub 'ਤੇ 3 ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਸਿਤਾਰੇ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ ਵੀ ਉਤਸ਼ਾਹਿਤ ਨਜ਼ਰ ਆਏ। ਐਪਲੀਕੇਸ਼ਨ ਕਾਫ਼ੀ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਸਤ ਅਤੇ ਸਮਰਥਿਤ ਹੈ, ਜੋ ਕਮਿਟਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਮੁੱਦਿਆਂ ਵਿੱਚ ਸੰਚਾਰ, ਅਤੇ ਨਾਲ ਹੀ ਬੰਦ (ਸਵੀਕਾਰ ਕੀਤੇ) ਪੀ.ਆਰ. ਸਾਰੇ ਮੋਰਚਿਆਂ 'ਤੇ ਮੁੱਖ ਰੱਖਿਅਕ ਦਾ ਜਵਾਬ ਹਮੇਸ਼ਾ ਦੋਸਤਾਨਾ ਅਤੇ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਦਲੀਲਾਂ ਸਨ.

ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਨਤੀਜੇ

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

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

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

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

ਇਸ ਸਭ ਲਈ ਧੰਨਵਾਦ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਨਵੇਂ DBMS ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲ ਸਕਦੇ, ਪਰ ਇੱਕ "ਸਥਿਰਤਾ ਉਪਾਅ" ਦੇ ਰੂਪ ਵਿੱਚ ਤੁਸੀਂ ਇਸਨੂੰ ਕੁਝ ਸਮੇਂ ਲਈ ਲੜਾਈ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ ਇਸ ਫਾਰਮ ਵਿੱਚ ਛੱਡ ਸਕਦੇ ਹੋ. ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵਾਧਾ (ਜਾਂ ਕੋਈ ਬਦਲਾਅ) ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ ਹੈ ਮੂਲ ਰੂਪ ਵਿੱਚ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਲਈ ਜ਼ਿੰਮੇਵਾਰ KeyDB ਪੈਰਾਮੀਟਰ (server-threads), ਇੱਕ ਦੇ ਬਰਾਬਰ ਹੈ, ਜੋ ਕਿ ਹੈ DBMS Redis ਵਾਂਗ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ.

ਨਵੀਂ ਐਪਲੀਕੇਸ਼ਨ (KeyDB ਦੇ ਨਾਲ) 'ਤੇ ਸਵਿਚ ਕਰਨ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਜੀਵਨ ਦੇ ਕੁਝ ਸਮੇਂ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਉਸੇ ਮਾਪਦੰਡਾਂ ਨਾਲ ਲੋਡ ਟੈਸਟਿੰਗ ਨੂੰ ਦੁਹਰਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਜੋ Redis ਲਈ ਵਰਤੇ ਗਏ ਸਨ। ਇਸ ਦੇ ਨਤੀਜੇ ਕੀ ਨਿਕਲੇ?...

CPU ਖਪਤ ਗ੍ਰਾਫ ਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਕੋਰ ਦੀ "ਛੱਤ" ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦਾ ਖਾਤਮਾ ਤੁਰੰਤ ਧਿਆਨ ਦੇਣ ਯੋਗ ਬਣ ਗਿਆ: ਪ੍ਰਕਿਰਿਆ ਨੇ ਉਪਲਬਧ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ:

ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੈਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਾਫ਼ੀ ਜ਼ੋਰਦਾਰ ਢੰਗ ਨਾਲ "ਤਸੀਹੇ ਦੇਣ" ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਅਤੇ ਤਿੰਨ ਕੋਰਾਂ ਤੱਕ ਦੀ ਖਪਤ ਨੂੰ ਦੇਖਿਆ ...

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

ਨਵੇਂ ਡੇਟਾਬੇਸ (KeyDB) ਦੀ ਲੇਟੈਂਸੀ ਵੀ ਵਿਗੜ ਗਈ, ਪਰ ਸਵੀਕਾਰਯੋਗ ਮੁੱਲਾਂ ਦੇ ਅੰਦਰ ਰਹੀ:

ਹੇਠਾਂ ਦਿੱਤਾ ਗ੍ਰਾਫ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀਡੀਬੀ ਨੂੰ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਆਪਣੇ ਆਪ ਸਮਾਨ ਹੈ:

ਇਹਨਾਂ ਸਿੰਥੈਟਿਕ ਟੈਸਟਾਂ ਨੂੰ ਸੰਖੇਪ ਕਰਨ ਲਈ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ Redis ਅਤੇ KeyDB ਦੋਵੇਂ ਸਮਾਨਾਂਤਰ ਕੁਨੈਕਸ਼ਨਾਂ (40+) ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧੇ ਦੇ ਨਾਲ ਲੇਟੈਂਸੀ (1000 ms+) ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਗਿਰਾਵਟ ਦਿਖਾਉਂਦੇ ਹਨ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਘੱਟ ਕੁਨੈਕਸ਼ਨਾਂ (400+) ਦੇ ਨਾਲ ਵੀ Redis ਦੀ ਲੇਟੈਂਸੀ ਨੂੰ "ਬਰਬਾਦ" ਕਰਨ ਦੇ ਯੋਗ ਸੀ, ਹਾਲਾਂਕਿ KeyDB ਲਈ ਅਜਿਹਾ ਲੋਡ ਸਵੀਕਾਰਯੋਗ ਰਿਹਾ।

ਸਿੱਟਾ

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

ਪਰਵਾਸ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹੋਏ, ਜੋ ਕਿ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਸੀ, ਸਾਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਇਆ ਇਸ ਲਈ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ, ਜਿਸਦੀ KeyDB ਦੇ ਲੇਖਕਾਂ ਦੇ ਗ੍ਰਾਫਾਂ ਨੂੰ ਦੇਖ ਕੇ ਉਮੀਦ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ... ਹਾਲਾਂਕਿ, ਇਹ ਸਿਰਫ ਸਾਡਾ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਬਦਨਾਮ ਆਰਕੀਟੈਕਚਰ ਸਮੇਤ ਬਹੁਤ ਸਾਰੇ ਵਿਵਹਾਰ ਹੋ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ , ਬਹੁਤ ਸਾਰੀਆਂ ਕਮਾਂਡਾਂ get ਕੁੱਲ ਪੁੱਛਗਿੱਛਾਂ ਦੇ ਵਧੇਰੇ ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ ਵਿਕਲਪ ਦੀ ਬਜਾਏ Redis ਵਿੱਚ mget...)। ਫਿਰ ਵੀ, ਅਸੀਂ ਸਕਾਰਾਤਮਕ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਉਪਯੋਗੀ ਫੰਕਸ਼ਨ ਜੋ ਅਸੀਂ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਲਾਗੂ ਕਰਾਂਗੇ।

ਆਮ ਤੌਰ 'ਤੇ, KeyDB ਹੋਨਹਾਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇਸ DBMS ਨਾਲ ਵਿਹਾਰਕ ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ (ਅਤੇ ਸਾਨੂੰ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਹਾਸਲ ਕਰਨਾ ਹੈ!) ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਖੁਦ ਵਿਕਸਿਤ ਕਰਨਾ ਹੈ, ਅਸੀਂ ਇਸਨੂੰ ਹੋਰ ਸਥਿਤੀਆਂ ਵਿੱਚ ਵਰਤਣ ਦੀ ਸੰਭਾਵਨਾ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ।

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

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕੈਸੈਂਡਰਾ ਦਾ ਪ੍ਰਵਾਸ: ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਹੱਲ";
• «ਮੋਂਗੋਡੀਬੀ ਦਾ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਹਿਜ ਪ੍ਰਵਾਸ";
• «RabbitMQ ਦਾ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਹਿਜ ਪ੍ਰਵਾਸ".

ਸਰੋਤ: www.habr.com