ਨਵੀਂ ਪੀੜ੍ਹੀ ਦਾ ਬਿਲਿੰਗ ਆਰਕੀਟੈਕਚਰ: ਟਰਾਂਟੂਲ ਵਿੱਚ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਤਬਦੀਲੀ

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

ਤਰਨਟੂਲ ਦਾ ਇਸ ਨਾਲ ਕੀ ਲੈਣਾ ਦੇਣਾ ਹੈ? ਉਹ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨਗੇ ਓਲੇਗ ਇਵਲੇਵ и ਆਂਦਰੇ ਕਯਾਜ਼ੇਵ. ਓਲੇਗ ਕੰਪਨੀ ਦਾ ਮੁੱਖ ਆਰਕੀਟੈਕਟ ਹੈ ਮੇਗਾਫੋਨ ਵਿਦੇਸ਼ੀ ਕੰਪਨੀਆਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦੇ ਵਿਆਪਕ ਤਜ਼ਰਬੇ ਦੇ ਨਾਲ, ਐਂਡਰੀ ਵਪਾਰ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਨਿਰਦੇਸ਼ਕ ਹੈ। 'ਤੇ ਉਨ੍ਹਾਂ ਦੀ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਤੋਂ ਤਰਨਟੂਲ ਕਾਨਫਰੰਸ 2018 ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਕਾਰਪੋਰੇਸ਼ਨਾਂ ਵਿੱਚ R&D ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ, Tarantool ਕੀ ਹੈ, ਕਿਵੇਂ ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਅਤੇ ਵਿਸ਼ਵੀਕਰਨ ਦੀ ਰੁਕਾਵਟ ਕੰਪਨੀ ਵਿੱਚ ਇਸ ਡੇਟਾਬੇਸ ਦੀ ਦਿੱਖ ਲਈ ਜ਼ਰੂਰੀ ਸ਼ਰਤਾਂ ਬਣ ਗਈ, ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ, ਆਰਕੀਟੈਕਚਰਲ ਪਰਿਵਰਤਨ, ਅਤੇ ਕਿਵੇਂ MegaFon ਦਾ ਟੈਕਨੋਸਟੈਕ Netflix ਵਰਗਾ ਹੈ। , ਗੂਗਲ ਅਤੇ ਐਮਾਜ਼ਾਨ.

ਪ੍ਰੋਜੈਕਟ "ਯੂਨੀਫਾਈਡ ਬਿਲਿੰਗ"

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

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

MegaFon ਇੱਕ ਵਿੱਚ ਅੱਠ ਕੰਪਨੀਆਂ ਹਨ. 2009 ਵਿੱਚ, ਪੁਨਰਗਠਨ ਪੂਰਾ ਹੋਇਆ: ਪੂਰੇ ਰੂਸ ਵਿੱਚ ਸ਼ਾਖਾਵਾਂ ਇੱਕ ਸਿੰਗਲ ਕੰਪਨੀ, ਮੇਗਾਫੋਨ ਓਜੇਐਸਸੀ (ਹੁਣ ਪੀਜੇਐਸਸੀ) ਵਿੱਚ ਮਿਲਾ ਦਿੱਤੀਆਂ ਗਈਆਂ। ਇਸ ਤਰ੍ਹਾਂ, ਕੰਪਨੀ ਕੋਲ ਉਹਨਾਂ ਦੇ ਆਪਣੇ "ਕਸਟਮ" ਹੱਲ, ਸ਼ਾਖਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਸੰਗਠਨਾਤਮਕ ਢਾਂਚੇ, ਆਈਟੀ ਅਤੇ ਮਾਰਕੀਟਿੰਗ ਦੇ ਨਾਲ 8 ਬਿਲਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਹਨ।

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

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

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

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

ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ

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

ਸਕੇਲੇਬਿਲਟੀ

ਜੇ ਇਹ ਪਹਿਲਾਂ ਸੀ, ਤਾਂ ਆਓ, ਕਹੀਏ 8 ਮਿਲੀਅਨ ਗਾਹਕਾਂ ਲਈ 15 ਬਿਲਿੰਗ, ਅਤੇ ਹੁਣ ਇਸ ਨੂੰ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ 100 ਮਿਲੀਅਨ ਗਾਹਕ ਅਤੇ ਹੋਰ - ਲੋਡ ਵੱਧ ਤੀਬਰਤਾ ਦਾ ਇੱਕ ਕ੍ਰਮ ਹੈ.

ਅਸੀਂ Mail.ru ਜਾਂ Netflix ਵਰਗੇ ਵੱਡੇ ਇੰਟਰਨੈਟ ਪਲੇਅਰਾਂ ਦੇ ਪੈਮਾਨੇ ਵਿੱਚ ਤੁਲਨਾਤਮਕ ਬਣ ਗਏ ਹਾਂ।

ਪਰ ਲੋਡ ਅਤੇ ਗਾਹਕਾਂ ਦੇ ਅਧਾਰ ਨੂੰ ਵਧਾਉਣ ਲਈ ਅੱਗੇ ਦੀ ਲਹਿਰ ਨੇ ਸਾਡੇ ਲਈ ਗੰਭੀਰ ਚੁਣੌਤੀਆਂ ਖੜ੍ਹੀਆਂ ਕੀਤੀਆਂ ਹਨ।

ਸਾਡੇ ਵਿਸ਼ਾਲ ਦੇਸ਼ ਦਾ ਭੂਗੋਲ

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

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

ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ

ਇਹ ਕੇਂਦਰੀਕਰਨ ਦਾ ਦੂਜਾ ਪੱਖ ਹੈ।

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

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

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

ਵਿਸ਼ਵ ਅਨੁਭਵ

ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ ਕਿ ਸਾਨੂੰ ਗਲੋਬਲ ਟੈਲੀਕਾਮ ਵਿੱਚ ਇੱਕ ਵੀ ਹਵਾਲਾ ਨਹੀਂ ਮਿਲਿਆ।

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

ਆਰਕੀਟੈਕਚਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਦੇ ਆਰਕੀਟੈਕਟਾਂ - IBM ਦੀ ਅਗਵਾਈ ਵਿੱਚ ਇੱਕ ਡਰੀਮ ਟੀਮ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ। ਇਹ ਲੋਕ ਸਹੀ ਢੰਗ ਨਾਲ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਅਸੀਂ ਕੀ ਕਰ ਰਹੇ ਸੀ ਅਤੇ ਸਾਡੇ ਆਰਕੀਟੈਕਚਰ ਲਈ ਕੁਝ ਖਾਸ ਗਿਆਨ ਲਿਆ ਸਕਦੇ ਹਨ।

ਸਕੇਲ

ਉਦਾਹਰਣ ਲਈ ਕੁਝ ਨੰਬਰ।

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

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

2 ਬਿਲੀਅਨ ਲੈਣ-ਦੇਣ ਬਕਾਇਆ ਰੋਜ਼ਾਨਾ ਬਦਲਦਾ ਹੈ - ਇਹ ਭੁਗਤਾਨ, ਖਰਚੇ, ਕਾਲਾਂ ਅਤੇ ਹੋਰ ਇਵੈਂਟ ਹਨ। 200 TB ਡਾਟਾ ਸਰਗਰਮੀ ਨਾਲ ਬਦਲ ਰਿਹਾ ਹੈ, ਥੋੜਾ ਹੌਲੀ ਬਦਲੋ ਡਾਟਾ ਦਾ 8 PB, ਅਤੇ ਇਹ ਇੱਕ ਪੁਰਾਲੇਖ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਸਿੰਗਲ ਬਿਲਿੰਗ ਵਿੱਚ ਲਾਈਵ ਡੇਟਾ ਹੈ। ਡਾਟਾ ਸੈਂਟਰ ਦੁਆਰਾ ਸਕੇਲ - 5 ਸਾਈਟਾਂ 'ਤੇ 14 ਹਜ਼ਾਰ ਸਰਵਰ.

ਤਕਨਾਲੋਜੀ ਸਟੈਕ

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

ਸਟੈਕ ਹੋਰ ਪ੍ਰਮੁੱਖ ਖਿਡਾਰੀਆਂ ਦੇ ਸਟੈਕ ਦੇ ਸਮਾਨ ਹੈ: Netflix, Twitter, Viber. ਇਸ ਵਿੱਚ 6 ਭਾਗ ਹੁੰਦੇ ਹਨ, ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਛੋਟਾ ਕਰਨਾ ਅਤੇ ਏਕੀਕਰਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਲਚਕਤਾ ਚੰਗੀ ਹੈ, ਪਰ ਇੱਕ ਵੱਡੇ ਕਾਰਪੋਰੇਸ਼ਨ ਵਿੱਚ ਏਕੀਕਰਨ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਰਸਤਾ ਨਹੀਂ ਹੈ।

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

ਤਰਨਟੂਲ ਕਿਉਂ?

ਇੱਥੇ 4 ਸਧਾਰਨ ਮਾਪਦੰਡ ਹਨ ਕਿ ਅਸੀਂ ਇਸ ਡੇਟਾਬੇਸ ਨੂੰ ਕਿਉਂ ਚੁਣਿਆ ਹੈ।

ਸਪੀਡ. ਅਸੀਂ MegaFon ਉਦਯੋਗਿਕ ਪ੍ਰਣਾਲੀਆਂ 'ਤੇ ਲੋਡ ਟੈਸਟ ਕਰਵਾਏ। Tarantool ਜਿੱਤਿਆ - ਇਸ ਨੇ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਦਿਖਾਇਆ.

ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਹੋਰ ਸਿਸਟਮ MegaFon ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਮੌਜੂਦਾ ਮੈਮੋਰੀ ਹੱਲ ਇੰਨੇ ਲਾਭਕਾਰੀ ਹਨ ਕਿ ਕੰਪਨੀ ਦੇ ਭੰਡਾਰ ਕਾਫ਼ੀ ਤੋਂ ਵੱਧ ਹਨ। ਪਰ ਅਸੀਂ ਇੱਕ ਨੇਤਾ ਨਾਲ ਨਜਿੱਠਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ, ਨਾ ਕਿ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨਾਲ ਜੋ ਪਛੜ ਰਿਹਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਲੋਡ ਟੈਸਟ ਵੀ ਸ਼ਾਮਲ ਹੈ।

ਤਰਨਟੂਲ ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਵੀ ਕੰਪਨੀ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

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

ਇੱਕ ਹੋਰ ਵਧੀਆ ਵਿਸ਼ੇਸ਼ਤਾ ਜਿਸ ਨੇ ਸਾਡੀ ਪਸੰਦ ਨੂੰ ਥੋੜ੍ਹਾ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਉਹ ਇਹ ਹੈ ਕਿ Tarantool ਹੋਰ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਮੈਮੋਰੀ ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਹ ਦਿਖਾਉਂਦਾ ਹੈ ਵੱਧ ਤੋਂ ਵੱਧ ਕੁਸ਼ਲਤਾ.

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

ਅਸੀਂ ਆਪਣਾ ਸਮਾਂ ਅਤੇ ਵਿੱਤ ਨਿਵੇਸ਼ ਕੀਤਾ, ਅਤੇ Mail.ru ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਅਸੀਂ ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੰਸਕਰਣ ਬਣਾਇਆ, ਜੋ ਹੁਣ ਕਈ ਹੋਰ ਕੰਪਨੀਆਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

Tarantool-Enterprise ਨੇ ਸੁਰੱਖਿਆ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਲਾਗਿੰਗ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸੰਤੁਸ਼ਟ ਕੀਤਾ ਹੈ।

ਭਾਈਵਾਲੀ

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

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

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

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

ਜਿੱਥੇ ਅਸੀਂ ਤਰਨਟੂਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ

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

ਉਦਾਹਰਨ ਲਈ, ਵਿਕਰੀ ਇੰਟਰਫੇਸ ਵਿੱਚ ਪਤਾ ਕੈਟਾਲਾਗ. ਓਰੇਕਲ 'ਤੇ, ਲੋੜੀਂਦੇ ਪਤੇ ਦੀ ਖੋਜ ਕਰਨ ਵਿੱਚ 12-13 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। - ਅਸੁਵਿਧਾਜਨਕ ਨੰਬਰ. ਜਦੋਂ ਅਸੀਂ Tarantool 'ਤੇ ਸਵਿੱਚ ਕਰਦੇ ਹਾਂ, Oracle ਨੂੰ ਕੰਸੋਲ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਡੇਟਾਬੇਸ ਨਾਲ ਬਦਲਦੇ ਹਾਂ, ਅਤੇ ਉਹੀ ਖੋਜ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ 200x ਸਪੀਡਅੱਪ ਮਿਲਦਾ ਹੈ! ਤੀਜੇ ਅੱਖਰ ਤੋਂ ਬਾਅਦ ਸ਼ਹਿਰ ਦਿਸਦਾ ਹੈ। ਹੁਣ ਅਸੀਂ ਇੰਟਰਫੇਸ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਪਹਿਲੇ ਦੇ ਬਾਅਦ ਵਾਪਰਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਜਵਾਬ ਦੀ ਗਤੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਹੈ - ਸਕਿੰਟਾਂ ਦੀ ਬਜਾਏ ਮਿਲੀਸਕਿੰਟ।

ਦੂਜੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਟਰੈਡੀ ਥੀਮ ਹੈ ਜਿਸਨੂੰ ਦੋ-ਸਪੀਡ ਆਈ.ਟੀ. ਅਜਿਹਾ ਇਸ ਲਈ ਕਿਉਂਕਿ ਹਰ ਕੋਨੇ ਤੋਂ ਸਲਾਹਕਾਰ ਕਹਿੰਦੇ ਹਨ ਕਿ ਕਾਰਪੋਰੇਸ਼ਨਾਂ ਨੂੰ ਉੱਥੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਸ਼ਾਇਦ ਮੇਗਾਫੋਨ 'ਤੇ ਟਾਰਨਟੂਲ ਦੀ ਮੁੱਖ ਭੂਮਿਕਾ ਹੈ।

ਜਿੱਥੇ ਅਸੀਂ ਤਰਨਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੈ

ਜੇਕਰ ਅਸੀਂ ਆਪਣੇ ਸਫਲ ਬਿਲਿੰਗ ਪ੍ਰੋਜੈਕਟ ਦੀ ਤੁਲਨਾ Deutsche Telekom, Svyazcom, Vodafone India ਦੇ ਪਰਿਵਰਤਨ ਪ੍ਰੋਗਰਾਮਾਂ ਨਾਲ ਕਰੀਏ, ਤਾਂ ਇਹ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਗਤੀਸ਼ੀਲ ਅਤੇ ਰਚਨਾਤਮਕ ਹੈ। ਇਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਨਾ ਸਿਰਫ਼ MegaFon ਅਤੇ ਇਸਦੀ ਬਣਤਰ ਨੂੰ ਬਦਲਿਆ ਗਿਆ ਸੀ, ਸਗੋਂ Mail.ru 'ਤੇ Tarantool-Enterprise ਵੀ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ, ਅਤੇ ਸਾਡੇ ਵਿਕਰੇਤਾ Nexign (ਪਹਿਲਾਂ ਪੀਟਰ-ਸਰਵਿਸ) - BSS ਬਾਕਸ (ਇੱਕ ਬਾਕਸਡ ਬਿਲਿੰਗ ਹੱਲ)।

ਇਹ, ਇੱਕ ਅਰਥ ਵਿੱਚ, ਰੂਸੀ ਮਾਰਕੀਟ ਲਈ ਇੱਕ ਇਤਿਹਾਸਕ ਪ੍ਰੋਜੈਕਟ ਹੈ. ਇਸਦੀ ਤੁਲਨਾ ਫਰੈਡਰਿਕ ਬਰੂਕਸ ਦੀ ਕਿਤਾਬ "ਦਿ ਮਿਥੀਕਲ ਮੈਨ-ਮੰਥ" ਵਿੱਚ ਵਰਣਨ ਕੀਤੀ ਗਈ ਗੱਲ ਨਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਫਿਰ, 60 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, IBM ਨੇ ਮੇਨਫ੍ਰੇਮ ਲਈ ਨਵਾਂ OS/360 ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿਕਸਿਤ ਕਰਨ ਲਈ 5 ਲੋਕਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕੀਤਾ। ਸਾਡੇ ਕੋਲ ਘੱਟ - 000 ਹਨ, ਪਰ ਸਾਡੀਆਂ ਵੈਸਟਾਂ ਵਿੱਚ ਹਨ, ਅਤੇ ਓਪਨ ਸੋਰਸ ਅਤੇ ਨਵੇਂ ਪਹੁੰਚਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ।

ਹੇਠਾਂ ਬਿਲਿੰਗ ਦੇ ਡੋਮੇਨ ਹਨ ਜਾਂ, ਵਧੇਰੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ, ਕਾਰੋਬਾਰੀ ਪ੍ਰਣਾਲੀਆਂ ਹਨ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਦੇ ਲੋਕ CRM ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦੇ ਹਨ। ਹਰੇਕ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੋਰ ਸਿਸਟਮ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਓਪਨ API, API ਗੇਟਵੇ।

ਓਪਨ API

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

ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕੀ ਅਸੀਂ SSO ਵਿੱਚ Mail.ru ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹਾਂ - ਮੁੰਡਿਆਂ ਦੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 1 ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਹੁੰਦੇ ਹਨ. ਉਹਨਾਂ ਦਾ ਹੱਲ ਸਾਡੇ ਲਈ ਬਹੁਤ ਦਿਲਚਸਪ ਹੈ ਅਤੇ ਅਸੀਂ ਉਹਨਾਂ ਦੇ ਤਜ਼ਰਬੇ ਨੂੰ ਅਪਣਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ - ਉਦਾਹਰਣ ਵਜੋਂ, Tarantool ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਕਾਰਜਸ਼ੀਲ SSO ਬੈਕਅੱਪ ਬਣਾਉਣਾ। ਹੁਣ Mail.ru ਦੇ ਡਿਵੈਲਪਰ ਸਾਡੇ ਲਈ ਅਜਿਹਾ ਕਰ ਰਹੇ ਹਨ।

CRM

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

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

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

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

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

ਪਿਛਲੀ ਤਸਵੀਰ ਉਹ ਡੋਮੇਨ ਹੈ ਜਿੱਥੇ ਅਸੀਂ Tarantool ਦੀ ਵਰਤੋਂ ਕਰਨ ਜਾ ਰਹੇ ਹਾਂ। CRM ਆਪਣੇ ਆਪ ਵਿੱਚ, ਬੇਸ਼ਕ, ਵਿਆਪਕ ਹੈ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਕੋਰ ਵਿੱਚ ਹੀ ਵਰਤਣ ਜਾ ਰਹੇ ਹਾਂ।

ਸਾਡੇ 100 ਮਿਲੀਅਨ ਗਾਹਕਾਂ ਦਾ ਅਨੁਮਾਨਿਤ TTX ਅੰਕੜਾ ਮੈਨੂੰ ਇੱਕ ਆਰਕੀਟੈਕਟ ਵਜੋਂ ਉਲਝਾਉਂਦਾ ਹੈ - ਜੇਕਰ 101 ਮਿਲੀਅਨ? ਕੀ ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਕਰਨਾ ਪਵੇਗਾ? ਅਜਿਹਾ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਅਸੀਂ ਕੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਉਸੇ ਸਮੇਂ ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ.

ਆਮ ਤੌਰ 'ਤੇ, ਟਾਰਨਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ ਹਨ। ਪਹਿਲਾਂ - ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਪੱਧਰ 'ਤੇ ਸਾਰੇ ਕੈਚ ਬਣਾਓ. ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, VimpelCom ਇਸ ਮਾਰਗ ਦੀ ਪਾਲਣਾ ਕਰ ਰਿਹਾ ਹੈ, ਗਾਹਕਾਂ ਦਾ ਇੱਕ ਕੈਸ਼ ਬਣਾ ਰਿਹਾ ਹੈ.

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

ਇਸ ਤਰੀਕੇ ਨਾਲ ਘੱਟ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਹੈ - ਇੱਕ ਸਿਸਟਮ ਕੈਸ਼ ਅਤੇ ਮੁੱਖ ਮਾਸਟਰ ਸਰੋਤ ਦੋਵਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

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

ਆਰ.ਟੀ.ਓ. ਅਤੇ ਆਰ.ਪੀ.ਓ

ਆਈਟੀ ਵਿੱਚ ਦੋ ਸ਼ਬਦ ਹਨ - ਆਰਟੀਓ и RPO.

ਰਿਕਵਰੀ ਟਾਈਮ ਉਦੇਸ਼ ਇੱਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। RTO = 0 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਭਾਵੇਂ ਕੁਝ ਅਸਫਲ ਹੋ ਜਾਵੇ, ਸੇਵਾ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ।

ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਉਦੇਸ਼ - ਇਹ ਡਾਟਾ ਰਿਕਵਰੀ ਸਮਾਂ ਹੈ, ਅਸੀਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ ਵਿੱਚ ਕਿੰਨਾ ਡਾਟਾ ਗੁਆ ਸਕਦੇ ਹਾਂ। RPO = 0 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਡਾਟਾ ਨਹੀਂ ਗੁਆ ਰਹੇ ਹਾਂ।

ਤਰਨਟੂਲ ਕਾਰਜ

ਆਉ Tarantool ਲਈ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ.

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

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

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

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

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

ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਭੂ-ਵਿਤਰਿਤ ਹੱਲ ਬਣਾ ਰਹੇ ਹਾਂ - ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕਲੱਸਟਰ ਹੈ, ਪਰ RPO = 0 ਅਤੇ RTO = 0 ਬਾਰੇ ਕੀ? ਹੱਲ ਸਧਾਰਨ ਹੈ, ਵਿਸ਼ੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.

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

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

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

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

Cassandra ਅਤੇ Tarantool ਇਕੱਠੇ

ਇੱਕ ਹੋਰ ਮਾਮਲਾ ਹੈ - "ਬਕਾਏ ਦਾ ਪ੍ਰਦਰਸ਼ਨ". ਇੱਥੇ Cassandra ਅਤੇ Tarantool ਦੀ ਸਾਂਝੀ ਵਰਤੋਂ ਦਾ ਇੱਕ ਦਿਲਚਸਪ ਮਾਮਲਾ ਹੈ।

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

Cassandra ਤੁਹਾਨੂੰ ਖਿਤਿਜੀ ਕਿਸੇ ਵੀ ਆਕਾਰ ਨੂੰ ਸਕੇਲ ਕਰਨ ਲਈ ਸਹਾਇਕ ਹੈ.

ਅਸੀਂ ਕੈਸੈਂਡਰਾ ਨਾਲ ਅਰਾਮਦੇਹ ਮਹਿਸੂਸ ਕਰਦੇ ਹਾਂ, ਪਰ ਇਸਦੀ ਇੱਕ ਸਮੱਸਿਆ ਹੈ - ਇਹ ਪੜ੍ਹਨ ਵਿੱਚ ਚੰਗੀ ਨਹੀਂ ਹੈ। ਰਿਕਾਰਡਿੰਗ 'ਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, 30 ਪ੍ਰਤੀ ਸਕਿੰਟ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ - ਪੜ੍ਹਨ ਦੀ ਸਮੱਸਿਆ.

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

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

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

ਸਿੱਟਾ

ਇਹ ਤਰਨਟੂਲ ਦੀ ਵਰਤੋਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਸਨ। ਸਾਨੂੰ ਸੱਚਮੁੱਚ Mail.ru ਦੀ ਖੁੱਲ੍ਹੀਤਾ ਅਤੇ ਵੱਖ-ਵੱਖ ਮਾਮਲਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਉਨ੍ਹਾਂ ਦੀ ਇੱਛਾ ਪਸੰਦ ਹੈ।

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

ਓਲੇਗ ਅਤੇ ਆਂਦਰੇ ਦੀ ਰਿਪੋਰਟ ਪਿਛਲੇ ਸਾਲ ਤਰਨਟੂਲ ਕਾਨਫਰੰਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ, ਅਤੇ 17 ਜੂਨ ਨੂੰ ਓਲੇਗ ਇਵਲੇਵ ਇੱਥੇ ਬੋਲਣਗੇ। T+ ਕਾਨਫਰੰਸ 2019 ਇੱਕ ਰਿਪੋਰਟ ਦੇ ਨਾਲ "ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ ਤਰਨਟੂਲ ਕਿਉਂ". ਅਲੈਗਜ਼ੈਂਡਰ ਡਿਊਲਿਨ ਮੈਗਾਫੋਨ ਤੋਂ ਇੱਕ ਪੇਸ਼ਕਾਰੀ ਵੀ ਦੇਣਗੇ "Tarantool ਕੈਸ਼ ਅਤੇ ਓਰੇਕਲ ਤੋਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ". ਆਓ ਜਾਣਦੇ ਹਾਂ ਕਿ ਕੀ ਬਦਲਿਆ ਹੈ, ਕਿਹੜੀਆਂ ਯੋਜਨਾਵਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਸ਼ਾਮਲ ਹੋਵੋ - ਕਾਨਫਰੰਸ ਮੁਫਤ ਹੈ, ਤੁਹਾਨੂੰ ਬੱਸ ਕਰਨਾ ਹੈ ਸਾਈਨ ਅੱਪ. ਸਭ ਰਿਪੋਰਟਾਂ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਗਈਆਂ ਅਤੇ ਕਾਨਫਰੰਸ ਪ੍ਰੋਗਰਾਮ ਦਾ ਗਠਨ ਕੀਤਾ ਗਿਆ ਹੈ: ਨਵੇਂ ਕੇਸ, ਤਰਨਟੂਲ, ਆਰਕੀਟੈਕਚਰ, ਐਂਟਰਪ੍ਰਾਈਜ਼, ਟਿਊਟੋਰਿਅਲ ਅਤੇ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਨਵਾਂ ਅਨੁਭਵ।

ਸਰੋਤ: www.habr.com