ਹੋਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਬਾਰੇ ਇਹ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: Jaana Dogan Google ਵਿੱਚ ਇੱਕ ਤਜਰਬੇਕਾਰ ਇੰਜੀਨੀਅਰ ਹੈ ਜੋ ਇਸ ਸਮੇਂ ਗੋ ਵਿੱਚ ਲਿਖੀਆਂ ਕੰਪਨੀ ਦੀਆਂ ਉਤਪਾਦਨ ਸੇਵਾਵਾਂ ਦੀ ਨਿਰੀਖਣਤਾ 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਹੈ। ਇਸ ਲੇਖ ਵਿੱਚ, ਜਿਸਨੇ ਅੰਗਰੇਜ਼ੀ ਬੋਲਣ ਵਾਲੇ ਦਰਸ਼ਕਾਂ ਵਿੱਚ ਬਹੁਤ ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕੀਤੀ, ਉਸਨੇ DBMS (ਅਤੇ ਕਈ ਵਾਰ ਆਮ ਤੌਰ 'ਤੇ ਵੰਡੇ ਸਿਸਟਮ) ਦੇ ਸੰਬੰਧ ਵਿੱਚ 17 ਪੁਆਇੰਟਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਜੋ ਕਿ ਵੱਡੇ/ਮੰਗ ਵਾਲੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਵਿਚਾਰ ਕਰਨ ਲਈ ਉਪਯੋਗੀ ਹਨ।

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

1. ਤੁਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋ ਜੇਕਰ 99,999% ਵਾਰ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣ ਰਿਹਾ ਹੈ।
2. ACID ਦਾ ਮਤਲਬ ਬਹੁਤ ਸਾਰੀਆਂ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ।
3. ਇਕਸਾਰਤਾ ਅਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਹਰੇਕ ਡੇਟਾਬੇਸ ਦੀ ਆਪਣੀ ਵਿਧੀ ਹੁੰਦੀ ਹੈ।
4. ਆਸ਼ਾਵਾਦੀ ਬਲਾਕਿੰਗ ਬਚਾਅ ਲਈ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਆਮ ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ.
5. ਗੰਦੇ ਰੀਡ ਅਤੇ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਿਗਾੜ ਹਨ.
6. ਡੇਟਾਬੇਸ ਅਤੇ ਉਪਭੋਗਤਾ ਹਮੇਸ਼ਾ ਕਾਰਵਾਈ ਦੇ ਕੋਰਸ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।
7. ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀ ਸ਼ਾਰਡਿੰਗ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਾਹਰ ਲਿਜਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
8. ਸਵੈ-ਇੰਕਰੀਮੈਂਟ ਕਰਨਾ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।
9. ਪੁਰਾਣਾ ਡੇਟਾ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲਾਕ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
10. ਕਿਸੇ ਵੀ ਸਮੇਂ ਦੇ ਸਰੋਤਾਂ ਲਈ ਵਿਗਾੜ ਆਮ ਹੁੰਦੇ ਹਨ।
11. ਦੇਰੀ ਦੇ ਕਈ ਅਰਥ ਹਨ।
12. ਕਿਸੇ ਖਾਸ ਲੈਣ-ਦੇਣ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
13. ਨੇਸਟਡ ਲੈਣ-ਦੇਣ ਖਤਰਨਾਕ ਹੋ ਸਕਦੇ ਹਨ।
14. ਲੈਣ-ਦੇਣ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਸਟੇਟ ਨਾਲ ਜੋੜਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
15. ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਕਾਰ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਬਾਰੇ ਬਹੁਤ ਕੁਝ ਦੱਸ ਸਕਦੇ ਹਨ।
16. ਔਨਲਾਈਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੁਸ਼ਕਲ ਹੈ, ਪਰ ਸੰਭਵ ਹੈ।
17. ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਅਨਿਸ਼ਚਿਤਤਾ ਵਿੱਚ ਵਾਧਾ ਕਰਦਾ ਹੈ।

ਮੈਂ ਇਸ ਲੇਖ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ 'ਤੇ ਉਨ੍ਹਾਂ ਦੇ ਫੀਡਬੈਕ ਲਈ ਇਮੈਨੁਅਲ ਓਡੇਕੇ, ਰੀਨ ਹੈਨਰਿਕਸ ਅਤੇ ਹੋਰਾਂ ਦਾ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹਾਂਗਾ।

ਤੁਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋ ਜੇਕਰ 99,999% ਵਾਰ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣ ਰਿਹਾ ਹੈ।

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

ਸਪੈਨਰ ਲਈ 99,999% ਦੀ ਉਪਲਬਧਤਾ ਦਰ ਦੇ ਨਾਲ (ਗੂਗਲ ਦਾ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਵੰਡਿਆ ਡੇਟਾਬੇਸ), ਗੂਗਲ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਕਿ ਸਿਰਫ 7,6% ਸਮੱਸਿਆਵਾਂ ਨੈੱਟਵਰਕ ਨਾਲ ਸਬੰਧਤ ਹਨ। ਉਸੇ ਸਮੇਂ, ਕੰਪਨੀ ਆਪਣੇ ਵਿਸ਼ੇਸ਼ ਨੈੱਟਵਰਕ ਨੂੰ ਉੱਚ ਉਪਲਬਧਤਾ ਦਾ "ਮੁੱਖ ਥੰਮ੍ਹ" ਕਹਿੰਦੀ ਹੈ। ਅਧਿਐਨ ਬੇਲਿਸ ਅਤੇ ਕਿੰਗਸਬਰੀ, 2014 ਵਿੱਚ ਕਰਵਾਏ ਗਏ, ਇੱਕ ਨੂੰ ਚੁਣੌਤੀ ਦਿੰਦਾ ਹੈ "ਵਿਤਰਿਤ ਕੰਪਿਊਟਿੰਗ ਬਾਰੇ ਗਲਤ ਧਾਰਨਾਵਾਂ", ਜਿਸ ਨੂੰ ਪੀਟਰ ਡਿਊਸ਼ ਨੇ 1994 ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਸੀ। ਕੀ ਨੈੱਟਵਰਕ ਅਸਲ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਹੈ?

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

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

ACID ਦਾ ਮਤਲਬ ਬਹੁਤ ਸਾਰੀਆਂ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ

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

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

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

ਇਸ ਬਾਰੇ ਬਹਿਸ ਕਿ ਕੀ MongoDB ACID ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਵਰਜਨ 4 ਦੇ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਜਾਰੀ ਹੈ। ਮੋਂਗੋਡੀਬੀ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ ਲਾਗਿੰਗ, ਹਾਲਾਂਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਡੇਟਾ ਹਰ 60 ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਤੋਂ ਵੱਧ ਡਿਸਕ ਲਈ ਵਚਨਬੱਧ ਨਹੀਂ ਸੀ। ਹੇਠਾਂ ਦਿੱਤੇ ਦ੍ਰਿਸ਼ ਦੀ ਕਲਪਨਾ ਕਰੋ: ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੋ ਰਾਈਟਸ ਪੋਸਟ ਕਰਦੀ ਹੈ (w1 ਅਤੇ w2)। MongoDB ਸਫਲਤਾਪੂਰਵਕ w1 ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਪਰ ਹਾਰਡਵੇਅਰ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ w2 ਗੁਆਚ ਜਾਂਦਾ ਹੈ।

ਦ੍ਰਿਸ਼ ਨੂੰ ਦਰਸਾਉਂਦਾ ਚਿੱਤਰ। ਮੋਂਗੋਡੀਬੀ ਡਿਸਕ 'ਤੇ ਡਾਟਾ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ

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

ਹਰੇਕ ਡੇਟਾਬੇਸ ਦੀ ਆਪਣੀ ਇਕਸਾਰਤਾ ਅਤੇ ਅਲੱਗ-ਥਲੱਗ ਵਿਧੀ ਹੁੰਦੀ ਹੈ

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

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

ਮੌਜੂਦਾ ਸਮਕਾਲੀ ਮਾਡਲਾਂ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦੀ ਸਮੀਖਿਆ

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

SQL ਸਟੈਂਡਰਡ ਹੇਠਾਂ ਦਿੱਤੇ ਆਈਸੋਲੇਸ਼ਨ ਪੱਧਰਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਦਾ ਹੈ:

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

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

ਆਈਸੋਲੇਸ਼ਨ ਪੱਧਰਾਂ ਲਈ ਸਮਰਥਨ ਅਕਸਰ ਇੱਕ ਦਿੱਤੇ ਗਏ DBMS ਵਿੱਚ ਇਸ਼ਤਿਹਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਸਦੇ ਵਿਵਹਾਰ ਦਾ ਸਿਰਫ ਧਿਆਨ ਨਾਲ ਅਧਿਐਨ ਕਰਨ ਨਾਲ ਹੀ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।

ਵੱਖ-ਵੱਖ DBMSs ਲਈ ਵੱਖ-ਵੱਖ ਆਈਸੋਲੇਸ਼ਨ ਪੱਧਰਾਂ 'ਤੇ ਇਕਸਾਰਤਾ ਸੰਬੰਧੀ ਵਿਗਾੜਾਂ ਦੀ ਸਮੀਖਿਆ

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

ਆਸ਼ਾਵਾਦੀ ਬਲਾਕਿੰਗ ਬਚਾਅ ਲਈ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਆਮ ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ.

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

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

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

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

ਗੰਦੇ ਰੀਡ ਅਤੇ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਿਗਾੜ ਹਨ

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

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

ਉਦਾਹਰਨ ਲਈ, ਆਓ ਇੱਕ ਨਿਗਰਾਨੀ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ ਜਿਸ ਲਈ ਇੱਕ ਓਪਰੇਟਰ ਨੂੰ ਹਰ ਸਮੇਂ ਆਨ-ਕਾਲ ਹੋਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

ਡੇਟਾਬੇਸ ਅਤੇ ਉਪਭੋਗਤਾ ਹਮੇਸ਼ਾ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਕੀ ਕਰਨਾ ਹੈ

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

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

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

ਨਤੀਜਾ1 = T1() // ਅਸਲ ਨਤੀਜੇ ਵਾਅਦੇ ਹਨ
ਨਤੀਜਾ2 = T2()

ਜੇਕਰ ਪਰਮਾਣੂ ਦੀ ਲੋੜ ਹੈ (ਭਾਵ, ਜਾਂ ਤਾਂ ਸਾਰੇ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਪੂਰਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਅਧੂਰਾ ਛੱਡ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ) ਅਤੇ ਕ੍ਰਮ ਦੇ ਮਾਮਲੇ, ਤਾਂ ਓਪਰੇਸ਼ਨ T1 ਅਤੇ T2 ਇੱਕ ਸਿੰਗਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀ ਸ਼ਾਰਡਿੰਗ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਾਹਰ ਲਿਜਾਇਆ ਜਾ ਸਕਦਾ ਹੈ

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

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

ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਜਿਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰਾਂ ਨੂੰ ਸ਼ਾਰਡਿੰਗ ਸੇਵਾ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

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

ਸਵੈ-ਇੰਕਰੀਮੈਂਟ ਕਰਨਾ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ

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

• ਇੱਕ ਵਿਤਰਿਤ ਡੇਟਾਬੇਸ ਵਿੱਚ, ਸਵੈ-ਵਧਨਾ ਇੱਕ ਗੰਭੀਰ ਸਮੱਸਿਆ ਹੈ। ID ਬਣਾਉਣ ਲਈ, ਇੱਕ ਗਲੋਬਲ ਲਾਕ ਦੀ ਲੋੜ ਹੈ। ਇਸਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ UUID ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ: ਇਸ ਲਈ ਵੱਖ-ਵੱਖ ਡਾਟਾਬੇਸ ਨੋਡਾਂ ਵਿਚਕਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤਾਲੇ ਦੇ ਨਾਲ ਸਵੈ-ਵਧਾਉਣ ਨਾਲ ਵਿਵਾਦ ਪੈਦਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਵੰਡੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸੰਮਿਲਨਾਂ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਕੁਝ DBMSs (ਉਦਾਹਰਨ ਲਈ, MySQL) ਨੂੰ ਮਾਸਟਰ-ਮਾਸਟਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਸੰਰਚਨਾ ਅਤੇ ਵਧੇਰੇ ਧਿਆਨ ਨਾਲ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਅਤੇ ਕੌਂਫਿਗਰ ਕਰਨ ਵੇਲੇ ਗਲਤੀਆਂ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਜੋ ਰਿਕਾਰਡਿੰਗ ਅਸਫਲਤਾਵਾਂ ਵੱਲ ਲੈ ਜਾਵੇਗਾ।
• ਕੁਝ ਡਾਟਾਬੇਸ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀਆਂ ਦੇ ਅਧਾਰ 'ਤੇ ਵਿਭਾਜਨ ਐਲਗੋਰਿਦਮ ਹੁੰਦੇ ਹਨ। ਲਗਾਤਾਰ ਆਈ.ਡੀ. ਕੁਝ ਭਾਗਾਂ 'ਤੇ ਅਣਪਛਾਤੇ ਹੌਟ ਸਪਾਟ ਅਤੇ ਵਧੇ ਹੋਏ ਲੋਡ ਵੱਲ ਲੈ ਜਾ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਕੁਝ ਵਿਹਲੇ ਰਹਿੰਦੇ ਹਨ।
• ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਇੱਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਕਤਾਰ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। ਰਿਕਾਰਡਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਦੇ ਬਿਹਤਰ ਤਰੀਕਿਆਂ ਨਾਲ, ਕ੍ਰਮਵਾਰ ਆਈਡੀ ਟੇਬਲਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਾਲਮ ਨੂੰ ਅਰਥਹੀਣ ਮੁੱਲਾਂ ਨਾਲ ਭਰੇ ਇੱਕ ਬੇਕਾਰ ਕਾਲਮ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ, ਜਦੋਂ ਵੀ ਸੰਭਵ ਹੋਵੇ, ਕਿਰਪਾ ਕਰਕੇ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਵਿਲੱਖਣ ਅਤੇ ਕੁਦਰਤੀ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ (ਉਦਾਹਰਨ ਲਈ ਉਪਭੋਗਤਾ ਨਾਮ) ਦੀ ਚੋਣ ਕਰੋ।

ਕਿਸੇ ਪਹੁੰਚ 'ਤੇ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੰਡੈਕਸਿੰਗ, ਵਿਭਾਗੀਕਰਨ, ਅਤੇ ਸ਼ਾਰਡਿੰਗ 'ਤੇ ਸਵੈ-ਵਧਣ ਵਾਲੇ IDs ਅਤੇ UUIDs ਦੇ ਪ੍ਰਭਾਵ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।

ਪੁਰਾਣਾ ਡਾਟਾ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਲਾਕ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ

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

ਥੋੜ੍ਹਾ ਜਿਹਾ ਪੁਰਾਣਾ ਡੇਟਾ ਪੜ੍ਹਨਾ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਡੇਟਾ ਤੋਂ ਵਿਸ਼ਲੇਸ਼ਣ ਤਿਆਰ ਕਰਦੇ ਹੋ ਜਾਂ ਲਗਭਗ ਕੁੱਲ ਮੁੱਲਾਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹੋ।

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

ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਸਥਾਨਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਡੇਟਾ ਪੜ੍ਹਦਾ ਹੈ ਜੋ 5 ਸਕਿੰਟ ਪੁਰਾਣਾ ਹੈ, ਭਾਵੇਂ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਪ੍ਰਸ਼ਾਂਤ ਮਹਾਸਾਗਰ ਦੇ ਦੂਜੇ ਪਾਸੇ ਉਪਲਬਧ ਹੋਵੇ

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

ਕਿਸੇ ਵੀ ਸਮੇਂ ਸਰੋਤ ਵਿਗਾੜ ਦੇ ਅਧੀਨ ਹੁੰਦੇ ਹਨ

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

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

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

ਸਥਿਤੀ ਇਸ ਤੱਥ ਤੋਂ ਵਿਗੜ ਗਈ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਡੇਟਾਬੇਸ ਅਕਸਰ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਸਥਿਤ ਹੁੰਦੇ ਹਨ (ਜੇ ਵੱਖ-ਵੱਖ ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਨਹੀਂ)। ਇਸ ਤਰ੍ਹਾਂ, ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਵੰਡੇ ਗਏ DB ਨੋਡਾਂ 'ਤੇ ਹੀ ਸਮਾਂ ਵੱਖਰਾ ਨਹੀਂ ਹੋਵੇਗਾ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ 'ਤੇ ਵੀ ਵੱਖਰਾ ਹੋਵੇਗਾ।

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

• TrueTime ਦੋ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ: GPS ਅਤੇ ਪਰਮਾਣੂ ਘੜੀਆਂ। ਇਹਨਾਂ ਘੜੀਆਂ ਵਿੱਚ ਗੈਰ-ਸਬੰਧਿਤ ਅਸਫਲ ਮੋਡ ਹੁੰਦੇ ਹਨ। [ਵੇਰਵਿਆਂ ਲਈ ਪੰਨਾ 5 ਦੇਖੋ ਇੱਥੇ - ਲਗਭਗ ਅਨੁਵਾਦ।), ਇਸ ਲਈ ਉਹਨਾਂ ਦੀ ਸਾਂਝੀ ਵਰਤੋਂ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ।
• TrueTime ਵਿੱਚ ਇੱਕ ਅਸਧਾਰਨ API ਹੈ। ਇਹ ਮਾਪ ਗਲਤੀ ਅਤੇ ਇਸ ਵਿੱਚ ਬਣੀ ਅਨਿਸ਼ਚਿਤਤਾ ਦੇ ਨਾਲ ਇੱਕ ਅੰਤਰਾਲ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਸਮੇਂ ਦਾ ਅਸਲ ਪਲ ਅੰਤਰਾਲ ਦੀਆਂ ਉਪਰਲੀਆਂ ਅਤੇ ਹੇਠਲੇ ਸੀਮਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਕਿਤੇ ਹੈ। ਸਪੈਨਰ, ਗੂਗਲ ਦਾ ਵਿਤਰਿਤ ਡੇਟਾਬੇਸ, ਉਦੋਂ ਤੱਕ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਕਹਿਣਾ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਮੌਜੂਦਾ ਸਮਾਂ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਹੈ। ਇਹ ਵਿਧੀ ਸਿਸਟਮ ਵਿੱਚ ਕੁਝ ਲੇਟੈਂਸੀ ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਜੇਕਰ ਮਾਸਟਰਾਂ 'ਤੇ ਅਨਿਸ਼ਚਿਤਤਾ ਜ਼ਿਆਦਾ ਹੈ, ਪਰ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਵੰਡੀ ਗਈ ਸਥਿਤੀ ਵਿੱਚ ਵੀ ਸ਼ੁੱਧਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।

ਸਪੈਨਰ ਕੰਪੋਨੈਂਟ TrueTime ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿੱਥੇ TT.now() ਇੱਕ ਅੰਤਰਾਲ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਸਪੈਨਰ ਸਿਰਫ਼ ਉਸ ਬਿੰਦੂ ਤੱਕ ਸੌਂਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਵਿਸ਼ਵਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਮੌਜੂਦਾ ਸਮਾਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬਿੰਦੂ ਲੰਘ ਗਿਆ ਹੈ।

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

ਦੇਰੀ ਦੇ ਕਈ ਅਰਥ ਹਨ

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

ਕਿਸੇ ਖਾਸ ਲੈਣ-ਦੇਣ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ

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

• ਸੰਬੰਧਿਤ ਟੇਬਲਾਂ ਵਿੱਚ ਨਿਰਧਾਰਤ ਰੁਕਾਵਟਾਂ ਅਤੇ ਕਤਾਰ ਪੈਡਿੰਗ ਦੇ ਨਾਲ ਸਾਰਣੀ X (50 ਮਿਲੀਅਨ ਕਤਾਰਾਂ ਦੇ ਨਾਲ) ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਕਤਾਰ ਸ਼ਾਮਲ ਕਰਨ ਵੇਲੇ ਥ੍ਰਰੂਪੁਟ ਅਤੇ ਲੇਟੈਂਸੀ ਲਿਖੋ।
• ਦੋਸਤਾਂ ਦੀ ਔਸਤ ਸੰਖਿਆ 500 ਹੋਣ 'ਤੇ ਕਿਸੇ ਖਾਸ ਉਪਭੋਗਤਾ ਦੇ ਦੋਸਤਾਂ ਦੇ ਦੋਸਤਾਂ ਨੂੰ ਦਿਖਾਉਣ ਵਿੱਚ ਦੇਰੀ।
• ਉਪਭੋਗਤਾ ਦੇ ਇਤਿਹਾਸ ਤੋਂ ਚੋਟੀ ਦੀਆਂ 100 ਐਂਟਰੀਆਂ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਲੇਟੈਂਸੀ ਜਦੋਂ ਉਪਭੋਗਤਾ ਪ੍ਰਤੀ ਘੰਟੇ X ਐਂਟਰੀਆਂ ਦੇ ਨਾਲ 500 ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਦਾ ਅਨੁਸਰਣ ਕਰਦਾ ਹੈ।

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

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

ਨੇਸਟਡ ਲੈਣ-ਦੇਣ ਖਤਰਨਾਕ ਹੋ ਸਕਦੇ ਹਨ

ਹਰੇਕ DBMS ਨੇਸਟਡ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਉਹ ਕਰਦੇ ਹਨ, ਤਾਂ ਅਜਿਹੇ ਲੈਣ-ਦੇਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਅਚਾਨਕ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਹਮੇਸ਼ਾ ਆਸਾਨ ਨਹੀਂ ਹੁੰਦਾ (ਭਾਵ, ਇਹ ਸਪੱਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਸੇ ਕਿਸਮ ਦੀ ਵਿਗਾੜ ਹੈ)।

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

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

ਮਲਟੀਪਲ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਨਾਲ ਇੱਕ ਡੇਟਾ ਪਰਤ ਦੀ ਕਲਪਨਾ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ newAccount) ਪਹਿਲਾਂ ਹੀ ਇਸ ਦੇ ਆਪਣੇ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਉੱਚ-ਪੱਧਰੀ ਵਪਾਰਕ ਤਰਕ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਚਲਾਉਂਦੇ ਹੋ ਜੋ ਇਸਦੇ ਆਪਣੇ ਲੈਣ-ਦੇਣ ਦੇ ਅੰਦਰ ਚਲਦਾ ਹੈ? ਇਸ ਕੇਸ ਵਿੱਚ ਅਲੱਗਤਾ ਅਤੇ ਇਕਸਾਰਤਾ ਕੀ ਹੋਵੇਗੀ?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

ਲੈਣ-ਦੇਣ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਸਟੇਟ ਨਾਲ ਜੋੜਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਕਾਰ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਬਾਰੇ ਬਹੁਤ ਕੁਝ ਦੱਸ ਸਕਦੇ ਹਨ

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

SELECT * FROM articles where author = "rakyll" order by title;

ਨਤੀਜੇ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ:

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

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

ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਕਾਰ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਕੁਝ ਮੈਟ੍ਰਿਕਸ ਸ਼ੋਰ ਦੇ ਅਧੀਨ ਹੋ ਸਕਦੇ ਹਨ (ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਲੇਟੈਂਸੀ ਜਾਂ CPU ਸਮੇਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ)। ਸ਼ਡਿਊਲਰਸ ਲਈ ਇੱਕ ਵਧੀਆ ਜੋੜ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਰਗ ਨੂੰ ਟਰੇਸ ਕਰਨ ਅਤੇ ਟਰੈਕ ਕਰਨ ਲਈ ਟੂਲ ਹਨ। ਉਹ ਤੁਹਾਨੂੰ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਨਿਦਾਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ (ਹਾਏ, ਸਾਰੇ DBMS ਅਜਿਹੇ ਸਾਧਨ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ ਹਨ)।

ਔਨਲਾਈਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੁਸ਼ਕਲ ਹੈ ਪਰ ਸੰਭਵ ਹੈ

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

ਵੱਖ-ਵੱਖ ਔਨਲਾਈਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਡਲ ਹਨ। ਇੱਥੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ:

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

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

ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਅਨਿਸ਼ਚਿਤਤਾ ਵਿੱਚ ਵਾਧਾ ਕਰਦਾ ਹੈ

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

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

...

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

PS

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

• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ: ਅਸੀਂ ਇਹ ਸਭ ਗਲਤ ਕੀਤਾ ਹੈ";
• «ਸੇਵਾ ਜਾਲ: ਹਰ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਸਭ ਤੋਂ ਗਰਮ ਤਕਨਾਲੋਜੀ ਬਾਰੇ ਕੀ ਜਾਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ".

ਸਰੋਤ: www.habr.com