Elasticsearch ਡਾਟਾ ਟਿਕਾਊ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਮੁੱਖ ਡਾਟਾਬੇਸ ਬਣਾਉਣ ਲਈ ਪੁੱਛੋ ਕਿ ਲਿਖਤ ਫੇਲ੍ਹ ਹੋਣ ਜਾਂ ਇਕੱਠੀਆਂ ਲਿਖਤਾਂ ਚੱਲਣ ਵੇਲੇ ਕਿਹੜੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਸਹੀ ਰਹਿਣੇ ਲਾਜ਼ਮੀ ਹਨ।
ਆਰਡਰ ਸਿਸਟਮ ਵਿੱਚ ਉਤਪਾਦ ਲੱਭਣਾ ਅਤੇ ਖਰੀਦ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਵੱਖਰੇ ਕੰਮ ਹਨ। ਪਹਿਲੇ ਲਈ ਖੋਜ ਦੀ ਸਾਰਥਕਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ; ਦੂਜੇ ਲਈ ਸਹੀ ਭੁਗਤਾਨ ਅਤੇ ਸਟਾਕ ਬਦਲਾਅ।
ਮੰਨੋ ਖਰੀਦ ਲਈ ਆਰਡਰ ਰਿਕਾਰਡ ਅਤੇ ਸਟਾਕ ਘਟਾਉਣਾ ਲੋੜੀਂਦੇ ਹਨ। ਕਾਰੋਬਾਰ ਨੂੰ ਤੈਅ ਕਰਨਾ ਪਵੇਗਾ ਕਿ ਜੇ ਇੱਕੋ ਕੰਮ ਸਫਲ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
[Create order] ---- must coordinate ---- [Reduce stock]
| |
success failure?
Elasticsearch ਦਾ bulk API ਕਈ ਡਾਕੂਮੈਂਟ ਕਾਰਵਾਈਆਂ ਇਕੱਠੀਆਂ ਭੇਜਦਾ ਹੈ, ਪਰ ਇੱਕ ਫੇਲ੍ਹ ਅਤੇ ਦੂਜੀ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਸਭ ਕੁਝ ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ ਵਾਲੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਹਰ ਨਤੀਜਾ ਜਾਂਚਣਾ ਪੈਂਦਾ ਹੈ। Bulk API।
ਜੇ ਕਈ ਰਿਕਾਰਡਾਂ ਉੱਤੇ ਐਟਾਮਿਕ ਬਦਲਾਅ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਾਲਾ ਡਾਟਾਬੇਸ ਆਮ ਤੌਰ ਉੱਤੇ ਸਿੱਧਾ ਆਧਾਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਤਾਲਮੇਲ ਖੁਦ ਬਣਾਉਣ ਨਾਲ ਹੋਰ ਫੇਲ੍ਹ ਹਾਲਤਾਂ ਅਤੇ ਬਹਾਲੀ ਦਾ ਕੰਮ ਵਧਦਾ ਹੈ।
Optimistic concurrency control ਜਾਂਚਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਪੜ੍ਹੇ ਵਰਜ਼ਨ ਤੋਂ ਬਾਅਦ ਡਾਕੂਮੈਂਟ ਬਦਲਿਆ ਨਹੀਂ। ਇਹ ਪੁਰਾਣੇ ਆਧਾਰ ਉੱਤੇ ਅਪਡੇਟ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਜੋ ਇੱਕ ਕਲਾਇੰਟ ਦੂਜੇ ਦਾ ਕੰਮ ਚੁੱਪਚਾਪ ਨਾ ਮਿਟਾਏ। Concurrency control।
ਇਹ ਸੁਰੱਖਿਆ ਅਪਡੇਟ ਹੋ ਰਹੇ ਡਾਕੂਮੈਂਟ ਲਈ ਹੈ। ਇਹ ਸਟਾਕ ਅਤੇ ਆਰਡਰ ਡਾਕੂਮੈਂਟ ਆਪਣੇ ਆਪ ਨਹੀਂ ਜੋੜਦੀ, ਰਿਲੇਸ਼ਨਲ foreign key ਨਹੀਂ ਦਿੰਦੀ ਅਤੇ ਕਾਰੋਬਾਰੀ ਫੀਲਡਾਂ ਵਿੱਚ ਮਨਚਾਹੇ ਵਿਲੱਖਣਤਾ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਕਰਦੀ।
ਸਟੋਰੇਜ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਲੋੜੀਂਦੇ ਨਿਯਮ ਲਿਖੋ। ਇਸ ਨਾਲ “ਸਰਚ ਇੰਜਣ” ਜਾਂ “ਡਾਟਾਬੇਸ” ਦੇ ਲੇਬਲ ਦੀ ਥਾਂ ਫ਼ੈਸਲਾ ਠੋਸ ਬਣਦਾ ਹੈ।
ਸਫਲ ਲਿਖਤ ਅਤੇ ਖੋਜ ਵਿੱਚ ਦਿਖਦਾ ਨਤੀਜਾ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਹਨ:
[Write accepted] -> [Refresh] -> [Search can see the change]
Refresh ਨਵੇਂ ਬਦਲਾਅ ਖੋਜ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਸ ਲਈ ਡਾਕੂਮੈਂਟ ID ਨਾਲ ਰੀਅਲ-ਟਾਈਮ ਪੜ੍ਹਨਾ ਸਰਚ ਕੁਏਰੀ ਤੋਂ ਵੱਖਰਾ ਹੈ। refresh=wait_for ਖੋਜ ਵਿੱਚ ਦਿਖਣ ਤੱਕ ਉਡੀਕ ਸਕਦਾ ਹੈ, ਪਰ ਕਈ ਡਾਕੂਮੈਂਟਾਂ ਦੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਨਹੀਂ ਬਣਾਉਂਦਾ। Refresh ਵਿਹਾਰ।
ਉਤਪਾਦ ਖੋਜ ਪੰਨੇ ਲਈ ਥੋੜ੍ਹੀ ਦੇਰੀ ਮੰਨਣਯੋਗ ਹੋ ਸਕਦੀ ਹੈ। ਅੰਤਿਮ ਭੁਗਤਾਨ ਜਾਂ ਇਜਾਜ਼ਤ ਦੇ ਫ਼ੈਸਲੇ ਲਈ ਲੋੜੀਂਦੀ ਇਕਸਾਰਤਾ ਸਪਸ਼ਟ ਕਰੋ ਅਤੇ ਉਹ ਦੇਣ ਵਾਲਾ ਸਰੋਤ ਪੜ੍ਹੋ। Refresh ਅਤੇ ਟਿਕਾਊ ਸਟੋਰੇਜ ਵੀ ਵੱਖਰੇ ਮਸਲੇ ਹਨ।
| ਲੋੜ | ਪਰਖਣ ਵਾਲੀ ਦਿਸ਼ਾ | ਕਾਰਨ |
|---|---|---|
| ਆਰਡਰ ਅਤੇ ਸੰਬੰਧਿਤ ਰਿਕਾਰਡ ਐਟਾਮਿਕ ਬਦਲਣੇ ਹਨ | ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਾਲਾ ਮੁੱਖ ਡਾਟਾਬੇਸ | ਸਹੀਪਣ ਦੇ ਨਿਯਮ ਅਧਿਕਾਰਤ ਰਿਕਾਰਡਾਂ ਨੇੜੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। |
| ਲਚਕੀਲੀ ਪੂਰੇ ਪਾਠ ਦੀ ਖੋਜ ਚਾਹੀਦੀ ਹੈ | ਖੋਜ ਕਾਪੀ ਵਜੋਂ Elasticsearch | ਖੋਜ ਡਾਟਾ ਸੁਤੰਤਰ ਬਣਾਇਆ ਅਤੇ ਮੁੜ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। |
| ਮਿਲਦੀਆਂ ਇਕਸਾਰਤਾ ਲੋੜਾਂ ਵਾਲੇ ਸੁਤੰਤਰ ਡਾਕੂਮੈਂਟ | ਮੁੱਖ ਸਟੋਰ ਵਜੋਂ Elasticsearch ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ | ਦੂਜੇ ਡਾਟਾਬੇਸ ਦਾ ਸਾਬਤ ਮਕਸਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। |
ਆਰਡਰ ਸਿਸਟਮ ਦਾ ਆਮ ਡਿਜ਼ਾਈਨ ਇਹ ਹੈ:
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
authoritative data search copy
CDC ਕਮਿਟ ਹੋਏ ਬਦਲਾਅ ਫੜਦਾ ਹੈ; outbox ਕਾਰੋਬਾਰੀ ਅਪਡੇਟ ਨਾਲ ਇੱਕੋ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਘਟਨਾ ਰੱਖਦਾ ਹੈ। ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਇਹ ਬਦਲਾਅ ਇੰਡੈਕਸ ਤੱਕ ਪਹੁੰਚਾਉਂਦੀ ਹੈ। ਇਸ ਨਾਲ ਦੋ ਅਸੰਬੰਧਿਤ ਐਪਲੀਕੇਸ਼ਨ ਲਿਖਤਾਂ ਹਮੇਸ਼ਾ ਇਕੱਠੀਆਂ ਸਫਲ ਹੋਣ ਉੱਤੇ ਨਿਰਭਰਤਾ ਹਟਦੀ ਹੈ।
ਇੰਡੈਕਸਿੰਗ ਰਸਤੇ ਨੂੰ ਅਜੇ ਵੀ ਸਥਿਰ ID, ਵਰਜ਼ਨ ਸੰਭਾਲ, ਮਿਟਾਉਣਾ, ਮੁੜ ਕੋਸ਼ਿਸ਼ ਅਤੇ ਦੇਰੀ ਦੀ ਨਿਗਰਾਨੀ ਚਾਹੀਦੀ ਹੈ। ਸਰੋਤ ਤੋਂ ਇੰਡੈਕਸ ਮੁੜ ਬਣਾਉਣਾ ਟੈਸਟ ਕਰੋ। ਨਹੀਂ ਤਾਂ ਖੋਜ ਕਾਪੀ ਦੂਜਾ, ਅਸੰਗਤ ਸੱਚ ਦਾ ਸਰੋਤ ਬਣ ਸਕਦੀ ਹੈ।
ਕੋਈ ਵੀ ਭੂਮਿਕਾ ਚੁਣੋ, ਬੈਕਅੱਪ ਯੋਜਨਾ ਅਤੇ ਬਹਾਲੀ ਟੈਸਟ ਕਰੋ। ਰੈਪਲਿਕਾ ਉਪਲਬਧਤਾ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਪਰ ਬੈਕਅੱਪ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੇ। ਅਸਲ ਸੰਰਚਨਾ ਲਈ ਮੰਨਣਯੋਗ ਡਾਟਾ ਨੁਕਸਾਨ ਅਤੇ ਬਹਾਲੀ ਸਮਾਂ ਤੈਅ ਕਰੋ।
ਆਰਡਰ ਦੀ ਉਦਾਹਰਨ ਵਿੱਚ ਮੈਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਰਿਕਾਰਡ ਉਨ੍ਹਾਂ ਦੇ ਨਿਯਮਾਂ ਨੂੰ ਸਹਾਰਾ ਦੇਣ ਵਾਲੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਰੱਖਾਂਗਾ ਅਤੇ ਖੋਜ ਲੋੜਾਂ ਜਾਇਜ਼ ਹੋਣ ਤਾਂ Elasticsearch ਜੋੜਾਂਗਾ। ਸੁਤੰਤਰ ਖੋਜ-ਕੇਂਦਰਿਤ ਡਾਕੂਮੈਂਟਾਂ ਲਈ ਪਰਖਾਂਗਾ ਕਿ Elasticsearch ਇਕੱਲਾ ਸਟੋਰੇਜ, ਇਕਸਾਰਤਾ ਅਤੇ ਬਹਾਲੀ ਦੀ ਲੋੜ ਪੂਰੀ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਯਾਦ ਰੱਖੋ: ਕੰਮ ਦੀਆਂ ਲੋੜੀਂਦੀਆਂ ਗਾਰੰਟੀਆਂ ਅਨੁਸਾਰ ਚੁਣੋ, ਫਿਰ ਫੇਲ੍ਹ ਅਤੇ ਬਹਾਲੀ ਵਿਹਾਰ ਜਾਂਚੋ। ਖੋਜ ਦੀ ਰਫ਼ਤਾਰ ਇਸ ਫ਼ੈਸਲੇ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੀ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ