NewSQL = NoSQL+ACID

ਹਾਲ ਹੀ ਵਿੱਚ, ਓਡਨੋਕਲਾਸਨੀਕੀ ਨੇ SQL ਸਰਵਰ ਵਿੱਚ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਗਏ ਲਗਭਗ 50 TB ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕੀਤਾ। ਅਜਿਹੇ ਵੌਲਯੂਮ ਲਈ, SQL DBMS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਮੰਦ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਡਾਟਾ ਸੈਂਟਰ ਅਸਫਲਤਾ-ਸਹਿਣਸ਼ੀਲ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨਾ ਲਗਭਗ ਅਸੰਭਵ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ, ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, NoSQL ਸਟੋਰੇਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਸਭ ਕੁਝ NoSQL ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਕੁਝ ਸੰਸਥਾਵਾਂ ਨੂੰ ACID ਲੈਣ-ਦੇਣ ਦੀ ਗਾਰੰਟੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਹੋਇਆ - ਕੱਟ ਦੇ ਹੇਠਾਂ ਪੜ੍ਹੋ.

ਅੱਜ, Odnoklassniki ਦੇ ਮਾਸਿਕ ਦਰਸ਼ਕ 70 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਵਿਲੱਖਣ ਵਿਜ਼ਿਟਰ ਹਨ। ਅਸੀਂ ਅਸੀਂ ਚੋਟੀ ਦੇ ਪੰਜ ਵਿੱਚ ਹਾਂ ਦੁਨੀਆ ਦੇ ਸਭ ਤੋਂ ਵੱਡੇ ਸੋਸ਼ਲ ਨੈਟਵਰਕ, ਅਤੇ ਉਹਨਾਂ ਵੀਹ ਸਾਈਟਾਂ ਵਿੱਚੋਂ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਉਪਭੋਗਤਾ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਨ। ਓਕੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ: ਪ੍ਰਤੀ ਫਰੰਟ ਇੱਕ ਮਿਲੀਅਨ HTTP ਬੇਨਤੀਆਂ/ਸੈਕੰਡ ਤੋਂ ਵੱਧ। 8000 ਤੋਂ ਵੱਧ ਟੁਕੜਿਆਂ ਦੇ ਸਰਵਰ ਫਲੀਟ ਦੇ ਹਿੱਸੇ ਇੱਕ ਦੂਜੇ ਦੇ ਨੇੜੇ ਸਥਿਤ ਹਨ - ਚਾਰ ਮਾਸਕੋ ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ, ਜੋ ਉਹਨਾਂ ਵਿਚਕਾਰ 1 ms ਤੋਂ ਘੱਟ ਦੀ ਇੱਕ ਨੈਟਵਰਕ ਲੇਟੈਂਸੀ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਅਸੀਂ ਵਰਜਨ 2010 ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, 0.6 ਤੋਂ ਕੈਸੈਂਡਰਾ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ। ਅੱਜ ਇੱਥੇ ਕਈ ਦਰਜਨ ਕਲੱਸਟਰ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ ਕਲੱਸਟਰ ਪ੍ਰਤੀ ਸਕਿੰਟ 4 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਸਟੋਰ 260 ਟੀ.ਬੀ.

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

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

ਸ਼ਾਰਡਿੰਗ ਅਤੇ SQL ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਧੰਨਵਾਦ:

• ਅਸੀਂ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਪਾਬੰਦੀਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਕਿਉਂਕਿ ਜਦੋਂ ਇਕਾਈ ID ਨੂੰ ਸ਼ਾਰਡਿੰਗ ਕਰਦੇ ਹੋ ਤਾਂ ਕਿਸੇ ਹੋਰ ਸਰਵਰ 'ਤੇ ਸਥਿਤ ਹੋ ਸਕਦਾ ਹੈ।
• ਅਸੀਂ DBMS CPU 'ਤੇ ਵਾਧੂ ਲੋਡ ਦੇ ਕਾਰਨ ਸਟੋਰ ਕੀਤੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਟਰਿਗਰਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।
• ਅਸੀਂ ਉਪਰੋਕਤ ਸਭ ਦੇ ਕਾਰਨ ਅਤੇ ਡਿਸਕ ਤੋਂ ਬਹੁਤ ਸਾਰੇ ਬੇਤਰਤੀਬੇ ਰੀਡਜ਼ ਦੇ ਕਾਰਨ JOINs ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।
• ਕਿਸੇ ਲੈਣ-ਦੇਣ ਤੋਂ ਬਾਹਰ, ਅਸੀਂ ਡੈੱਡਲਾਕ ਨੂੰ ਘਟਾਉਣ ਲਈ ਰੀਡ ਅਣਕਮਿਟਿਡ ਆਈਸੋਲੇਸ਼ਨ ਪੱਧਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।
• ਅਸੀਂ ਸਿਰਫ਼ ਛੋਟੇ ਲੈਣ-ਦੇਣ ਕਰਦੇ ਹਾਂ (ਔਸਤਨ 100 ms ਤੋਂ ਘੱਟ)।
• ਅਸੀਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਡੈੱਡਲਾਕ ਦੇ ਕਾਰਨ ਮਲਟੀ-ਰੋਅ ਅੱਪਡੇਟ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ - ਅਸੀਂ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਰਿਕਾਰਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਹਾਂ।
• ਅਸੀਂ ਹਮੇਸ਼ਾ ਸਿਰਫ਼ ਸੂਚਕਾਂਕ 'ਤੇ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹਾਂ - ਸਾਡੇ ਲਈ ਇੱਕ ਪੂਰੀ ਟੇਬਲ ਸਕੈਨ ਯੋਜਨਾ ਵਾਲੀ ਪੁੱਛਗਿੱਛ ਦਾ ਮਤਲਬ ਹੈ ਡਾਟਾਬੇਸ ਨੂੰ ਓਵਰਲੋਡ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਫੇਲ ਕਰਨਾ।

ਇਹਨਾਂ ਕਦਮਾਂ ਨੇ ਸਾਨੂੰ SQL ਸਰਵਰਾਂ ਤੋਂ ਲਗਭਗ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸਕਿਊਜ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਹਾਲਾਂਕਿ, ਸਮੱਸਿਆਵਾਂ ਹੋਰ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਹੁੰਦੀਆਂ ਗਈਆਂ. ਆਓ ਉਨ੍ਹਾਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ।

SQL ਨਾਲ ਸਮੱਸਿਆਵਾਂ

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

ਪਰ ਮੁੱਖ ਸਮੱਸਿਆ ਹੈ

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

ਕਲਾਸਿਕ SQL ਸਰਵਰ ਵਿੱਚ ਖਰਾਬ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ ਇੱਕ ਡਾਟਾਬੇਸ ਸਰਵਰ ਹੈ, ਅਤੇ ਇਹ ਹਰ ਤਿੰਨ ਸਾਲਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਸਾਈਟ 20 ਮਿੰਟ ਲਈ ਡਾਊਨ ਰਹਿੰਦੀ ਹੈ, ਜੋ ਸਵੀਕਾਰਯੋਗ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ 64 ਸਰਵਰ ਹਨ, ਤਾਂ ਸਾਈਟ ਹਰ ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਡਾਊਨ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਜੇ ਤੁਹਾਡੇ ਕੋਲ 200 ਸਰਵਰ ਹਨ, ਤਾਂ ਸਾਈਟ ਹਰ ਹਫ਼ਤੇ ਕੰਮ ਨਹੀਂ ਕਰਦੀ. ਇਹ ਸਮੱਸਿਆ ਹੈ।

ਇੱਕ SQL ਸਰਵਰ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਵਿਕੀਪੀਡੀਆ ਸਾਨੂੰ ਬਣਾਉਣ ਲਈ ਸੱਦਾ ਦਿੰਦਾ ਹੈ ਬਹੁਤ ਹੀ ਉਪਲਬਧ ਕਲੱਸਟਰ: ਜਿੱਥੇ ਕਿਸੇ ਵੀ ਹਿੱਸੇ ਦੇ ਅਸਫਲ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਬੈਕਅੱਪ ਹੁੰਦਾ ਹੈ।

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

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

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

ਇਹਨਾਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇੱਕ ਰੈਡੀਕਲ ਹੱਲ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਅਸੀਂ ਉਹਨਾਂ ਦਾ ਵਿਸਥਾਰ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਇੱਥੇ ਸਾਨੂੰ SQL ਸਰਵਰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਕੀ ਕਰਦਾ ਹੈ - ਲੈਣ-ਦੇਣ ਤੋਂ ਜਾਣੂ ਹੋਣ ਦੀ ਲੋੜ ਹੈ।

ਸਧਾਰਨ ਲੈਣ-ਦੇਣ

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

1. ਅਸੀਂ ਕੁੰਜੀ ਦੁਆਰਾ ਐਲਬਮ ਨੂੰ ਲਾਕ ਕਰਦੇ ਹਾਂ।
2. ਫੋਟੋ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ ਬਣਾਓ।
3. ਜੇਕਰ ਫੋਟੋ ਦੀ ਜਨਤਕ ਸਥਿਤੀ ਹੈ, ਤਾਂ ਐਲਬਮ ਵਿੱਚ ਇੱਕ ਜਨਤਕ ਫੋਟੋ ਕਾਊਂਟਰ ਸ਼ਾਮਲ ਕਰੋ, ਰਿਕਾਰਡ ਨੂੰ ਅਪਡੇਟ ਕਰੋ ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕਰੋ।

ਜਾਂ ਸੂਡੋਕੋਡ ਵਿੱਚ:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

ਹੋਰ, ਕੋਈ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ, ਲੋੜਾਂ ਸਨ:

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

ਫੈਸਲੇ, ਫੈਸਲੇ

ਸੰਭਾਵਿਤ ਹੱਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਦੋ ਸੰਭਾਵਿਤ ਆਰਕੀਟੈਕਚਰ ਵਿਕਲਪਾਂ 'ਤੇ ਆਏ:

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

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

Cassandra ਅਤੇ CQL

ਇਸ ਲਈ, ਕੈਸੈਂਡਰਾ ਬਾਰੇ ਦਿਲਚਸਪ ਕੀ ਹੈ, ਇਸ ਵਿਚ ਕਿਹੜੀਆਂ ਯੋਗਤਾਵਾਂ ਹਨ?

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਥੇ ਤੁਸੀਂ ਟੇਬਲ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਵੱਖ-ਵੱਖ ਡਾਟਾ ਕਿਸਮਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਤੁਸੀਂ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ 'ਤੇ SELECT ਜਾਂ ਅੱਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ।

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

ਪਹੁੰਚ ਜਦੋਂ ਅਸੀਂ ਤਿੰਨ ਨੋਡਾਂ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਾਂ ਅਤੇ ਦੋ ਤੋਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਤਾਂ ਉਸ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਟਕਲਾਂ: ਵਾਧੂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਬੇਨਤੀ "ਡਿੱਗਣ" ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਭੇਜੀ ਜਾਂਦੀ ਹੈ।

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

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

ਅਸੀਂ ਕੈਸੈਂਡਰਾ ਵਿੱਚ ਕੀ ਗੁਆ ਰਹੇ ਸੀ

ਇਸ ਲਈ, ਸਾਨੂੰ ਕੈਸੈਂਡਰਾ ਵਿੱਚ ਅਸਲ ACID ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਪਿਆ। ਜਿਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਕਲਾਸਿਕ DBMS ਦੀਆਂ ਦੋ ਹੋਰ ਸੁਵਿਧਾਜਨਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ: ਇਕਸਾਰ ਤੇਜ਼ ਸੂਚਕਾਂਕ, ਜੋ ਸਾਨੂੰ ਨਾ ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦੁਆਰਾ ਡਾਟਾ ਚੋਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਮੋਨੋਟੋਨਿਕ ਆਟੋ-ਇੰਕਰੀਮੈਂਟ IDs ਦਾ ਇੱਕ ਨਿਯਮਤ ਜਨਰੇਟਰ।

C*ਇੱਕ

ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਨਵਾਂ DBMS ਪੈਦਾ ਹੋਇਆ ਸੀ C*ਇੱਕ, ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਕਿਸਮ ਦੇ ਸਰਵਰ ਨੋਡ ਸ਼ਾਮਲ ਹਨ:

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

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

ਗ੍ਰਾਹਕ

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

C*ਵਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕੋਆਰਡੀਨੇਟਰ

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

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

ਤਾਲੇ

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

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

ਕਿਉਂਕਿ ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਡੇਟਾ ਪਹਿਲਾਂ ਹੀ SQL ਵਿੱਚ ਸਥਾਨਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੇ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ, ਇਸ ਲਈ ਸਥਾਨਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸਮੂਹਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟਰਾਂ ਨੂੰ ਸੌਂਪਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ: ਇੱਕ ਕੋਆਰਡੀਨੇਟਰ 0 ਤੋਂ 9 ਤੱਕ ਟੋਕਨਾਂ ਨਾਲ ਸਾਰੇ ਲੈਣ-ਦੇਣ ਕਰਦਾ ਹੈ, ਦੂਜਾ - 10 ਤੋਂ 19 ਤੱਕ ਟੋਕਨਾਂ ਨਾਲ, ਇਤਆਦਿ. ਨਤੀਜੇ ਵਜੋਂ, ਹਰ ਕੋਆਰਡੀਨੇਟਰ ਉਦਾਹਰਨ ਲੈਣ-ਦੇਣ ਸਮੂਹ ਦਾ ਮਾਸਟਰ ਬਣ ਜਾਂਦਾ ਹੈ।

ਫਿਰ ਤਾਲੇ ਕੋਆਰਡੀਨੇਟਰ ਦੀ ਯਾਦ ਵਿੱਚ ਇੱਕ ਆਮ ਹੈਸ਼ਮੈਪ ਦੇ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ.

ਕੋਆਰਡੀਨੇਟਰ ਅਸਫਲਤਾਵਾਂ

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

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

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

ਦਿਲ ਦੀ ਧੜਕਣ ਦੇ ਸੁਨੇਹੇ 20 ms ਦੀ ਮਿਆਦ ਦੇ ਨਾਲ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 50 ਵਾਰ, ਉੱਚ ਬਾਰੰਬਾਰਤਾ ਨਾਲ ਭੇਜੇ ਜਾਂਦੇ ਹਨ। Java ਵਿੱਚ, ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੁਆਰਾ ਵਿਰਾਮ ਦੀ ਤੁਲਨਾਤਮਕ ਲੰਬਾਈ ਦੇ ਕਾਰਨ 50 ms ਦੇ ਅੰਦਰ ਐਪਲੀਕੇਸ਼ਨ ਜਵਾਬ ਦੀ ਗਰੰਟੀ ਦੇਣਾ ਮੁਸ਼ਕਲ ਹੈ। ਅਸੀਂ G1 ਗਾਰਬੇਜ ਕੁਲੈਕਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇਸ ਜਵਾਬ ਸਮੇਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ, ਜੋ ਸਾਨੂੰ GC ਵਿਰਾਮ ਦੀ ਮਿਆਦ ਲਈ ਇੱਕ ਟੀਚਾ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਕਦੇ-ਕਦਾਈਂ, ਬਹੁਤ ਘੱਟ ਹੀ, ਕੁਲੈਕਟਰ 50 ms ਤੋਂ ਵੱਧ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਗਲਤ ਨੁਕਸ ਦਾ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਅਜਿਹਾ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਕੋਆਰਡੀਨੇਟਰ ਕਿਸੇ ਰਿਮੋਟ ਨੋਡ ਦੀ ਅਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਨਹੀਂ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਸ ਤੋਂ ਪਹਿਲਾ ਦਿਲ ਦੀ ਧੜਕਣ ਦਾ ਸੁਨੇਹਾ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਸਿਰਫ ਤਾਂ ਹੀ ਜੇਕਰ ਕਈ ਲਗਾਤਾਰ ਗਾਇਬ ਹੋ ਗਏ ਹੋਣ ਤਾਂ ਅਸੀਂ 200 ਵਿੱਚ ਕੋਆਰਡੀਨੇਟਰ ਨੋਡ ਦੀ ਅਸਫਲਤਾ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ms

ਪਰ ਇਹ ਜਲਦੀ ਸਮਝਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ ਕਿ ਕਿਸ ਨੋਡ ਨੇ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ। ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਰਿਜ਼ਰਵੇਸ਼ਨ

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

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

ਇਹ ਸਕੀਮ ਯੂਨੀਵਰਸਲ ਐਲਗੋਰਿਦਮ ਨਾਲੋਂ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਨਵੇਂ ਮਾਸਟਰ ਨੂੰ ਸਰਗਰਮ ਕਰਨ ਲਈ ਇਹ ਪੁਰਾਣੇ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਾਫੀ ਹੈ.

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

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

ਲੈਣ-ਦੇਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

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

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

ਜਦੋਂ ਇੱਕ ਕਲਾਇੰਟ ਇੱਕ ਕਿਰਿਆਸ਼ੀਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਆਪਣੇ ਖੁਦ ਦੇ ਬਦਲੇ ਹੋਏ ਡੇਟਾ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੋਆਰਡੀਨੇਟਰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ:

• ਜੇਕਰ ID ਪਹਿਲਾਂ ਹੀ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਹੈ, ਤਾਂ ਡੇਟਾ ਮੈਮੋਰੀ ਤੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ;
• ਜੇਕਰ ਮੈਮੋਰੀ ਵਿੱਚ ਕੋਈ ID ਨਹੀਂ ਹੈ, ਤਾਂ ਗੁੰਮ ਹੋਏ ਡੇਟਾ ਨੂੰ ਸਟੋਰੇਜ ਨੋਡਾਂ ਤੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਮੈਮੋਰੀ ਵਿੱਚ ਹਨ, ਅਤੇ ਨਤੀਜਾ ਕਲਾਇੰਟ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

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

ਅਤੇ ਰੋਲਬੈਕ ਕਰਨ ਲਈ, ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਸਿਰਫ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸਟੇਟ ਦੁਆਰਾ ਕਬਜੇ ਵਾਲੀ ਮੈਮੋਰੀ ਨੂੰ ਖਾਲੀ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਉਪਰੋਕਤ ਸੁਧਾਰਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ACID ਸਿਧਾਂਤ ਲਾਗੂ ਕੀਤੇ:

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

ਸੂਚਕਾਂਕ ਦੁਆਰਾ ਪੜ੍ਹਨਾ

ਆਓ ਇੱਕ ਸਧਾਰਨ ਸਾਰਣੀ ਕਰੀਏ:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

ਇਸ ਵਿੱਚ ਇੱਕ ID (ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ), ਮਾਲਕ ਅਤੇ ਸੋਧ ਮਿਤੀ ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਬੇਨਤੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ - "ਆਖਰੀ ਦਿਨ ਲਈ" ਤਬਦੀਲੀ ਦੀ ਮਿਤੀ ਦੇ ਨਾਲ ਮਾਲਕ 'ਤੇ ਡਾਟਾ ਚੁਣੋ।

SELECT *
WHERE owner=?
AND modified>?

ਅਜਿਹੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ, ਇੱਕ ਕਲਾਸਿਕ SQL DBMS ਵਿੱਚ ਤੁਹਾਨੂੰ ਕਾਲਮਾਂ (ਮਾਲਕ, ਸੋਧਿਆ) ਦੁਆਰਾ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਇਹ ਬਹੁਤ ਆਸਾਨੀ ਨਾਲ ਕਰ ਸਕਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਹੁਣ ਸਾਡੇ ਕੋਲ ACID ਗਾਰੰਟੀ ਹੈ!

C*ਵਨ ਵਿੱਚ ਸੂਚਕਾਂਕ

ਫੋਟੋਆਂ ਦੇ ਨਾਲ ਇੱਕ ਸਰੋਤ ਸਾਰਣੀ ਹੈ ਜਿਸ ਵਿੱਚ ਰਿਕਾਰਡ ID ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਹੈ।

ਇੱਕ ਸੂਚਕਾਂਕ ਲਈ, C*ਵਨ ਇੱਕ ਨਵੀਂ ਸਾਰਣੀ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲ ਦੀ ਇੱਕ ਕਾਪੀ ਹੈ। ਕੁੰਜੀ ਇੰਡੈਕਸ ਸਮੀਕਰਨ ਦੇ ਸਮਾਨ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਸਰੋਤ ਸਾਰਣੀ ਤੋਂ ਰਿਕਾਰਡ ਦੀ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਵੀ ਸ਼ਾਮਲ ਹੈ:

ਹੁਣ "ਆਖਰੀ ਦਿਨ ਲਈ ਮਾਲਕ" ਲਈ ਪੁੱਛਗਿੱਛ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸਾਰਣੀ ਵਿੱਚੋਂ ਇੱਕ ਚੋਣ ਵਜੋਂ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

ਕੀ ਹੋਇਆ

ਅਸੀਂ ਤਿੰਨ ਸਾਲ ਪਹਿਲਾਂ C*One ਵਿਕਸਿਤ ਕੀਤਾ ਸੀ ਅਤੇ ਇਸਨੂੰ ਵਪਾਰਕ ਸੰਚਾਲਨ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਸੀ।

ਸਾਨੂੰ ਅੰਤ ਵਿੱਚ ਕੀ ਮਿਲਿਆ? ਆਉ ਫੋਟੋ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਸਟੋਰੇਜ ਸਬਸਿਸਟਮ ਦੀ ਉਦਾਹਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇਸਦਾ ਮੁਲਾਂਕਣ ਕਰੀਏ, ਇੱਕ ਸੋਸ਼ਲ ਨੈਟਵਰਕ ਵਿੱਚ ਡੇਟਾ ਦੀਆਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਿਸਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਅਸੀਂ ਫੋਟੋਆਂ ਦੀਆਂ ਲਾਸ਼ਾਂ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਹਰ ਕਿਸਮ ਦੀ ਮੈਟਾ-ਜਾਣਕਾਰੀ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ. ਹੁਣ ਓਡਨੋਕਲਾਸਨੀਕੀ ਕੋਲ ਲਗਭਗ 20 ਬਿਲੀਅਨ ਅਜਿਹੇ ਰਿਕਾਰਡ ਹਨ, ਸਿਸਟਮ ਪ੍ਰਤੀ ਸਕਿੰਟ 80 ਹਜ਼ਾਰ ਰੀਡ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਡੇਟਾ ਸੋਧ ਨਾਲ ਜੁੜੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 8 ਹਜ਼ਾਰ ACID ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਤੱਕ.

ਜਦੋਂ ਅਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਫੈਕਟਰ = 1 (ਪਰ RAID 10 ਵਿੱਚ) ਨਾਲ SQL ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਤਾਂ ਫੋਟੋ ਮੇਟੇਨਫਾਰਮੇਸ਼ਨ ਨੂੰ Microsoft SQL ਸਰਵਰ (ਪਲੱਸ 32 ਬੈਕਅੱਪ) ਚਲਾਉਣ ਵਾਲੀਆਂ 11 ਮਸ਼ੀਨਾਂ ਦੇ ਇੱਕ ਬਹੁਤ ਹੀ ਉਪਲਬਧ ਕਲੱਸਟਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਬੈਕਅੱਪ ਸਟੋਰ ਕਰਨ ਲਈ 10 ਸਰਵਰ ਵੀ ਅਲਾਟ ਕੀਤੇ ਗਏ ਸਨ। ਕੁੱਲ 50 ਮਹਿੰਗੀਆਂ ਕਾਰਾਂ। ਉਸੇ ਸਮੇਂ, ਸਿਸਟਮ ਬਿਨਾਂ ਰਿਜ਼ਰਵ ਦੇ ਰੇਟ ਕੀਤੇ ਲੋਡ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।

ਨਵੇਂ ਸਿਸਟਮ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਫੈਕਟਰ = 3 - ਹਰੇਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਇੱਕ ਕਾਪੀ ਪ੍ਰਾਪਤ ਹੋਈ। ਸਿਸਟਮ ਵਿੱਚ ਕੁੱਲ 63 ਸਰਵਰਾਂ ਲਈ 6 ਕੈਸੈਂਡਰਾ ਸਟੋਰੇਜ ਨੋਡ ਅਤੇ 69 ਕੋਆਰਡੀਨੇਟਰ ਮਸ਼ੀਨਾਂ ਸ਼ਾਮਲ ਹਨ। ਪਰ ਇਹ ਮਸ਼ੀਨਾਂ ਬਹੁਤ ਸਸਤੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੀ ਕੁੱਲ ਲਾਗਤ ਇੱਕ SQL ਸਿਸਟਮ ਦੀ ਲਾਗਤ ਦਾ ਲਗਭਗ 30% ਹੈ। ਉਸੇ ਸਮੇਂ, ਲੋਡ 30% 'ਤੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ.

C*One ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਨਾਲ, ਲੇਟੈਂਸੀ ਵੀ ਘਟ ਗਈ: SQL ਵਿੱਚ, ਇੱਕ ਰਾਈਟ ਓਪਰੇਸ਼ਨ ਲਗਭਗ 4,5 ms ਲੈਂਦਾ ਹੈ। C*ਵਨ ਵਿੱਚ - ਲਗਭਗ 1,6 ms. ਲੈਣ-ਦੇਣ ਦੀ ਮਿਆਦ ਔਸਤਨ 40 ms ਤੋਂ ਘੱਟ ਹੈ, ਪ੍ਰਤੀਬੱਧਤਾ 2 ms ਵਿੱਚ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀ ਮਿਆਦ ਔਸਤਨ 2 ms ਹੈ। 99 ਵੀਂ ਪਰਸੈਂਟਾਈਲ - ਸਿਰਫ 3-3,1 ms, ਟਾਈਮਆਉਟ ਦੀ ਗਿਣਤੀ 100 ਗੁਣਾ ਘੱਟ ਗਈ ਹੈ - ਇਹ ਸਭ ਅਟਕਲਾਂ ਦੀ ਵਿਆਪਕ ਵਰਤੋਂ ਦੇ ਕਾਰਨ ਹੈ।

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

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

ਸਰੋਤ: www.habr.com