ਅਜੇ ਵੀ ਫਿਲਮ "ਸਾਡਾ ਸੀਕਰੇਟ ਬ੍ਰਹਿਮੰਡ: ਸੈੱਲ ਦੀ ਲੁਕਵੀਂ ਜ਼ਿੰਦਗੀ" ਤੋਂ

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਰੈਗੂਲੇਟਰਾਂ ਦੀਆਂ ਲੋੜਾਂ, ਰੂਸੀ ਅਤੇ ਵਿਦੇਸ਼ੀ ਦੋਵੇਂ, ਵਧ ਰਹੀਆਂ ਹਨ.

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

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

prehistory

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

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

ਇੱਕ ਨਵੇਂ ਹੱਲ ਲਈ ਲੋੜਾਂ

ਕਾਰੋਬਾਰਾਂ ਨੇ ਮਹਿਸੂਸ ਕੀਤਾ ਹੈ ਕਿ ਹੋਰ ਵਿਕਾਸ ਲਈ ਤਕਨੀਕੀ ਤਬਦੀਲੀ ਜ਼ਰੂਰੀ ਹੈ। ਸਾਨੂੰ ਕੰਮ ਦਿੱਤੇ ਗਏ ਸਨ:

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਆਰਕੀਟੈਕਟ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ ਸੈਟ ਕਰਦੇ ਹਨ:

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

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

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

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

ਅੱਗੇ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਸਾਡਾ ਸਿਸਟਮ ਕਿਵੇਂ ਵਧਿਆ, ਇਹ ਕਿਵੇਂ ਵਿਕਸਿਤ ਹੋਇਆ, ਅਸੀਂ ਕੀ ਕੀਤਾ ਅਤੇ ਅਜਿਹਾ ਕਿਉਂ ਕੀਤਾ।

ਵਿਕਾਸ

ਪਹਿਲਾ ਸਵਾਲ ਜੋ ਅਸੀਂ ਆਪਣੇ ਆਪ ਤੋਂ ਪੁੱਛਿਆ ਸੀ ਕਿ ਸਾਡੇ ਮੌਜੂਦਾ ਸਿਸਟਮਾਂ ਤੋਂ ਡੇਟਾ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ। ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ HTTP ਸਾਡੇ ਲਈ ਕਾਫ਼ੀ ਢੁਕਵਾਂ ਸੀ, ਕਿਉਂਕਿ ਸਾਰੇ ਮੌਜੂਦਾ ਸਿਸਟਮ HTTP ਉੱਤੇ XML ਜਾਂ JSON ਭੇਜ ਕੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ।

ਅਸੀਂ Tarantool ਵਿੱਚ ਬਣੇ HTTP ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਕਿਉਂਕਿ ਸਾਨੂੰ SSL ਸੈਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸਦਾ ਪ੍ਰਦਰਸ਼ਨ ਸਾਡੇ ਲਈ ਕਾਫੀ ਹੈ।

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

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

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

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

ਹੁਣ ਤੁਹਾਨੂੰ ਇਹ ਸਿੱਖਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਸਿਸਟਮਾਂ ਦਾ ਧਿਆਨ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਅਤੇ ਦੇਖਿਆ ਕਿ Java ਅਤੇ Oracle ਦੇ ਕਲਾਸਿਕ ਸਟੈਕ ਵਿੱਚ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਕੁਝ ਕਿਸਮ ਦਾ ORM ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਡੇਟਾ ਨੂੰ ਰਿਲੇਸ਼ਨਲ ਤੋਂ ਆਬਜੈਕਟ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਤਾਂ ਕਿਉਂ ਨਾ ਗ੍ਰਾਫ ਦੇ ਰੂਪ ਵਿੱਚ ਸਿਸਟਮਾਂ ਨੂੰ ਤੁਰੰਤ ਆਬਜੈਕਟ ਦਿਓ? ਇਸ ਲਈ ਅਸੀਂ ਖੁਸ਼ੀ ਨਾਲ GraphQL ਨੂੰ ਅਪਣਾਇਆ, ਜੋ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਗ੍ਰਾਫਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਸਿਰਫ ਉਹੀ ਬਾਹਰ ਕੱਢਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਇਸ ਸਮੇਂ ਲੋੜ ਹੈ। ਤੁਸੀਂ ਕਾਫੀ ਲਚਕਤਾ ਦੇ ਨਾਲ API ਦਾ ਸੰਸਕਰਣ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।

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

ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਸਿਸਟਮ ਲਾਗੂ ਕੀਤਾ.

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

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

ਭਾਵ, ਰੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਕਲੱਸਟਰ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਕੀਤਾ, ਜੋ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

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

ਟੈਸਟਿੰਗ

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

ਅਸੀਂ ਟੈਸਟ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਵਿਕਾਸ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰੀਏ?

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

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

ਹਾਲਾਂਕਿ, ਜੋ ਅਸੀਂ ਸਭ ਤੋਂ ਵੱਧ ਪਸੰਦ ਕਰਦੇ ਹਾਂ ਉਹ ਹੈ ਲੋਡ ਟੈਸਟਿੰਗ; ਅਸੀਂ ਇਸਨੂੰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਮੰਨਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਕਰਦੇ ਹਾਂ।

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

ਅਸੀਂ ਬਹੁਤ ਦੁਖੀ ਸੀ। ਅਸੀਂ ਸਰਵਰ ਲੋਡ ਨੂੰ ਦੇਖਦੇ ਹਾਂ, ਪਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਉਹ ਵਿਹਲੇ ਹਨ।

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

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਮੈਮੋਰੀ ਸਿਰਫ ਆਉਣ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨਾਂ ਅਤੇ ਅਸਥਾਈ ਵਸਤੂਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਸੀ।

ਇਸ ਦੇ ਉਲਟ, ਸਟੋਰੇਜ ਸਰਵਰਾਂ 'ਤੇ, ਪ੍ਰੋਸੈਸਰ ਲੋਡ ਵਧਿਆ ਹੈ, ਪਰ ਉਹਨਾਂ ਸਰਵਰਾਂ ਨਾਲੋਂ ਬਹੁਤ ਹੌਲੀ ਹੈ ਜੋ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਨ।

ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਦੇ ਸਿੱਧੇ ਅਨੁਪਾਤ ਵਿੱਚ ਵਧੀ ਹੈ।

ਸੇਵਾਵਾਂ

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

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

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

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

ਪੁਰਾਣੇ ਸਿਸਟਮ

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

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

ਨਵੇਂ ਸੁਧਾਰ

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

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

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

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

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

ਸਿੱਟਾ

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

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

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

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

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

ਜਦੋਂ ਅਸੀਂ ਇਸ ਤੱਥ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ SQL ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਲੋਕਾਂ ਨੂੰ ਡਰਾਉਂਦਾ ਹੈ। “ਤੁਸੀਂ SQL ਤੋਂ ਬਿਨਾਂ ਡੇਟਾ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ? ਕੀ ਇਹ ਸੰਭਵ ਹੈ? ਯਕੀਨਨ. ਇੱਕ OLTP ਕਲਾਸ ਸਿਸਟਮ ਵਿੱਚ, SQL ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਕਿਸੇ ਕਿਸਮ ਦੀ ਭਾਸ਼ਾ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਵਿਕਲਪ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਇੱਕ ਦਸਤਾਵੇਜ਼-ਮੁਖੀ ਦ੍ਰਿਸ਼ ਵੱਲ ਵਾਪਸ ਲੈ ਜਾਂਦਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, GraphQL. ਅਤੇ ਵਿਤਰਿਤ ਕੰਪਿਊਟਿੰਗ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਵਿਕਲਪ ਹੈ.

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

ਸਰੋਤ: www.habr.com