MySQL ਵਿੱਚ 300 ਮਿਲੀਅਨ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਮਿਟਾਉਣ ਦੀ ਕਹਾਣੀ

ਜਾਣ ਪਛਾਣ

ਸਤ ਸ੍ਰੀ ਅਕਾਲ. ਮੈਂ ningenMe, ਵੈੱਬ ਡਿਵੈਲਪਰ ਹਾਂ।

ਜਿਵੇਂ ਕਿ ਸਿਰਲੇਖ ਕਹਿੰਦਾ ਹੈ, ਮੇਰੀ ਕਹਾਣੀ MySQL ਵਿੱਚ 300 ਮਿਲੀਅਨ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਮਿਟਾਉਣ ਦੀ ਕਹਾਣੀ ਹੈ.

ਮੈਨੂੰ ਇਸ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੋ ਗਈ, ਇਸ ਲਈ ਮੈਂ ਇੱਕ ਰੀਮਾਈਂਡਰ (ਹਿਦਾਇਤਾਂ) ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।

ਘਰ - ਚੇਤਾਵਨੀ

ਜਿਸ ਬੈਚ ਸਰਵਰ ਦੀ ਮੈਂ ਵਰਤੋਂ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕਰਦਾ ਹਾਂ, ਉਸ ਦੀ ਇੱਕ ਨਿਯਮਤ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ MySQL ਤੋਂ ਦਿਨ ਵਿੱਚ ਇੱਕ ਵਾਰ ਪਿਛਲੇ ਮਹੀਨੇ ਦੇ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਦੀ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਲਗਭਗ 1 ਘੰਟੇ ਦੇ ਅੰਦਰ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਇਸ ਵਾਰ ਇਹ 7 ਜਾਂ 8 ਘੰਟੇ ਤੱਕ ਪੂਰੀ ਨਹੀਂ ਹੋਈ, ਅਤੇ ਚੇਤਾਵਨੀ ਪੌਪ-ਅੱਪ ਬੰਦ ਨਹੀਂ ਹੋਈ ...

ਕਿਸੇ ਕਾਰਨ ਦੀ ਭਾਲ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

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

hoge_table | 350'000'000 |

350 ਮਿਲੀਅਨ ਰਿਕਾਰਡ. ਇੰਡੈਕਸਿੰਗ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੀ ਜਾਪਦੀ ਸੀ, ਬਹੁਤ ਹੌਲੀ।

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

DB

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

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

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

ਅਤੇ ਫਿਰ ਮੈਂ ਹਰਕਤ ਵਿੱਚ ਆਇਆ।

ਸੁਧਾਰ

ਆਪਣੇ ਆਪ ਵਿੱਚ ਤਰਕ ਨੂੰ ਬਦਲਣ ਨਾਲੋਂ ਡੇਟਾਬੇਸ ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾਉਣਾ ਅਤੇ ਇਸਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਸਮਾਂ ਘਟਾਉਣਾ ਵਧੇਰੇ ਤਰਕਸ਼ੀਲ ਸੀ।

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

ਕਾਰਵਾਈ 1

ਇੱਕ ਭਰੋਸੇਯੋਗ ਬੈਕਅੱਪ ਤਿਆਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਅੰਤ ਵਿੱਚ ਬੇਨਤੀਆਂ ਭੇਜਣੀਆਂ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀਆਂ।

'ਬੇਨਤੀ ਭੇਜਣਾ'

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

"…"

"…"

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

ਕਾਰਵਾਈ 2

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

ਮੈਂ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਜੋ ਲਗਭਗ 1 ਰਿਕਾਰਡਾਂ ਨੂੰ ਮਿਟਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲਾਂਚ ਕੀਤਾ।

'ਮੈਂ ਸਕ੍ਰਿਪਟ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹਾਂ'

"ਹੁਣ ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰੇਗਾ," ਮੈਂ ਸੋਚਿਆ।

ਕਾਰਵਾਈ 3

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

ਇਸ ਲਈ ਇੱਥੇ ਮੈਂ ਕੀ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ:

ਟੇਬਲ ਨੂੰ ਕਾਪੀ ਕਰੋ ਅਤੇ ਇਸਦਾ ਨਾਮ ਬਦਲੋ

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

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

ਜੇਕਰ ਤੁਸੀਂ ਨਵੀਂ ਸਾਰਣੀ ਨੂੰ ਉੱਪਰ ਦਿੱਤੇ ਸਮਾਨ ਆਕਾਰ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਗਤੀ ਵੀ 1/7 ਤੇਜ਼ ਹੋ ਜਾਵੇਗੀ।

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

ਪੂਰਨਤਾ

'ਬੇਨਤੀ ਭੇਜਣਾ'

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

"…"
"…"
"ਐਮ...?"

ਕਾਰਵਾਈ 4

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

ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇੰਨਾ ਥੱਕ ਗਿਆ ਸੀ ਕਿ ਮੈਂ ਸੋਚਣ ਲੱਗਾ ਕਿ ਮੈਂ ਹੁਣ ਅਜਿਹਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ।

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

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

ਇੱਕ ਟੇਬਲ ਦਾ ਨਾਮ ਬਦਲਿਆ ਜਾ ਰਿਹਾ ਹੈ

ਇੱਥੇ ਕਿਸਮਤ ਮੇਰੇ ਪਾਸੇ ਸੀ: ਸਭ ਕੁਝ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਚਲਾ ਗਿਆ.

ਅਲਰਟ ਗਾਇਬ ਹੋ ਗਿਆ ਹੈ

ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਗਤੀ ਵਧ ਗਈ ਹੈ।

ਪਹਿਲਾਂ ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ ਘੰਟਾ ਲੱਗਦਾ ਸੀ, ਹੁਣ ਇਸ ਵਿੱਚ ਲਗਭਗ 2 ਮਿੰਟ ਲੱਗਦੇ ਹਨ।

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

ਸੰਖੇਪ

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

ਕੀ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਤੋਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਮਿਟਾਉਣ ਵੇਲੇ ਡੇਟਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਦੌਰਾਨ ਲੋਡ ਬਾਰੇ ਸੋਚਦੇ ਹੋ? ਆਓ MySQL ਨੂੰ ਓਵਰਲੋਡ ਨਾ ਕਰੀਏ।

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

ਪੜ੍ਹਨ ਲਈ ਧੰਨਵਾਦ!

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

ਸਰੋਤ: www.habr.com