PostgreSQL ਐਂਟੀਪੈਟਰਨ: "ਮਰੇ" ਦੀ ਭੀੜ ਨਾਲ ਲੜਨਾ

PostgreSQL ਦੇ ਅੰਦਰੂਨੀ ਮਕੈਨਿਜ਼ਮ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਸ ਨੂੰ ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ ਬਹੁਤ ਤੇਜ਼ ਹੋਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਦੂਜਿਆਂ ਵਿੱਚ "ਬਹੁਤ ਤੇਜ਼ ਨਹੀਂ"। ਅੱਜ ਅਸੀਂ ਇੱਕ DBMS ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਡਿਵੈਲਪਰ ਇਸਦੇ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਟਕਰਾਅ ਦੀ ਇੱਕ ਸ਼ਾਨਦਾਰ ਉਦਾਹਰਣ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਾਂਗੇ - ਅੱਪਡੇਟ ਬਨਾਮ MVCC ਸਿਧਾਂਤ.

ਤੋਂ ਸੰਖੇਪ ਕਹਾਣੀ ਮਹਾਨ ਲੇਖ:

ਜਦੋਂ ਇੱਕ ਕਤਾਰ ਨੂੰ ਇੱਕ ਅੱਪਡੇਟ ਕਮਾਂਡ ਦੁਆਰਾ ਸੰਸ਼ੋਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਦੋ ਓਪਰੇਸ਼ਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: DELETE ਅਤੇ INSERT. IN ਸਤਰ ਦਾ ਮੌਜੂਦਾ ਸੰਸਕਰਣ xmax ਨੂੰ ਉਸ ਲੈਣ-ਦੇਣ ਦੀ ਸੰਖਿਆ ਦੇ ਬਰਾਬਰ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਸਨੇ ਅੱਪਡੇਟ ਕੀਤਾ ਹੈ। ਫਿਰ ਇਸ ਨੂੰ ਬਣਾਇਆ ਗਿਆ ਹੈ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਇੱਕੋ ਲਾਈਨ; ਇਸਦਾ xmin ਮੁੱਲ ਪਿਛਲੇ ਸੰਸਕਰਣ ਦੇ xmax ਮੁੱਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

ਇਸ ਲੈਣ-ਦੇਣ ਦੇ ਪੂਰਾ ਹੋਣ ਤੋਂ ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਪੁਰਾਣਾ ਜਾਂ ਨਵਾਂ ਸੰਸਕਰਣ, ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ COMMIT/ROOLBACK, ਨੂੰ ਮਾਨਤਾ ਦਿੱਤੀ ਜਾਵੇਗੀ "ਮੁਰਦਾ" (ਮ੍ਰਿਤ ਟੂਪਲਸ) ਲੰਘਣ ਵੇਲੇ VACUUM ਸਾਰਣੀ ਦੇ ਅਨੁਸਾਰ ਅਤੇ ਸਾਫ਼.

ਪਰ ਇਹ ਤੁਰੰਤ ਨਹੀਂ ਹੋਵੇਗਾ, ਪਰ "ਮੁਰਦੇ" ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਬਹੁਤ ਜਲਦੀ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ - ਵਾਰ-ਵਾਰ ਜਾਂ ਰਿਕਾਰਡਾਂ ਦਾ ਪੁੰਜ ਅੱਪਡੇਟ ਇੱਕ ਵੱਡੀ ਸਾਰਣੀ ਵਿੱਚ, ਅਤੇ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਤੁਹਾਨੂੰ ਉਸੇ ਸਥਿਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਵੇਗਾ VACUUM ਮਦਦ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ.

#1: ਮੈਨੂੰ ਇਸ ਨੂੰ ਮੂਵ ਕਰਨਾ ਪਸੰਦ ਹੈ

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੀ ਵਿਧੀ ਵਪਾਰਕ ਤਰਕ 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਅਚਾਨਕ ਇਹ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਕਿਸੇ ਰਿਕਾਰਡ ਵਿੱਚ X ਖੇਤਰ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ:

UPDATE tbl SET X = <newX> WHERE pk = $1;

ਫਿਰ, ਜਿਵੇਂ ਕਿ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਅੱਗੇ ਵਧਦਾ ਹੈ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ Y ਖੇਤਰ ਨੂੰ ਵੀ ਅਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

UPDATE tbl SET Y = <newY> WHERE pk = $1;

... ਅਤੇ ਫਿਰ Z ਵੀ - ਕਿਉਂ ਛੋਟੀਆਂ ਗੱਲਾਂ 'ਤੇ ਸਮਾਂ ਬਰਬਾਦ ਕਰੋ?

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

ਸਾਡੇ ਕੋਲ ਹੁਣ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਸ ਰਿਕਾਰਡ ਦੇ ਕਿੰਨੇ ਸੰਸਕਰਣ ਹਨ? ਹਾਂ, 4 ਟੁਕੜੇ! ਇਹਨਾਂ ਵਿੱਚੋਂ, ਇੱਕ ਢੁਕਵਾਂ ਹੈ, ਅਤੇ 3 ਨੂੰ [ਆਟੋ]ਵੈਕਿਊਮ ਦੁਆਰਾ ਤੁਹਾਡੇ ਤੋਂ ਬਾਅਦ ਸਾਫ਼ ਕਰਨਾ ਹੋਵੇਗਾ।

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

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2: ਵਰਤੋ IS DISTINCT FROM, ਲੂਕ!

ਇਸ ਲਈ, ਤੁਸੀਂ ਅਜੇ ਵੀ ਚਾਹੁੰਦੇ ਸੀ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ, ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਕ੍ਰਿਪਟ ਜਾਂ ਕਨਵਰਟਰ ਦੀ ਵਰਤੋਂ ਦੌਰਾਨ)। ਅਤੇ ਅਜਿਹਾ ਕੁਝ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਉੱਡਦਾ ਹੈ:

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਅਜਿਹੇ ਸ਼ਾਨਦਾਰ ਓਪਰੇਟਰ ਦੀ ਹੋਂਦ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਇੱਥੇ ਇੱਕ ਚੀਟ ਸ਼ੀਟ ਹੈ IS DISTINCT FROM ਅਤੇ ਹੋਰ ਲਾਜ਼ੀਕਲ ਓਪਰੇਟਰ ਮਦਦ ਕਰਨ ਲਈ:

... ਅਤੇ ਕੰਪਲੈਕਸ 'ਤੇ ਕਾਰਵਾਈਆਂ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ROW()-ਸਮੀਕਰਨ:

#3: ਮੈਂ ਆਪਣੇ ਪਿਆਰੇ ਨੂੰ... ਬਲੌਕ ਕਰਕੇ ਪਛਾਣਦਾ ਹਾਂ

ਲਾਂਚ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ ਦੋ ਸਮਾਨ ਸਮਾਂਤਰ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਐਂਟਰੀ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਇਹ "ਪ੍ਰਗਤੀ ਵਿੱਚ ਹੈ":

UPDATE tbl SET processing = TRUE WHERE pk = $1;

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

ਹੱਲ #1: ਕੰਮ ਨੂੰ ਪਿਛਲੇ ਇੱਕ ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ

ਚਲੋ ਇਸਨੂੰ ਦੁਬਾਰਾ ਜੋੜਦੇ ਹਾਂ IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

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

ਹੱਲ #2: ਸਲਾਹਕਾਰੀ ਤਾਲੇ

ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਲਈ ਇੱਕ ਵੱਡਾ ਵਿਸ਼ਾ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਤਰੀਕੇ ਅਤੇ ਸਿਫਾਰਸ਼ੀ ਬਲਾਕਿੰਗ ਦੇ "ਰੇਕ".

ਹੱਲ #3: ਮੂਰਖ ਕਾਲਾਂ

ਪਰ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਨਾਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਇੱਕੋ ਰਿਕਾਰਡ ਦੇ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਦਾ ਕੰਮ? ਜਾਂ ਕੀ ਤੁਸੀਂ ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਐਲਗੋਰਿਦਮ ਨਾਲ ਗੜਬੜ ਕੀਤੀ, ਉਦਾਹਰਣ ਲਈ? ਅਤੇ ਜੇ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਸੋਚਦੇ ਹੋ? ..

ਸਰੋਤ: www.habr.com