NoSQL ਵਿੱਚ ਡੇਟਾ, ਸਥਿਰਤਾ ਅਤੇ ਵਿਸ਼ਵਾਸ ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ ਕੈਸੈਂਡਰਾ ਦੀਆਂ ਅੱਖਾਂ ਵਿੱਚ ਕਿਵੇਂ ਵੇਖਣਾ ਹੈ

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

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

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

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

ਇਸ ਲਈ, ਇਹ ਉਹ ਹੈ ਜੋ ਸਾਨੂੰ ਅਨੁਭਵ ਦਿੰਦਾ ਹੈ

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

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

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

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

ਸਾਨੂੰ ਟੈਸਟ ਜ਼ੋਨਾਂ ਵਿੱਚ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਆਈ (ਪ੍ਰੋਮ ਵਿੱਚ 5 ਦੇ ਮੁਕਾਬਲੇ ਟੈਸਟ ਵਿੱਚ 20 ਨੋਡਸ)। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਡੰਪ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ.

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

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

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

ਅਸੀਂ ਕਿਵੇਂ ਫੈਸਲਾ ਕੀਤਾ

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

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

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

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

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

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

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

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

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਹੁਣ ਲਈ EACH_QUORUM ਲਿਖਣ ਲਈ ਇਕਸਾਰਤਾ ਪੱਧਰ 'ਤੇ ਰੋਕਿਆ ਗਿਆ, ਪੜ੍ਹਨ ਲਈ - LOCAL_QUORUM

ਸੰਖੇਪ ਪ੍ਰਭਾਵ ਅਤੇ ਸਿੱਟੇ

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

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

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

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

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

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

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

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

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

ਬੁਰਾ ਨਹੀਂ TTL ਨੂੰ ਅਟੈਚ ਕਰਨ ਅਤੇ ਪੁਰਾਣੇ ਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਲਈ ਤੁਰੰਤ ਪ੍ਰਦਾਨ ਕਰੋ।

Cassandra ਤੋਂ ਡਾਟਾ ਡਾਊਨਲੋਡ ਕਰਨ ਵੇਲੇ ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ ਨੂੰ FETCH ਸਿਧਾਂਤ 'ਤੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਨਾ ਹੋਣ, ਪਰ ਬੈਚਾਂ ਵਿੱਚ ਚੁਣੀਆਂ ਜਾਣ।

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

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

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

ਸਰੋਤ: www.habr.com