07 ਅਗ 2025·8 ਮਿੰਟ
ਵੰਡੇ ਡੇਟਾਬੇਸ: ਇਕਸਾਰਤਾ ਦੇ ਬਦਲੇ ਉਪਲਬਧਤਾ
ਜਾਣੋ ਕਿ ਵੰਡੇ ਹੋਏ ਡੇਟਾਬੇਸ ਕਿਉਂ ਅਕਸਰ ਇਕਸਾਰਤਾ ਨੂੰ ਢਿਲਾ ਕਰਕੇ ਫੇਲੀਆਂ ਦੌਰਾਨ ਉਪਲਬਧ ਰਹਿੰਦੇ ਹਨ, CAP ਤੇ ਕੋਅਰਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀ ਦਿਸ਼ਾ ਕਦੋਂ ਚੁਣਨੀ ਚਾਹੀਦੀ ਹੈ।
ਜਾਣੋ ਕਿ ਵੰਡੇ ਹੋਏ ਡੇਟਾਬੇਸ ਕਿਉਂ ਅਕਸਰ ਇਕਸਾਰਤਾ ਨੂੰ ਢਿਲਾ ਕਰਕੇ ਫੇਲੀਆਂ ਦੌਰਾਨ ਉਪਲਬਧ ਰਹਿੰਦੇ ਹਨ, CAP ਤੇ ਕੋਅਰਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀ ਦਿਸ਼ਾ ਕਦੋਂ ਚੁਣਨੀ ਚਾਹੀਦੀ ਹੈ।
ਜਦੋਂ ਇੱਕ ਡੇਟਾਬੇਸ ਕਈ ਮਸ਼ੀਨਾਂ (ਰੀਪਲਿਕਾ) 'ਤੇ ਵੰਡਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਅਤੇ ਲਚੀਲਾਪਣ ਮਿਲਦਾ ਹੈ—ਪਰ ਇੱਕ ਸਮੇ ਵਿੱਚ ਉਹ ਮਸ਼ੀਨ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਰਹਿਣ ਜਾਂ ਉਹ ਇੱਕ ਦੂਜੇ ਨਾਲ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰ ਪਉਂਦੀਆਂ।
ਇਕਸਾਰਤਾ ਦਾ ਮਤਲਬ ਹੈ: ਇੱਕ ਸਫਲ ਲਿਖਤ ਤੋਂ ਬਾਅਦ, ਹਰ ਕੋਈ ਉਹੀ ਵੈਲਯੂ ਪੜ੍ਹਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਪ੍ਰੋਫ਼ਾਈਲ ਈਮੇਲ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਅਗਲਾ ਪੜ੍ਹਾਈ—ਭਾਵੇਂ ਕਿਸੇ ਵੀ ਰੀਪਲਿਕਾ ਤੋਂ—ਨਵਾਂ ਈਮੇਲ ਵਾਪਸ ਕਰੇ।
ਅਮਲ ਵਿੱਚ, ਉਹ ਸਿਸਟਮ ਜੋ ਇਕਸਾਰਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ, ਖ਼ਰਾਬੀ ਦੌਰਾਨ ਕੁਝ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਣ ਜਾਂ ਰੱਦ ਵੀ ਕਰ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਵਿਵਾਦਪੂਰਨ ਜਵਾਬਾਂ ਦਿੱਤੀਆਂ ਨਾ ਜਾਣ।
ਉਪਲਬਧਤਾ ਦਾ ਮਤਲਬ ਹੈ: ਸਿਸਟਮ ਹਰ ਬੇਨਤੀ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਕੁਝ ਸਰਵਰ ਡਾਊਨ ਹੋਣ ਜਾਂ ਕਨੈਕਟਿਵਿਟੀ ਖਰਾਬ ਹੋਣ ਦੇ ਬਾਵਜੂਦ। ਤੁਹਾਨੂੰ ਸ਼ਾਇਦ ਤਾਜ਼ਾ ਡੇਟਾ ਨਾ ਮਿਲੇ, ਪਰ ਜਵਾਬ ਤਾਂ ਮਿਲੇਗਾ।
ਅਮਲ ਵਿੱਚ, ਉਹ ਸਿਸਟਮ ਜੋ ਉਪਲਬਧਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ, ਲਿਖਤਾਂ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਪੜ੍ਹਾਈਆਂ ਦੇ ਸਕਦੀਆਂ ਹਨ ਭਾਵੇਂ ਰੀਪਲਿਕਾ ਅਸਹਿਮਤ ਹੋਣ ਅਤੇ ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਫਰਕਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਸਹੀ ਕਰਦਾ ਹੈ।
ਇੱਕ ਵਪਾਰ-ਆਫ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਹਾਲਤ ਵਿੱਚ ਦੋਹਾਂ ਲਕਸ਼ਾਂ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜੇ رੀਪਲਿਕਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੰਯੋਜਿਤ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ, ਤਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਜਾਂ ਤਾਂ:
ਸਹੀ ਸੰਤੁਲਨ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਸਹਨ ਕਰ ਸਕਦੇ ਹੋ: ਇੱਕ ਛੋਟਾ ਆਊਟੇਜ ਜਾਂ ਇੱਕ ਛੋਟਾ ਸਮਾਂ ਜਦੋਂ ਡੇਟਾਗਲਤ/ਪੁਰਾਣਾ ਹੋਵੇ। ਅਸਲ ਦੀਆਂ ਸਿਸਟਮਾਂ ਅਕਸਰ ਦੋਹਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਬਿੰਦੂ ਚੁਣ ਲੈਂਦੀਆਂ ਹਨ—ਅਤੇ ਇਸ ਵਪਾਰ-ਆਫ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦੀਆਂ ਹਨ।
ਜਦੋਂ ਡੇਟਾ ਕਈ ਨੋਡਾਂ (ਮਸ਼ੀਨਾਂ) 'ਤੇ ਸਟੋਰ ਅਤੇ ਸਰਵ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਕੋਆਰਡੀਨੇਟ ਕਰਦੇ ਹਨ, ਤਦੋਂ ਉਹ "ਵੰਡਿਆ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਹ ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਹੀ ਲੱਗ ਸਕਦਾ ਹੈ—ਪਰ ਪਿੱਛੇ, ਬੇਨਤੀਆਂ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ ਦੁਆਰਾ ਹੇਠਾਂ-ਚਲਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਵੰਡੇ ਹੋਏ ਡੇਟਾਬੇਸ ਡੇਟਾ ਨੂੰ ਨਕਲ ਕਰਦੇ ਹਨ: ਇਕੋ ਰਿਕਾਰਡ ਕਈ ਨੋਡਾਂ 'ਤੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਇਹ ਇਸ ਲਈ ਕਰਦੀਆਂ ਹਨ ਕਿ:
ਰਿਪਲਿਕੇਸ਼ਨ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ, ਪਰ ਇਹ ਸਹੀ ਪ੍ਰਸ਼ਨ ਉੱਠਾਉਂਦਾ ਹੈ: ਜੇ ਦੋ ਨੋਡਾਂ ਕੋਲ ਇਕੋ ਡੇਟਾ ਦੀ ਨਕਲ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਵੋਗੇ ਕਿ ਉਹ ਹਮੇਸ਼ਾਂ ਸਹਿਮਤ ਰਹਿਣ?
ਇੱਕ ਹੀ ਸਰਵਰ 'ਤੇ, "ਡਾਊਨ" ਆਮ طور 'ਤੇ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ: ਮਸ਼ੀਨ ਚੱਲ ਰਹੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਵੰਡੇ ਸਿਸਟਮ ਵਿੱਚ, ਖਰਾਬੀ ਅਕਸਰ ਅੰਸ਼ਿਕ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਨੋਡ ਜਿੰਦਾ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਧੀਮਾ ਹੋਵੇ। ਇੱਕ ਨੈੱਟਵਰਕ ਲਿੰਕ ਪੈਕਟ ਗੁਮ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਪੂਰਾ ਰੈਕ ਕੁਨੈਕਟਿਵਿਟੀ ਗੁਆ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸਿੱਟਾ ਕਲੱਸਟਰ ਚੱਲ ਰਿਹਾ ਹੋਵੇ।
ਇਹ ਗੱਲ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ ਨੋਡ ਤੁਰੰਤ ਇਹ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਕਿ ਦੂਜਾ ਨੋਡ ਸੱਚ-ਮੁੱਚ ਡਾਊਨ ਹੈ, ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਣਪਹੁੰਚ ਯੋਗ ਹੈ, ਜਾਂ ਸਿਰਫ਼ ਦੇਰ ਹੋ ਰਿਹਾ ਹੈ। ਉਹਨਾਂ ਦੇ ਪਾਸIncoming Reads and Writes ਦੇ ਨਾਲ ਫੈਸਲਾ ਕਰਨ ਲਈ ਸਮਾਂ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸਰਵਰ ਨਾਲ, ਇੱਕ ਸਰਸ ਯਥਾਰਥ ਹੁੰਦਾ ਹੈ: ਹਰ ਪੜ੍ਹਾਈ ਆਖਰੀ ਸਫਲ ਲਿਖਤ ਦੇਖਦੀ ਹੈ।
ਕਈ ਨੋਡਾਂ ਨਾਲ, "ਆਖਰੀ" ਕੋਆਰਡੀਨੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕ ਲਿਖਤ ਨੋਡ A 'ਤੇ ਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ ਪਰ ਨੋਡ B ਤੱਕ ਨਹੀਂ ਪੁੱਜਦੀ, ਤਾਂ ਡੇਟਾਬੇਸ ਕੀ ਕਰੇ:
ਇਹ ਤਣਾਅ—ਅਪਰਿਪੂਰਕ ਨੈੱਟਵਰਕ ਦੁਆਰਾ ਸਚ ਹੋਇਆ—ਇਸ ਲਈ ਵੰਡਣ ਨਾਲ ਨਿਯਮ ਬਦਲ ਜਾਂਦੇ ਹਨ।
ਨੈੱਟਵਰਕ ਪਾਰਟੀਸ਼ਨ ਉਹ ਹੈ ਜਦੋਂ ਉਹ ਨੋਡ ਜੋ ਇੱਕ ਡੇਟਾਬੇਸ ਵਾਂਗ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਉਹਨਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਨੋਡ ਹੋ ਸਕਦਾ ਹੈ ਚੱਲ ਰਹੇ ਹੋਣ ਅਤੇ ਸਹੀ ਹੋਣ, ਪਰ ਉਹ ਆਪਣਾ ਸੁਨੇਹਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਾਂਝਾ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਇਹ ਕਿਸੇ ਖਰਾਬ ਸਵਿੱਚ, ਓਵਰਲੋਡਡ ਲਿੰਕ, ਗਲਤ ਰੂਟਿੰਗ, ਗਲਤ ਫਾਇਰਵਾਲ ਨਿਯਮ, ਜਾਂ ਕਲਾਉਡ 'ਚ ਕੋਈ ਨੌਜ਼ੀ ਨਤੀਜੇ ਵਜੋਂ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਸਿਸਟਮ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਫੈਲ ਜਾਂਦਾ ਹੈ (ਰੈਕ, ਜੋਨ, ਜਾਂ ਰੀਜਨ), ਤਾਂ ਹੋਰ ਹਰ ਹੱਪ 'ਤੇ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਨਹੀਂ ਰਹਿੰਦੀ। ਨੈੱਟਵਰਕ ਪੈਕਟ ਗੁਮ ਕਰਦੇ ਹਨ, ਦੇਰੀਆਂ ਲਿਆਉਂਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰੀ "ਦੁੱਧ-ਟੁਕੜੇ" ਬਣ ਜਾਂਦੇ ਹਨ। ਛੋਟੀ ਪੱਧਰ 'ਤੇ ਇਹ ਘਟਨਾਵਾਂ ਦਰਅਸਲ ਹੀ ਕਿੱਤੇ ਕੁਮ ਹੁੰਦੀਆਂ ਹਨ; ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਇਹ ਰੋਜ਼ਮਰਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਵਿਛੋੜੀ ਵੀ ਗਿਣਤੀ ਰੱਖਦੀ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ ਕੀ ਹੋਇਆ ਇਹਨਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋਣ।
ਪਾਰਟੀਸ਼ਨ ਦੌਰਾਨ, ਦੋਹਾਂ ਪਾਸੇ ਬੇਨਤੀਆਂ ਮਿਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਜੇ ਯੂਜ਼ਰ ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ ਲਿਖ ਸਕਦੇ ਹਨ, ਤਾਂ ਹਰ ਪਾਸਾ ਉਹ ਅਪਡੇਟ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ ਜੋ ਦੂਜੇ ਪਾਸੇ ਨਹੀਂ ਦੇਖਦਾ।
ਉਦਾਹਰਨ: ਨੋਡ A ਇਕ ਯੂਜ਼ਰ ਦਾ ਪਤਾ "New Street" ਕਰਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ ਨੋਡ B ਇਸਨੂੰ "Old Street Apt 2" ਕਰਦਾ ਹੈ। ਹਰ ਪਾਸਾ ਆਪਣੀ ਲਿਖਤ ਨੂੰ ਨਵਾਂ ਸਮਝਦਾ ਹੈ—ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਰੀਅਲ-ਟਾਈਮ 'ਚ ਨੋਟਸ ਮਿਲਣੇ ਦਾ ਤਰੀਕਾ ਨਹੀਂ।
ਪਾਰਟੀਸ਼ਨ ਸਾਫ਼ ਏਰਰ ਸੁਨੇਹਿਆਂ ਵਜੋਂ ਨਹੀਂ ਆਉਂਦੇ; ਉਹ ਉਲਝਣ ਭਰਿਆ ਵਰਤਾਰਾ ਵਜੋਂ ਆਉਂਦੇ ਹਨ:
ਇਹ ਉਹ ਦਬਾਅ-ਬਿੰਦੂ ਹਨ ਜੋ ਇਕ ਚੋਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ: ਜਦੋਂ ਨੈੱਟਵਰਕ ਸੰਚਾਰ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਇੱਕ ਵੰਡਿਆ ਹੋਇਆ ਡੇਟਾਬੇਸ ਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਹ ਇਕਸਾਰਤਾ ਨੂੰ ਤਰਜੀਹ ਦੇਵੇ ਜਾਂ ਉਪਲਬਧਤਾ ਨੂੰ।
CAP ਇੱਕ ਸੰਖੇਪ ਤਰੀਕਾ ਹੈ ਇਹ ਵੇਖਾਉਣ ਦਾ ਕਿ ਜਦੋਂ ਡੇਟਾਬੇਸ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਪਾਰਟੀਸ਼ਨ ਨਹੀਂ ਹੁੰਦੀ, ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਦੋਹਾਂ ਇਕਸਾਰਤਾ ਅਤੇ ਉਪਲਬਧਤਾ ਦਿਖਾ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਪਾਰਟੀਸ਼ਨ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਤਰਜੀਹ ਦੇਣੀ ਹੈ:
balance = 100 ਲਿਖਦਾ ਹੈ।balance = 80 ਵਾਪਸ ਕਹੇ।CAP ਦਾ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕਿ "ਹਮੇਸ਼ਾ ਸਿਰਫ ਦੋ ਚੁਣੋ"।ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਪਾਰਟੀਸ਼ਨ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਦੋਹਾਂ ਦਾ ਵਾਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦੇ।ਪਾਰਟੀਸ਼ਨ ਦੇ ਬਾਹਰ, ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਅਕਸਰ ਦੋਹਾਂ ਦੇ ਨੇੜੇ ਹੋ ਸਕਦੇ ਹਨ—ਪਰ ਨੈੱਟਵਰਕ ਮਿਸਬੀਹੇਵ ਕਰੇ ਤਾਂ ਇਹ ਸੀਮਾ ਵੇਖਾਈ ਦੇਂਦੀ ਹੈ।
ਇਕਸਾਰਤਾ ਚੁਣਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੇਟਾਬੇਸ "ਹਰ ਕੋਈ ਇੱਕੋ ਸੱਚਾਈ ਵੇਖੇ" ਨੂੰ ਉੱਚ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦਾ ਹੈ ਬਜਾਏ "ਹਮੇਸ਼ਾਂ ਜਵਾਬ ਦੇਣ" ਦੇ।ਅਮਲੀ ਰੂਪ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਿਹਨੂੰ ਕਈ ਵਾਰੀ linearizable ਕਿਹਾ ਜਾਂਦਾ ਹੈ: ਜਦੋਂ ਇੱਕ ਲਿਖਤ ਮਨਜ਼ੂਰ ਹੋ ਜਾਵੇ, ਕੋਈ ਵੀ ਬਾਅਦੀ ਪੜ੍ਹਾਈ (ਕਿਤੇ ਵੀ) ਓਹੀ ਮੁੱਲ ਵੇਖੇ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਹੀ ਅਪ-ਟੂ-ਡੇਟ ਕਾਪੀ ਹੋਵੇ।
ਜਦੋਂ ਨੈੱਟਵਰਕ ਵੰਡ ਜਾਂਦਾ ਹੈ ਅਤੇ ਰੀਪਲਿਕਾ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਇੱਕ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਵਾਲੀ ਸਿਸਟਮ ਖੁਦਮੁਖਤਿਆਰ ਤੌਰ 'ਤੇ ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ ਸਵਤੰਤਰ ਅਪਡੇਟ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਸਹੀਤਾ ਰੱਖਣ ਲਈ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ:
ਯੂਜ਼ਰ ਦੀ ਨਜ਼ਰ ਵਿੱਚ, ਇਹ ਇੱਕ ਆਊਟੇਜ ਵਰਗਾ ਦਿਸ ਸਕਦਾ ਹੈ ਹਾਲਾਂਕਿ ਕੁਝ ਮਸ਼ੀਨ ਹਜੇ ਵੀ ਚੱਲ ਰਹੀਆਂ ਹਨ।
ਮੁੱਖ ਫਾਇਦਾ ਹੈ ਸਾਦਾ ਸੋਚਣਾ।ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਐਸਾ ਵਿਹਿਵ ਕਰ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਉਹ ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲ ਕਰ ਰਿਹਾ ਹੋਵੇ, ਨਾ ਕਿ ਕਈ ਰੀਪਲਿਕਾ ਜਿਹੜੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ।ਇਸ ਨਾਲ ਉਹ ਅਜਿਹੀਆਂ "ਅਜੀਬ ਘੜੀਆਂ" ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ ਜਿਵੇਂ:
ਤੁਸੀਂ ਆਡਿਟਿੰਗ, ਬਿਲਿੰਗ, ਅਤੇ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਸਾਫ਼ ਮੈਨਟਲ ਮਾਡਲ ਵੀ ਮਿਲਦਾ ਹੈ ਜਿਹੜੀਆਂ ਪਹਿਲੀ ਵਾਰੀ 'ਤੇ ਸਹੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਇਕਸਾਰਤਾ ਦੀਆਂ ਅਸਲ ਲਾਗਤਾਂ ਹਨ:
ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਅਸਥਾਈ ਆਊਟੇਜ ਦੌਰਾਨ ਫੇਲਡ ਬੇਨਤੀਆਂ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਮਹਿੰਗੀ ਲੱਗ ਸਕਦੀ ਹੈ—ਫਿਰ ਵੀ ਇਹ ਸਹੀਤਾ ਲਈ ਸਹੀ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ।
ਉਪਲਬਧਤਾ ਚੁਣਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਣ ਵਾਅਦਾ ਨਿਭਾਉਂਦੇ ਹੋ: ਸਿਸਟਮ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਦੇ ਕੁਝ ਹਿੱਸੇ ਦੇਖਭਾਲ-ਯੋਗ ਨਾ ਹੋਣ।ਅਮਲੀ ਰੂਪ ਵਿੱਚ, "ਉੱਚ ਉਪਲਬਧਤਾ" ਦਾ ਮਤਲਬ "ਕਦੇ-ਕਦੇ ਗਲਤੀਆਂ ਨਹੀਂ" ਨਹੀਂ—ਇਹ ਹੈ ਕਿ ਨੋਡ ਨਾਕਾਮੀਆਂ, ਓਵਰਲੋਡ ਜ਼ਰੂਰਤਾਂ, ਜਾਂ ਟੁੱਟੀਆਂ ਲਿੰਕਾਂ ਦੌਰਾਨ ਵੱਧ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਜਵਾਬ ਮਿਲਦਾ ਹੈ।
ਜਦੋਂ ਨੈੱਟਵਰਕ ਵੰਡ ਜਾਂਦਾ ਹੈ ਅਤੇ ਰੀਪਲਿਕਾ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਇੱਕ ਉਪਲਬਧਤਾ-ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਲਈ ਜ਼ੋਂ ਪਹੁੰਚਯੋਗ ਪਾਸੇ ਤੋਂ ਟ੍ਰੈਫਿਕ ਸਰਵ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ:
ਇਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਪਰ ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਰੀਪਲਿਕਾ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਸੱਚਾਈਆਂ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਤੁਹਾਨੂੰ ਬਿਹਤਰ ਅਪਟਾਈਮ ਮਿਲਦੀ ਹੈ: ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਬਰਾਊਜ਼, ਕਾਰਟ 'ਚ ਆਈਟਮ ਪਾਇਆ, ਟਿੱਪਣੀ ਪੋਸਟ ਕਰ ਸਕਦੇ ਹਨ, ਜਾਂ ਘਟਨਾਵਾਂ ਰਿਕਾਰਡ ਕਰ ਸਕਦੇ ਹਨ ਭਾਵੇਂ ਇੱਕ ਰੀਜਨ ਇਕੱਲਾ ਹੋਵੇ।
ਤੁਹਾਨੂੰ ਸੰਕਟ ਸਮੇਂ ਇੱਕ ਨਰਮ ਯੂਜ਼ਰ ਅਨੁਭਵ ਵੀ ਮਿਲਦਾ ਹੈ।ਟਾਇਮਆਊਟਾਂ ਦੀ ਥਾਂ, ਤੁਹਾਡੀ ਐਪ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ ("ਤੁਹਾਡੀ ਅਪਡੇਟ ਸੇਵ ਕੀਤੀ ਗਈ ਹੈ") ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਿੰਕ ਹੁੰਦੀ ਹੈ।ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗੀ ਅਤੇ ਐਨਾਲਿਟਿਕਲ ਵਰਕਲੋਡ ਲਈ ਇਹ ਵਪਾਰ-ਆਫ ਲਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।
ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਸਟੇਲ ਰੀਡਸ ਦੇ ਸਕਦਾ ਹੈ।ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਰੀਪਲਿਕਾ 'ਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਤੁਰੰਤ ਦੂਜੇ ਰੀਪਲਿਕਾ ਤੋਂ ਪੜ੍ਹਦੇ ਸਮੇਂ ਪੁਰਾਣਾ ਮੁੱਲ ਵੇਖ ਸਕਦਾ ਹੈ।
ਤੁਸੀਂ ਲਿਖਤ ਟੱਕਰਾਂ ਦਾ ਖਤਰਾ ਵੀ ਲੈਂਦੇ ਹੋ।ਦੋ ਯੂਜ਼ਰ (ਜਾਂ ਇੱਕੋ ਯੂਜ਼ਰ ਦੋ ਸਥਾਨਾਂ 'ਤੇ) ਇੱਕੋ ਹੀ ਰਿਕਾਰਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਪਾਸਿਆਂ 'ਤੇ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹਨ।ਜਦੋਂ ਪਾਰਟੀਸ਼ਨ ਠੀਕ ਹੁੰਦੀ ਹੈ, ਸਿਸਟਮ ਨੂੰ ਵੱਖ-ਵੱਖ ਇਤਿਹਾਸਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਪੈਂਦਾ ਹੈ।ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਇੱਕ ਲਿਖਤ "ਜਿੱਤ" ਕਰ ਸਕਦੀ ਹੈ, ਫੀਲਡ ਮੇਰਜ ਹੋ ਸਕਦੇ ਹਨ, ਜਾਂ ਸੰਘਰਸ਼ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਲਾਜ਼ਮੀ ਹੋ ਸਕਦੀ ਹੈ।
ਉਪਲਬਧਤਾ-ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਦਾ ਮਕਸਦ ਹੈ ਅਸਥਾਈ ਅਸਹਿਮਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਤਾਂ ਜੋ ਉਤਪਾਦ ਜਵਾਬ ਦਿੰਦਾ ਰਹੇ—ਫਿਰ ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਠੀਕ ਕਰਨ 'ਤੇ ਨਿਵੇਸ਼ ਕਰਦੇ ਹੋ।
ਕੋਅਰਮ ਉਹ ਅਮਲੀ "ਵੋਟਿੰਗ" ਤਰੀਕਾ ਹੈ ਜੋ ਕਈ ਨਕਲ ਕੀਤੇ ਡੇਟਾਬੇਸ ਇਕਸਾਰਤਾ ਅਤੇ ਉਪਲਬਧਤਾ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹਨ।ਇਕ ਰੀਪਲਿਕਾ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ, ਸਿਸਟਮ 'ਉਹਨਾ' ਰੀਪਲਿਕਿਆਂ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਜੋ "ਕਾਫ਼ੀ" ਹਨ।
ਤੁਸੀਂ ਅਕਸਰ ਕੋਅਰਮ ਨੂੰ ਤਿੰਨ ਨੰਬਰਾਂ ਨਾਲ ਵੇਖੋਗੇ:
ਇੱਕ ਆਮ ਨਿਯਮ-ਹਥਿਆਰ ਹੈ: ਜੇ R + W > N, ਤਾਂ ਹਰ ਪੜ੍ਹਾਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਐਸੀ ਰੀਪਲਿਕਾ ਨਾਲ ਓਵਰਲੈਪ ਕਰਦੀ ਹੈ ਜਿਸ 'ਤੇ ਆਖਰੀ ਸਫਲ ਲਿਖਤ ਹੈ—ਇਸ ਨਾਲ ਸਟੇਲ ਡੇਟਾ ਪੜ੍ਹਨ ਦੀ ਸੰਭਾਵਨਾ ਘਟਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ N=3 ਰੀਪਲਿਕਾ ਹਨ:
ਕੁਝ ਸਿਸਟਮ ਹੋਰ ਅੱਗੇ ਵਧ ਕੇ W=3 (ਸਾਰੇ ਰੀਪਲਿਕਾ) ਵਰਤਦੇ ਹਨ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਲਈ, ਪਰ ਇਹ ਕਿਸੇ ਵੀ ਰੀਪਲਿਕਾ ਦੇ ਧੀਮੇ ਜਾਂ ਡਾਊਨ ਹੋਣ 'ਤੇ ਵਧੇਰੇ ਲਿਖਤ ਨਾਕਾਮੀਆਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
ਕੋਅਰਮ ਪਾਰਟੀਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦੂਰ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਕਿ ਕੌਣ ਅੱਗੇ ਵੱਧ ਸਕਦਾ ਹੈ।ਜੇ ਨੈੱਟਵਰਕ 2–1 ਵੰਡ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਸ ਪਾਸੇ ਜਿਸ ਕੋਲ 2 ਰੀਪਲਿਕਾ ਹਨ ਉਹ R=2 ਅਤੇ W=2 ਪੂਰੇ ਕਰ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕਲੋ-ਇਕ ਰੀਪਲਿਕਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।ਇਸ ਨਾਲ ਟੱਕਰ-ਅਪਡੇਟਾਂ ਘਟਦੀਆਂ ਹਨ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੁਝ ਕਲੀਐਂਟ錯 警 ਕਿਰਿਆ ਜਾਂ ਟਾਇਮਆਊਟ ਦੇਖ ਸਕਦੇ ਹਨ।
ਕੋਅਰਮ ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਕ ਲੇਟੈਂਸੀ (ਵੱਧ ਨੋਡਾਂ ਨਾਲ ਗੱਲ ਕਰਨੀ ਪੈਂਦੀ ਹੈ), ਵਧੀਕ ਲਾਗਤ (ਨੋਡ-ਦਰਮਿਆਨੀ ਟ੍ਰੈਫਿਕ), ਅਤੇ ਨੁਕਸਾਨ-ਵਰਤਾਰਾ (ਟਾਇਮਆਊਟ ਅਣਪਹੁੰਚ/ਅਵੈਲੇਬਿਲਟੀ ਵਾਂਗ ਦਿਸ ਸਕਦੇ ਹਨ) ਲਿਆਉਂਦੇ ਹਨ।ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਇੱਕ ਤਿਉਨਬਲ ਮੱਧ-ਮਾਰਗ ਹੈ: ਤੁਸੀਂ R ਅਤੇ W ਨੂੰ ਨਵਾਂ ਪੜ੍ਹਾਈ/ਅੱਠਣਾ ਜਾਂ ਲਿਖਤ ਸਫਲਤਾ ਵੱਲ ਢਾਲ ਸਕਦੇ ਹੋ, ਜੋ ਤੁਹਾਡੇ ਲਈ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
Eventual consistency ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਰੀਪਲਿਕਾ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਸਰੂਪ ਹੋ ਸਕਦੇ ਹਨ, ਬਸ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਉਹ ਬਾਅਦ ਵਿੱਚ ਇਕੱਠੇ ਹੋ ਜਾਣ।
ਇੱਕ ਕੈਫੇ ਚੇਨ ਦੀ ਤਰ੍ਹਾਂ ਸੋਚੋ ਜੋ ਇੱਕ ਸਾਂਝਾ "sold out" ਨਿਸ਼ਾਨ ਅਪਡੇਟ ਕਰ ਰਹੀ ਹੈ।ਇੱਕ ਸਟੋਰ ਨੇ ਇਹ "sold out" ਲਿਖ ਦਿੱਤਾ, ਪਰ ਅਪਡੇਟ ਹੋਰ ਸਟੋਰੇ ਨੂੰ ਕੁਝ ਮਿੰਟ ਬਾਅਦ ਮਿਲਦੀ ਹੈ।ਇਸ ਦਰਮਿਆਨ, ਹੋਰ ਸਟੋਰ ਲਈ ਅਜੇ ਵੀ "available" ਦਿਖ ਰਿਹਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਆਖ਼ਰੀ ਇਕ ਵੇਚ ਸਕਦਾ ਹੈ।ਕੋਈ ਸਿਸਟਮ "ਟੁੱਟਿਆ" ਨਹੀਂ—ਸਿਰਫ਼ ਅਪਡੇਟ ਪਹੁੰਚ ਰਹੀਆਂ ਹਨ।
ਜਦੋਂ ਡੇਟਾ ਪھیل ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਕਲੀਐਂਟ ਇਨ੍ਹਾਂ ਵਿਹਾਰੀਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਨ:
Eventual consistency ਵਾਲੇ ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਪਿਛੋਕੜ ਰਣਨੀਤੀਆਂ ਜੋੜਦੇ ਹਨ ਤਾਂ ਜੋ ਅਸਮੰਜਸ ਦਾ ਸਮਾਂ ਘੱਟ ਹੋਵੇ:
ਜੇ ਉਪਲਬਧਤਾ ਇਕਸਾਰਤਾ 'ਤੇ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ ਅਤੇ ਪ੍ਰਤੱਖਨ-ਸਹੀ ਨਹੀਂ ਹੋਣਾ ਜ਼ਰੂਰੀ, ਤਾਂ ਇਹ ਚੰਗੀ ਫਿੱਟ ਹੈ: ਐਕਟੀਵਿਟੀ ਫੀਡ, ਵਿਊ ਕਾਊਂਟਰ, ਰਿਕਮੈਂਡੇਸ਼ਨ, ਕੈਸ਼ਡ ਪ੍ਰੋਫ਼ਾਈਲ, ਲੌਗ/ਟੈਲੀਮੇਟਰੀ, ਅਤੇ ਹੋਰ ਗੈਰ-ਆਵਸ਼ਕ ਡੇਟਾ ਜਿੱਥੇ "ਕੁਝ ਸਮੇਂ ਵਿੱਚ ਸਹੀ" ਮਨਜ਼ੂਰ ਹੈ।
ਜਦੋਂ ਡੇਟਾਬੇਸ ਵੱਖ-ਵੱਖ ਰੀਪਲਿਕਾ 'ਤੇ ਲਿਖਤਾਂ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਸੰਘਰਸ਼ ਪੈਦਾ ਹੋ ਸਕਦੇ ਹਨ: ਉਹ ਸਮਾਂ ਜਦੋਂ ਇਕੋ ਆਈਟਮ 'ਤੇ ਵੱਖ-ਵੱਖ ਅਪਡੇਟ ਇੱਕ-ਦੂਜੇ ਤੋਂ ਅਲੱਗ ਹੋ ਕੇ ਆਏ।
ਕਲਾਸਿਕ ਉਦਾਹਰਨ ਹੈ ਕਿ ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਡਿਵਾਈਸ 'ਤੇ ਆਪਣਾ ਸ਼ਿਪਿੰਗ ਪਤਾ ਬਦਲ ਰਿਹਾ ਹੋਵੇ, ਦੂਜੇ 'ਤੇ ਫੋਨ ਨੰਬਰ।ਜੇ ਹਰ ਅਪਡੇਟ ਅਲੱਗ-ਅਲੱਗ ਰੀਪਲਿਕਾ 'ਤੇ ਆਵੇ, ਤਾਂ ਸਿਸਟਮ ਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਜਦੋਂ ਰੀਪਲਿਕਾ ਮੁੜ ਮਿਲਣ, ਤਦ ਅਸਲੀ ਰਿਕਾਰਡ ਕੀ ਹੋਵੇਗਾ।
ਕਈ ਸਿਸਟਮ last-write-wins ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਜਿਸਦਾ ਟਾਈਮਸਟੈਂਪ ਨਵਾਂ ਹੁੰਦਾ ਹੈ ਉਹ ਹੋਰਾਂ ਨੂੰ ਉੱਲੇਖ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇਹ ਅਸਾਨ ਹੈ ਅਤੇ ਤੇਜ਼ ਹੈ।ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਹ ਚੁੱਪਚਾਪ ਡੇਟਾ ਖੋ ਸਕਦਾ ਹੈ।ਜੇ "ਨਵਾਂ" ਜਿੱਤਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਪੁਰਾਣੀ ਪਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਰੱਦ ਹੋ ਸਕਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਦੋ ਅਪਡੇਟ ਵੱਖ-ਵੱਖ ਫੀਲਡ ਛੇੜਦੇ ਹੋਣ।
ਇਹ ਘੜੀਆਂ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।ਮਸ਼ੀਨਾਂ ਜਾਂ ਕਲੀਐਂਟਾਂ ਦੇ ਘੜੀਆਂ ਵਿੱਚ ਫਰਕ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਗਲਤ ਅਪਡੇਟ ਜਿੱਤ ਸਕਦੀ ਹੈ।
ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਸੰਘਰਸ਼ ਸੰਭਾਲਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕਾਰਨਕ ਇਤਿਹਾਸ ਟ੍ਰੈਕ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੈ।
ਕਾਂਸੈਪਚੂਅਲ ਤੌਰ 'ਤੇ, version vectors (ਅਤੇ ਹੋਰ ਸਧਾਰਣ ਵਰਜਨ) ਹਰ ਰਿਕਾਰਡ ਨਾਲ metadata ਜੁੜਦੇ ਹਨ ਜੋ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸਦਾ ਹੈ "ਕਿਹੜੀ ਰੀਪਲਿਕਾ ਨੇ ਕਿਹੜੇ ਅਪਡੇਟ ਵੇਖੇ ਹਨ"।ਜਦੋਂ ਰੀਪਲਿਕਾ ਵਰਜਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਪਤਾ ਲਗਾ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਵਰਜਨ ਦੂਜੇ 'ਚ ਸ਼ਾਮਲ ਹੈ (ਕੋਈ ਟੱਕਰ ਨਹੀਂ) ਜਾਂ ਉਹਨਾਂ ਨੇ ਵੱਖਰਾ ਰਸਤਾ ਲਿਆ (ਟੱਕਰ ਜਿਸਦਾ ਹੱਲ ਲੋੜੀਂਦਾ ਹੈ)।
ਕਈ ਸਿਸਟਮ ਲਾਜ਼ਿਕਲ ਟਾਈਮਸਟੈਂਪ (ਜਿਵੇਂ Lamport ਘੜੀਆਂ) ਜਾਂ hybrid logical clocks ਵਰਤਦੇ ਹਨ ਤਾਂ ਕਿ ਵਾਲ-ਕਲਾਕ 'ਤੇ ਨਿਰਭਰਤਾ ਘੱਟ ਹੋ ਜਾਵੇ ਪਰ ਫਿਰ ਵੀ ਅਨੁਕ੍ਰਮ ਲਈ ਇੱਕ ਇਸ਼ਾਰਾ ਮਿਲੇ।
ਜਦੋਂ ਇਕ ਟੱਕਰ ਪਛਾਣ ਲਈ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਚੋਣਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਸਭ ਤੋਂ ਵਧੀਆ ਰਣਨੀਤੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡੇ ਡੇਟਾ ਲਈ "ਸਹੀ" ਕੀ ਹੈ—ਕਦੇ-ਕਦੇ ਇੱਕ ਲਿਖਤ ਖੋ ਜਾਣਾ ਮਨਜ਼ੂਰ ਹੈ, ਤੇ ਕਦੇ-ਕਦੇ ਇਹ ਕਾਰੋਬਾਰੀ ਤੌਰ 'ਤੇ ਗਲਤ ਹੈ।
ਇਕਸਾਰਤਾ/ਉਪਲਬਧਤਾ ਰੁਖ ਦਾਰਸ਼ਨਿਕ ਚਰਚਾ ਨਹੀਂ—ਇਹ ਇੱਕ ਪ੍ਰੋਡਕਟ ਫੈਸਲਾ ਹੈ।ਸ਼ੁਰੂ ਕਰੋ ਇਸ ਸਵਾਲ ਨਾਲ: ਛੇਤੀ ਲਈ ਗਲਤ ਹੋਣ ਦੀ ਕੀ ਕੀਮਤ ਹੈ, ਅਤੇ "ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ" ਕਹਿਣ ਦੀ ਕੀ ਕੀਮਤ ਹੈ?
ਕੁਝ ਖੇਤਰ ਲਿਖਤ ਸਮੇਂ ਇੱਕ ਇੱਕ-ਅਧਿਕਾਰਤ ਜਵਾਬ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ ਕਿਉਂਕਿ "ਲਗਭਗ ਸਹੀ" ਵੀ ਗਲਤ ਹੈ:
ਜੇ ਅਸਥਾਈ ਗਲਤ ਇਕ ਘੱਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ/ਉਲਟ-ਹੋ ਸਕਦੀ ਚੀਜ਼ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ ਉਪਲਬਧਤਾ ਅਪਣਾ ਸਕਦੇ ਹੋ।
ਕਈ ਯੂਜ਼ਰ ਅਨੁਭਵ ਥੋੜ੍ਹਾ ਪੁਰਾਣਾ ਡੇਟਾ ਚੱਲਦਾ ਹੈ:
ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕਿੰਨੀ ਦੇਰ ਠੀਕ ਹੈ: ਸਕਿੰਟ, ਮਿੰਟ, ਜਾਂ ਘੰਟੇ।ਉਹ ਸਮਾਂ-ਬਜਟ ਤੁਹਾਡੀਆਂ ਰਿਪਲਿਕੇਸ਼ਨ ਅਤੇ ਕੋਅਰਮ ਚੋਣਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੇਗਾ।
ਜਦੋਂ ਰੀਪਲਿਕਾ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ UX ਨਤੀਜੇ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣਦੇ ਹੋ:
ਸਥਿਤੀ-ਵਿਸ਼ੇਸ਼ ਫੀਚਰ ਅਨੁਸਾਰ ਘੱਟ ਨੁਕਸਾਨ ਵਾਲਾ ਵਿਕਲਪ ਚੁਣੋ—ਪੂਰੇ ਸਿਸਟਮ ਲਈ ਨਹੀਂ।
Lean C (Consistency) ਜਦੋਂ: ਗਲਤ ਨਤੀਜੇ ਆਰਥਿਕ/ਕਾਨੂੰਨੀ ਖ਼ਤਰਾ ਬਣ ਜਾਂਦੇ ਹਨ, ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਜਾਂ ਪੂਰਨ ਹੁਟ-ਕਾਰਵਾਈਆਂ ਹੋ ਰਹੀਆਂ ਹਨ।
Lean A (Availability) ਜਦੋਂ: ਯੂਜ਼ਰ ਪ੍ਰਤਿਕ੍ਰਿਆ ਨੂੰ ਮਹੱਤਵ ਹੈ, ਸਟੇਲ ਡੇਟਾ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਟੱਕਰ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੁਧਾਰੇ ਜਾ ਸਕਦੇ ਹਨ।
ਸੰਦੇਹ ਵਿਚ, ਸਿਸਟਮ ਨੂੰ ਵਿਭਾਜਿਤ ਕਰੋ: ਮਹੱਤਵਪੂਰਨ ਰਿਕਾਰਡਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਦਿਓ, ਅਤੇ ਨਿਕਾਸੀ ਦ੍ਰਿਸ਼ (ਫੀਡ, ਕੈਸ਼, ਐਨਾਲਿਟਿਕਸ) ਲਈ ਉਪਲਬਧਤਾ-ਅਨੁਕੂਲ ਢਾਂਚੇ ਰੱਖੋ।
ਤੁਹਾਨੂੰ ਕਦੇ ਵੀ ਪੂਰੇ ਸਿਸਟਮ ਲਈ ਇਕ ਹੀ "ਇਕਸਾਰਤਾ ਸੈਟਿੰਗ" ਚੁਣਨੀ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੁੰਦੀ।ਕਈ ਆਧੁਨਿਕ ਵੰਡੇ ਡੇਟਾਬੇਸ ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਓਪਰੇਸ਼ਨ ਇਕਸਾਰਤਾ ਚੁਣਨ ਦਿੰਦੇ ਹਨ—ਅਤੇ ਸਮਾਰਟ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਅਨੁਭਵ ਸਥਿਰ ਰਹੇ ਬਿਨਾਂ ਇਹ ਝੂਠਾ ਦਿਖਾਉਣ ਦੇ ਕਿ ਟਰੇਡ-ਆਫ ਮੌਜੂਦ ਨਹੀਂ।
ਇਕਸਾਰਤਾ ਨੂੰ ਇੱਕ ਡਾਇਲ ਵਾਂਗ ਸਮਝੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਉਹ ਅਨੁਭਵ ਦੇਖ ਕੇ ਘੁਮਾਉਂਦੇ ਹੋ ਜਿਸ ਤੇ ਯੂਜ਼ਰ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ:
ਇਸ ਨਾਲ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਦੀ ਕੀਮਤ ਨਹੀਂ ਚੁਕਾਉਣੀ ਪੈਂਦੀ, ਪਰ ਉਹ ਓਪਰੇਸ਼ਨ ਜਿਹੜੇ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦੇ ਹਨ ਉਹ ਸੰਰਖਿਤ ਰਹਿੰਦੇ ਹਨ।
ਆਮ ਨਮੂਨਾ ਹੈ ਲਿਖਤ ਲਈ ਮਜ਼ਬੂਤ, ਪੜ੍ਹਾਈ ਲਈ ਕਮਜ਼ੋਰ:
ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਲਟ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੇਜ਼ ਲਿਖਤ (ਕਤਾਰ/ਅੰਤਿਮ) ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਮਜ਼ਬੂਤ ਪੜ੍ਹਾਈ ("ਕੀ ਮੇਰਾ ਆਰਡਰ ਰੱਖਿਆ ਗਿਆ?")।
ਜਦੋਂ ਨੈੱਟਵਰਕ ਹਿਲਦਾ-ਡੁੱਲਦਾ ਹੈ, ਕਲੀਐਂਟ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।ਰੀਟ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਅਤ ਬਣਾਓ idempotency keys ਨਾਲ ਤਾਂ ਜੋ "ਆਰਡਰ ਭੇਜੋ" ਦੋ ਵਾਰੀ ਚਲਣ 'ਤੇ ਦੋ ਆਰਡਰ ਨਾ ਬਣ ਜਾਣ।ਪਹਿਲਾ ਨਤੀਜਾ ਸਟੋਰ ਕਰੋ ਅਤੇ ਜੇ ਇੱਕੋ key ਫਿਰ ਮਿਲੇ ਤਾਂ ਉਸੇ ਨਤੀਜੇ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਸੇਵਾ-ਪਾਰ ਕੀਤੀਆਂ ਮੁੱਲਾਂ ਲਈ, saga ਵਰਤੋ: ਹਰ ਕਦਮ ਦਾ ਇੱਕ compensating action ਹੋਵੇ (ਰਿਫੰਡ, ਰਿਕਵਰ, ਸ਼ਿਪਮੈਂਟ ਰੱਦ)।ਇਸ ਨਾਲ ਸਿਸਟਮ ਕਾਬਿਲ-ਇਸਤੇਮਾਲ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ ਜੇ ਕੁਝ ਹਿੱਸੇ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਸਹਿਮਤ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਟਰੇਡ-ਆਫ ਨੂੰ ਮੈਨੇਜ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜੇ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦੇ।ਪ੍ਰੋਡਕਸ਼ਨ ਮੁੱਦੇ ਅਕਸਰ "ਯਾਦਰਹੀ ਗਲਤੀਆਂ" ਵਰਗੇ ਦਿਸਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਹੀ ਮੈਟਰਿਕਸ ਅਤੇ ਟੈਸਟ ਨਹੀਂ ਜੋੜਦੇ।
ਛੋਟੀ ਮੈਟਰਿਕ ਵਿਵਸਥਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਿੱਧਾ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਨਾਲ ਜੁੜੇ ਹੋਣ:
ਜੇ ਹੋ ਸਕੇ ਤਾਂ, ਮੈਟ੍ਰਿਕਸ ਨੂੰ Consistency mode (quorum ਬਨਾਮ ਸਥਾਨਕ) ਅਤੇ ਰੀਜਨ/ਜ਼ੋਨ ਨਾਲ ਟੈਗ ਕਰੋ ਤਾਂ ਜੋ ਜਿੱਥੇ ਵਿਹਾਰ ਵਿੱਚ ਫਰਕ ਹੈ ਉਹ ਦਿਸੇ।
ਅਸਲ ਆਊਟੇਜ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ।ਸਟੇਜਿੰਗ ਵਿੱਚ ਓਹਨਾਂ ਕਾਉਸ ਐਕਸਪੈਰੀਮੈਂਟ ਚਲਾਓ ਜੋ ਇਹਨਾਂ ਨੂੰ ਨਕਲ ਕਰਦੇ ਹਨ:
ਸਿਰਫ਼ ਇਹ ਨਾਂ ਦੇਖੋ ਕਿ "ਸਿਸਟਮ ਉੱਪ ਹੈ"—ਪਰ ਦੇਖੋ ਕਿ ਕਿਹੜੀ ਗਾਰੰਟੀ ਰੱਖੀ ਜਾਂਦੀ ਹੈ: ਕੀ ਪੜ੍ਹਾਈ ਤਾਜ਼ਾ ਰਹਿੰਦੀ ਹੈ, ਕੀ ਲਿਖਤ ਰੋਕੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਕੀ ਕਲੀਐਂਟਾਂ ਨੂੰ ਸਪਸ਼ਟ ਐਰਰ ਮਿਲਦੇ ਹਨ?
ਨਿਲਖੇ ਐਲਰਟ ਸ਼ਾਮਲ ਕਰੋ:
ਅਖੀਰ 'ਤੇ, ਗਾਰੰਟੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ: ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਸਿਸਟਮ ਨਾਰਮਲ ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ ਅਤੇ ਪਾਰਟੀਸ਼ਨ ਦੌਰਾਨ ਕਿਹੜੀਆਂ ਵਿਰਦੇਸ਼ਾਂ ਦਾ ਵਾਅਦਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਅਤੇ ਸਹਾਇਤਾ ਟੀਮਾਂ ਨੂੰ ਸਿਖਾਓ ਕਿ ਯੂਜ਼ਰ ਕੀ ਵੇਖ ਸਕਦੇ ਹਨ ਅਤੇ ਉਹ ਕਿਵੇਂ ਜਵਾਬ ਦਿਉਂ।
ਜੇ ਤੁਸੀਂ ਨਵੇਂ ਉਤਪਾਦ ਵਿੱਚ ਇਹ ਟਰੇਡ-ਆਫ ਅਨੁਸੂਚਿਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਫੈਸਲੇ ਦੀ ਪੜਚੋਲ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਜਲਦੀ ਸਚ ਕਰਨਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਫੇਲ ਮੋਡ, ਰੀਟ੍ਰਾਈ ਵਰਤਾਰਾ, ਅਤੇ UI ਵਿੱਚ "ਸਟੇਲ" ਕਿਵੇਂ ਦਿਸਦਾ ਹੈ।
ਇੱਕ ਕਾਨੂੰਨੀ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਵਰਕਫਲੋ (ਲਿਖਤ ਪਾਥ, ਪੜ੍ਹਤ ਪਾਥ, ਰੀਟ੍ਰਾਈ/ਇਡੈਂਟਿਪੋਟਿੰਸੀ, ਅਤੇ ਇੱਕ ਰੀਕਨਸਾਈਲੇਸ਼ਨ ਜੌਬ) ਦਾ ਇੱਕ ਛੋਟਾ ਵਰਜਨ ਪ੍ਰੋਟੋਟਾਈਪ ਕੀਤਾ ਜਾਵੇ ਜ਼ਿਸ ਨਾਲ ਤੁਸੀਂ ਪੂਰੀ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਿਹਾਰ ਵੇਖ ਸਕੋ।Koder.ai ਨਾਲ, ਟੀਮਾਂ ਇੱਕ ਚੈਟ-ਡ੍ਰਾਈਵਨ ਵਰਕਫਲੋ ਰਾਹੀਂ ਵੈੱਬ ਐਪ ਅਤੇ ਬੈਕਐਂਡ ਤੇਜ਼ੀ ਨਾਲ ਘੁਮਾ ਸਕਦੀਆਂ ਹਨ, ਡੇਟਾ ਮਾਡਲ ਅਤੇ APIs 'ਤੇ ਦੁਹਰਾਅ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਇਕਸਾਰਤਾ ਪੈਟਰਨ (ਉਦਾਹਰਨ ਲਈ, ਕਠੋਰ ਲਿਖਤ + ਢਿੱਲੇ ਪੜ੍ਹਾਈ) ਨੂੰ ਬਿਨਾਂ ਪਰੰਪਰਾਗਤ ਬਿਲਡ ਪਾਈਪਲਾਈਨ ਦੇ ਤਗੜੇ ਓਵਰਹੈੱਡ ਦੇ ਆਜ਼ਮਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।ਜਦੋਂ ਪ੍ਰੋਟੋਟਾਈਪ ਚਾਹੀਦਾ ਵਰਤਾਰਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਤੁਸੀਂ ਸੋర్స్ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਕੇ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵੱਲ ਵਿਕਸਿਤ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਰੀਪਲਿਕੇਟ ਕੀਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ, "ਇੱਕੋ" ਡੇਟਾ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਲਵਚੀਲਤਾ ਅਤੇ ਘਟੀਆ ਲੇਟੈਂਸੀ ਘਟਦੀ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ: ਨੋਡ ਸਲੇਓ ਹੋ ਸਕਦੇ ਹਨ, ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਜਾਂ ਨੈੱਟਵਰਕ ਨਾਲ ਵੰਡੇ ਜਾ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਹਮੇਸ਼ਾਂ ਤੁਰੰਤ ਆਖਰੀ ਲਿਖਤ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਰਹਿੰਦੇ।
ਇਕਸਾਰਤਾ ਦਾ ਅਰਥ ਹੈ: ਇੱਕ ਸਫਲ ਲਿਖਤ ਤੋਂ ਬਾਅਦ, ਕੋਈ ਵੀ ਬਾਅਦੀ ਪੜ੍ਹਾਈ ਉਸੇ ਹੀ ਮੁੱਲ ਨੂੰ ਵਾਪਸ ਕਰਦੀ ਹੈ—ਭਾਵੇਂ ਕਿਹੜਾ ਵੀ ਰੀਪਲਿਕਾ ਸਰਵ ਕਰ ਰਿਹਾ ਹੋਵੇ।ਅਮਲੀ ਰੂਪ ਵਿੱਚ, ਪ੍ਰਬੰਧ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕੁਝ ਪੜ੍ਹਾਈ/ਲਿਖਤਾਂ ਨੂੰ ਰੋਕ ਜਾਂ ਰੱਦ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਕਾਫ਼ੀ ਰੀਪਲਿਕਾ (ਜਾਂ ਆਗੂ) ਅਪਡੇਟ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦੇ।
ਉਪਲਬਧਤਾ ਦਾ ਮਤਲਬ ਹੈ: ਜਦੋਂ ਕੁਝ ਨੋਡ ਡਾਊਨ ਹੋਣ ਜਾਂ ਗੱਲਬਾਤ ਨਾ ਕਰ ਸਕਣ, ਸਿਸਟਮ ਹਰ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਨਾਨ-ਏਰਰ ਜਵਾਬ ਦੇਂਦਾ ਹੈ।ਉਹ ਜਵਾਬ ਪੁਰਾਣਾ, ਅਧੂਰਾ ਜਾਂ ਸਥਾਨਕ ਜਾਣਕਾਰੀ 'ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਸਟਮ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।
ਨੈੱਟਵਰਕ ਪਾਰਟੀਸ਼ਨ ਉਹ ਹੈ ਜਦੋਂ ਉਹ ਨੋਡ ਜੋ ਇੱਕੋ ਸਿਸਟਮ ਵਾਂਗ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਦਰਮਿਆਨ ਸੰਚਾਰ ਟੁੱਟ ਜਾਂ ਵਿਸ਼ਵਾਸਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ।ਨੋਡ ਹਜੇ ਵੀ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਸੁਨੇਹੇ ਸਹੀ ਤਰ੍ਹਾਂ ਸਪਲਾਈ ਨਹੀਂ ਹੋ ਰਹੇ—ਇਸ ਨਾਲ ਡੇਟਾਬੇਸ ਨੂੰ ਚੋਣ ਕਰਨੀ ਪੈਂਦੀ ਹੈ:
ਪਾਰਟੀਸ਼ਨ ਦੌਰਾਨ ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ ਅਪਡੇਟ ਆ ਸਕਦੇ ਹਨ ਜੋ ਇਕ ਦੂਜੇ ਨਾਲ ਤੁਰੰਤ ਸਾਂਝੇ ਨਹੀਂ ਹੁੰਦੇ।ਇਸ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ:
ਇਹ ਉਹ ਸਪਸ਼ਟ ਲਕੜ ਹਨ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਰੀਪਲਿਕਾ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਕੋਆਰਡੀਨੇਟ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ।
ਇਹ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਮੇਸ਼ਾਂ ਤਿੰਨ ਵਿੱਚੋਂ ਦੋ ਚੁਣੋ।ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਜਦੋਂ ਪਾਰਟੀਸ਼ਨ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਦੋਹਾਂ ਨੂੰ ਯਕੀਨੀ ਨਹੀਂ ਬਣਾ ਸਕਦੇ:
ਪਾਰਟੀਸ਼ਨ ਤੋਂ ਬਾਹਰ, ਬਹੁਤ ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਦੋਹਾਂ ਦੇ ਨੇੜੇ ਹੋ ਸਕਦੇ ਹਨ—ਪਰ ਜਦੋਂ ਨੈੱਟਵਰਕ ਗੜਬੜ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸੀਮਾਵਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।
Quorum ਰੀਪਲਿਕੇਟਡ ਡੇਟਾਬੇਸਾਂ ਵਿੱਚ ਇੱਕ ਅਮਲੀ “ਵੋਟਿੰਗ” ਤਕਨਿਕ ਹੈ ਜੋ ਇਕਸਾਰਤਾ ਅਤੇ ਉਪਲਬਧਤਾ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਂਦੀ ਹੈ:
ਸਧਾਰਨ ਨਿਯਮ: ਹੋਵੇ ਤਾਂ ਹਰ ਪੜ੍ਹਾਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਐਸੀ ਰੀਪਲਿਕਾ ਨੂੰ ਛੂਹਦੀ ਹੈ ਜਿਸ 'ਤੇ ਆਖਰੀ ਸਫਲ ਲਿਖਤ ਹੈ—ਇਸ ਨਾਲ ਸਟੇਲ ਰੀਡ ਘਟਦੇ ਹਨ।Quorum ਪਾਰਟੀਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਕਿ ਕੌਣ ਅਗੇ ਵੱਧ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਉਹ ਪਾਸਾ ਜਿਸ ਕੋਲ ਬਹੁਮਤ ਹੈ)।
Eventual consistency ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਰੀਪਲਿਕਾ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਸਮੰਮਤ ਹੋ ਸਕਦੇ ਹਨ, ਜਦ ਤੱਕ ਉਹ ਬਾਅਦ ਵਿੱਚ ਇੱਕੋ ਮੁੱਲ 'ਤੇ ਮਿਲ ਨਹੀਂ ਜਾਂਦੇ।ਆਮ ਅਸਥਿਰਤਾਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਇਨ੍ਹਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਆਮ ਤਕਨੀਕਾਂ: , , ਅਤੇ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਚੱਲਣ ਵਾਲੀ ਸਿੰਕ।
ਜਦੋਂ ਵੱਖ-ਵੱਖ ਰੀਪਲਿਕਾ ਅਲੱਗ-ਅਲੱਗ ਲਿਖਤਾਂ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹਨ, ਪਾਰਟੀਸ਼ਨ ਠੀਕ ਹੋਣ 'ਤੇ ਸੰਘਰਸ਼ ਪੈਦਾ ਹੋ ਸਕਦੇ ਹਨ।ਇਹਾਂ ਕੁਝ ਹੱਲ ਹਨ:
ਤੁਹਾਡੇ ਡੇਟਾ ਲਈ “ਸਹੀ” ਕੀ ਹੈ, ਇਸ ਦੇ ਆਧਾਰ 'ਤੇ ਰਣਨੀਤੀ ਚੁਣੋ।
ਇਕਸਾਰਤਾ/ਉਪਲਬਧਤਾ ਰਵੈਏ ਦਾ ਚੁਣਾਅ ਦਰਅਸਲ ਇੱਕ ਪ੍ਰੋਡਕਟ ਫੈਸਲਾ ਹੈ।ਸ਼ੁਰੂਆਤ ਇਸ ਸਵਾਲ ਨਾਲ ਕਰੋ: ਇਕ ਲੰਬੇ ਸਮੇਂ ਲਈ ਗਲਤ ਹੋ ਜਾਣੇ ਦੀ ਕੀ ਕੀਮਤ ਹੈ, ਅਤੇ "ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ" ਕਹਿਣ ਦੀ ਕੀ ਕੀਮਤ ਹੈ?
ਬਹੁਤ ਵਾਰੀ, ਹਲ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਜ਼ਰੂਰੀ ਰਿਕਾਰਡਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਦੇਓ, ਅਤੇ ਨਿਰਪੱਖ/ਪ੍ਰਦਰਸ਼ਨ-ਉਪਲਬਧ ਦ੍ਰਿਸ਼ਾਂ (ਫੀਡ, ਕੈਸ਼, ਐਨਾਲਿਟਿਕਸ) ਲਈ ਉਪਲਬਧਤਾ ਨੂੰ ਅਪਣਾਇਆ ਜਾਵੇ।