DBA: ਸਮਕਾਲੀਕਰਨ ਅਤੇ ਆਯਾਤ ਨੂੰ ਸਮਰੱਥ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕਰੋ

ਵੱਡੇ ਡੇਟਾ ਸੈੱਟਾਂ ਦੀ ਗੁੰਝਲਦਾਰ ਪ੍ਰਕਿਰਿਆ ਲਈ (ਵੱਖ ETL ਪ੍ਰਕਿਰਿਆਵਾਂ: ਇੱਕ ਬਾਹਰੀ ਸਰੋਤ ਨਾਲ ਆਯਾਤ, ਪਰਿਵਰਤਨ ਅਤੇ ਸਮਕਾਲੀਕਰਨ) ਅਕਸਰ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਸਥਾਈ ਤੌਰ 'ਤੇ "ਯਾਦ ਰੱਖੋ" ਅਤੇ ਤੁਰੰਤ ਕਾਰਵਾਈ ਕਰੋ ਕੁਝ ਵਿਸ਼ਾਲ

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

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

PostgreSQL ਵਿੱਚ ਉਹਨਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ (ਅਤੇ ਇਸ ਵਿੱਚ ਹੀ ਨਹੀਂ), ਤੁਸੀਂ ਕੁਝ ਅਨੁਕੂਲਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਘੱਟ ਸਰੋਤ ਖਪਤ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ।

1. ਕਿੱਥੇ ਭੇਜਣਾ ਹੈ?

ਪਹਿਲਾਂ, ਆਓ ਇਹ ਫੈਸਲਾ ਕਰੀਏ ਕਿ ਅਸੀਂ ਉਸ ਡੇਟਾ ਨੂੰ ਕਿੱਥੇ ਅਪਲੋਡ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿਸਨੂੰ ਅਸੀਂ "ਪ੍ਰਕਿਰਿਆ" ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

1.1 ਅਸਥਾਈ ਟੇਬਲ (ਆਰਜ਼ੀ ਸਾਰਣੀ)

ਅਸੂਲ ਵਿੱਚ, PostgreSQL ਲਈ ਅਸਥਾਈ ਟੇਬਲ ਕਿਸੇ ਹੋਰ ਦੇ ਸਮਾਨ ਹਨ। ਇਸ ਲਈ, ਅੰਧਵਿਸ਼ਵਾਸਾਂ ਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਨ "ਉੱਥੇ ਹਰ ਚੀਜ਼ ਸਿਰਫ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ". ਪਰ ਕਈ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਵੀ ਹਨ.

ਡੇਟਾਬੇਸ ਨਾਲ ਹਰੇਕ ਕਨੈਕਸ਼ਨ ਲਈ ਤੁਹਾਡਾ ਆਪਣਾ "ਨੇਮਸਪੇਸ"

ਜੇਕਰ ਦੋ ਕੁਨੈਕਸ਼ਨ ਇੱਕੋ ਸਮੇਂ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ CREATE TABLE x, ਫਿਰ ਕਿਸੇ ਨੂੰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕਰੇਗਾ ਗੈਰ-ਵਿਲੱਖਣਤਾ ਗਲਤੀ ਡਾਟਾਬੇਸ ਆਬਜੈਕਟ.

ਪਰ ਜੇ ਦੋਨੋ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ CREATE TEMPORARY TABLE x, ਫਿਰ ਦੋਵੇਂ ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਰਨਗੇ, ਅਤੇ ਹਰ ਕੋਈ ਪ੍ਰਾਪਤ ਕਰੇਗਾ ਤੁਹਾਡੀ ਕਾਪੀ ਟੇਬਲ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਕੁਝ ਵੀ ਸਾਂਝਾ ਨਹੀਂ ਹੋਵੇਗਾ.

ਡਿਸਕਨੈਕਟ ਕਰਨ ਵੇਲੇ "ਸਵੈ-ਵਿਨਾਸ਼"

ਜਦੋਂ ਕੁਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਰੀਆਂ ਅਸਥਾਈ ਟੇਬਲਾਂ ਆਪਣੇ ਆਪ ਮਿਟਾ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਹੱਥੀਂ DROP TABLE x ਸਿਵਾਏ ਕੋਈ ਬਿੰਦੂ ਨਹੀਂ...

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

ਇਸਲਈ, ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ, ਇੱਕ ਵੱਖਰੇ ਕਨੈਕਸ਼ਨ ਤੋਂ pgbouncer ਤੱਕ, ਇੱਕ ਗਲਤੀ ਹੋਵੇਗੀ। ਪਰ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ CREATE TEMPORARY TABLE IF NOT EXISTS x.

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

ਗੈਰ-ਪ੍ਰਤੀਕ੍ਰਿਤੀ

ਕਿਉਂਕਿ ਉਹ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ ਕੁਨੈਕਸ਼ਨ ਨਾਲ ਸਬੰਧਤ ਹਨ, ਅਸਥਾਈ ਟੇਬਲਾਂ ਨੂੰ ਦੁਹਰਾਇਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ। ਪਰ ਇਹ ਡਾਟਾ ਦੀ ਡਬਲ ਰਿਕਾਰਡਿੰਗ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਹੀਪ + WAL ਵਿੱਚ, ਇਸਲਈ ਇਸ ਵਿੱਚ INSERT/UPDATE/DELETE ਬਹੁਤ ਤੇਜ਼ ਹੈ।

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

1.2 ਅਣਲਾਗਡ ਟੇਬਲ

ਪਰ ਤੁਹਾਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਮੁਸ਼ਕਲ ETL ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਇੱਕ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਪਰ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਹੈ ਲੈਣ-ਦੇਣ ਮੋਡ ਵਿੱਚ pgbouncer? ..

ਜਾਂ ਡੇਟਾ ਦਾ ਪ੍ਰਵਾਹ ਇੰਨਾ ਵੱਡਾ ਹੈ ਕਿ ਇੱਕ ਕੁਨੈਕਸ਼ਨ 'ਤੇ ਲੋੜੀਂਦੀ ਬੈਂਡਵਿਡਥ ਨਹੀਂ ਹੈ ਇੱਕ ਡੇਟਾਬੇਸ ਤੋਂ (ਪੜ੍ਹੋ, ਪ੍ਰਤੀ CPU ਇੱਕ ਪ੍ਰਕਿਰਿਆ)?..

ਜਾਂ ਕੁਝ ਆਪਰੇਸ਼ਨ ਚੱਲ ਰਹੇ ਹਨ ਅਸਿੰਕ੍ਰੋਨਸ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਸਬੰਧਾਂ ਵਿੱਚ? ..

ਇੱਥੇ ਸਿਰਫ ਇੱਕ ਵਿਕਲਪ ਹੈ - ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਇੱਕ ਗੈਰ-ਆਰਜ਼ੀ ਸਾਰਣੀ ਬਣਾਓ. ਪੁਨ, ਹਾਂ। ਜੋ ਕਿ ਹੈ:

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

ਅਤੇ ਹੁਣ - ਅਤਰ ਵਿੱਚ ਇੱਕ ਮੱਖੀ. ਵਾਸਤਵ ਵਿੱਚ, PostgreSQL ਵਿੱਚ ਸਾਰੀਆਂ ਲਿਖਤਾਂ ਦੋ ਵਾਰ ਹੁੰਦੀਆਂ ਹਨ - WAL ਵਿੱਚ ਪਹਿਲਾਂ, ਫਿਰ ਟੇਬਲ/ਇੰਡੈਕਸ ਬਾਡੀਜ਼ ਵਿੱਚ। ਇਹ ਸਭ ACID ਦਾ ਸਮਰਥਨ ਕਰਨ ਅਤੇ ਵਿਚਕਾਰ ਡੇਟਾ ਦਿੱਖ ਨੂੰ ਸਹੀ ਕਰਨ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ COMMIT'ਨਟੀ ਅਤੇ ROLLBACK'ਨਲ ਲੈਣ-ਦੇਣ.

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

ਅਜਿਹਾ ਕਰਨ ਲਈ, PostgreSQL ਡਿਵੈਲਪਰਾਂ ਨੇ, ਵਰਜਨ 9.1 ਵਿੱਚ ਵਾਪਸ, ਅਜਿਹੀ ਚੀਜ਼ ਪੇਸ਼ ਕੀਤੀ ਜਿਵੇਂ ਕਿ ਅਣਲੌਗ ਕੀਤੇ ਟੇਬਲ:

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

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

ਜੇ ਨਹੀਂ, ਅਤੇ ਉਪਰੋਕਤ ਕੇਸ ਤੁਹਾਡੇ ਵਰਗਾ ਹੈ, ਤਾਂ ਵਰਤੋ UNLOGGEDਪਰ ਕਦੇ ਵੀ ਅਸਲ ਟੇਬਲ 'ਤੇ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਯੋਗ ਨਾ ਕਰੋ, ਜਿਸ ਤੋਂ ਡੇਟਾ ਤੁਹਾਡੇ ਲਈ ਪਿਆਰਾ ਹੈ।

1.3 ਕਮਿਟ ਕਰਨ 'ਤੇ { ਕਤਾਰਾਂ ਨੂੰ ਮਿਟਾਓ | ਡ੍ਰੌਪ}

ਇਹ ਨਿਰਮਾਣ ਤੁਹਾਨੂੰ ਆਟੋਮੈਟਿਕ ਵਿਵਹਾਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਸਾਰਣੀ ਬਣਾਉਣ ਵੇਲੇ ਕੋਈ ਲੈਣ-ਦੇਣ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ।

'ਤੇ ON COMMIT DROP ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਲਿਖਿਆ ਹੈ, ਇਹ ਬਣਾਉਂਦਾ ਹੈ DROP TABLE, ਪਰ ਨਾਲ ON COMMIT DELETE ROWS ਸਥਿਤੀ ਵਧੇਰੇ ਦਿਲਚਸਪ ਹੈ - ਇਹ ਇੱਥੇ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ TRUNCATE TABLE.

ਕਿਉਂਕਿ ਇੱਕ ਅਸਥਾਈ ਟੇਬਲ ਦੇ ਮੈਟਾ-ਵਰਣਨ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਪੂਰਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਇੱਕ ਨਿਯਮਤ ਸਾਰਣੀ ਦੇ ਸਮਾਨ ਹੈ, ਫਿਰ ਅਸਥਾਈ ਟੇਬਲਾਂ ਦੀ ਨਿਰੰਤਰ ਰਚਨਾ ਅਤੇ ਮਿਟਾਉਣ ਨਾਲ ਸਿਸਟਮ ਟੇਬਲਾਂ ਦੀ ਗੰਭੀਰ "ਸੋਜ" ਹੁੰਦੀ ਹੈ pg_class, pg_attribute, pg_attrdef, pg_depend,…

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

ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਨਾ ਕਰੋ! ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ CREATE TEMPORARY TABLE x ... ON COMMIT DELETE ROWS ਇਸਨੂੰ ਲੈਣ-ਦੇਣ ਦੇ ਚੱਕਰ ਵਿੱਚੋਂ ਬਾਹਰ ਕੱਢੋ - ਫਿਰ ਹਰੇਕ ਨਵੇਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਟੇਬਲ ਪਹਿਲਾਂ ਹੀ ਹਨ ਮੌਜੂਦ ਹੋਵੇਗਾ (ਇੱਕ ਕਾਲ ਸੁਰੱਖਿਅਤ ਕਰੋ CREATE), ਪਰ ਖਾਲੀ ਹੋ ਜਾਵੇਗਾ, ਦਾ ਧੰਨਵਾਦ TRUNCATE (ਅਸੀਂ ਇਸਦੀ ਕਾਲ ਨੂੰ ਵੀ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਹੈ) ਜਦੋਂ ਪਿਛਲੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਪੂਰਾ ਕੀਤਾ ਸੀ।

1.4 ਪਸੰਦ...ਸਮੇਤ...

ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤਾ ਸੀ ਕਿ ਅਸਥਾਈ ਟੇਬਲਾਂ ਲਈ ਆਮ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਆਯਾਤ ਹਨ - ਅਤੇ ਵਿਕਾਸਕਾਰ ਥੱਕ ਕੇ ਟੀਚੇ ਦੀ ਸਾਰਣੀ ਦੇ ਖੇਤਰਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਆਪਣੀ ਅਸਥਾਈ ਘੋਸ਼ਣਾ ਵਿੱਚ ਕਾਪੀ-ਪੇਸਟ ਕਰਦਾ ਹੈ...

ਪਰ ਆਲਸ ਤਰੱਕੀ ਦਾ ਇੰਜਣ ਹੈ! ਇਸ ਕਰਕੇ "ਨਮੂਨੇ ਦੇ ਅਧਾਰ ਤੇ" ਇੱਕ ਨਵੀਂ ਸਾਰਣੀ ਬਣਾਓ ਇਹ ਬਹੁਤ ਸਰਲ ਹੋ ਸਕਦਾ ਹੈ:

CREATE TEMPORARY TABLE import_table(
  LIKE target_table
);

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

ਕਿਉਂਕਿ, ਅਕਸਰ, ਲੋੜੀਂਦੇ ਸੂਚਕਾਂਕ ਨਿਸ਼ਾਨਾ ਸਾਰਣੀ ਦੇ ਸੂਚਕਾਂਕ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤੁਸੀਂ ਬਸ ਲਿਖ ਸਕਦੇ ਹੋ LIKE target_table INCLUDING INDEXES.

ਜੇਕਰ ਤੁਹਾਨੂੰ ਵੀ ਲੋੜ ਹੈ DEFAULT-values ​​(ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਮੁੱਲਾਂ ਨੂੰ ਭਰਨ ਲਈ), ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ LIKE target_table INCLUDING DEFAULTS. ਜਾਂ ਬਸ - LIKE target_table INCLUDING ALL — ਕਾਪੀਆਂ ਡਿਫੌਲਟ, ਸੂਚਕਾਂਕ, ਪਾਬੰਦੀਆਂ,...

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

ਸੰਖੇਪ ਵਿੱਚ, ਆਰਟੀਐਫਐਮ!

2. ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ?

ਮੈਨੂੰ ਸਿਰਫ ਇਹ ਕਹਿਣ ਦਿਓ - ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ COPY- "ਪੈਕ" ਦੀ ਬਜਾਏ ਵਹਾਓ INSERT, ਕਈ ਵਾਰ ਪ੍ਰਵੇਗ. ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਕੀਤੀ ਫਾਈਲ ਤੋਂ ਵੀ ਸਿੱਧੇ ਕਰ ਸਕਦੇ ਹੋ।

3. ਕਿਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕਰਨੀ ਹੈ?

ਇਸ ਲਈ ਮੰਨ ਲਓ ਕਿ ਸਾਡੀ ਜਾਣ-ਪਛਾਣ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

• ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਗਾਹਕ ਡੇਟਾ ਦੇ ਨਾਲ ਇੱਕ ਸਾਰਣੀ ਹੈ 1M ਰਿਕਾਰਡ
• ਹਰ ਰੋਜ਼ ਇੱਕ ਗਾਹਕ ਤੁਹਾਨੂੰ ਇੱਕ ਨਵਾਂ ਭੇਜਦਾ ਹੈ ਪੂਰੀ "ਚਿੱਤਰ"
• ਤਜਰਬੇ ਤੋਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਸਮੇਂ ਸਮੇਂ ਤੇ 10K ਤੋਂ ਵੱਧ ਰਿਕਾਰਡ ਨਹੀਂ ਬਦਲੇ ਜਾਂਦੇ

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

3.1 ਪੂਰਾ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਐਲਗੋਰਿਦਮ

ਸਰਲਤਾ ਲਈ, ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਨੂੰ ਡੇਟਾ ਦਾ ਪੁਨਰਗਠਨ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ - ਬਸ ਸਾਰਣੀ ਨੂੰ ਲੋੜੀਂਦੇ ਰੂਪ ਵਿੱਚ ਲਿਆਓ, ਇਹ ਹੈ:

• ਹਟਾਓ ਹਰ ਚੀਜ਼ ਜੋ ਹੁਣ ਮੌਜੂਦ ਨਹੀਂ ਹੈ
• ਅਪਡੇਟ ਹਰ ਚੀਜ਼ ਜੋ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ ਅਤੇ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ
• ਸੰਮਿਲਿਤ ਕਰਨ ਲਈ ਸਭ ਕੁਝ ਜੋ ਅਜੇ ਤੱਕ ਨਹੀਂ ਹੋਇਆ ਹੈ

ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਕਾਰਵਾਈਆਂ ਕਿਉਂ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ? ਕਿਉਂਕਿ ਇਸ ਤਰ੍ਹਾਂ ਟੇਬਲ ਦਾ ਆਕਾਰ ਘੱਟ ਤੋਂ ਘੱਟ ਵਧੇਗਾ (MVCC ਯਾਦ ਰੱਖੋ!).

dst ਤੋਂ ਮਿਟਾਓ

ਨਹੀਂ, ਬੇਸ਼ਕ ਤੁਸੀਂ ਸਿਰਫ ਦੋ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ:

• ਹਟਾਓ (DELETE) ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ
• ਸੰਮਿਲਿਤ ਕਰਨ ਲਈ ਸਾਰੇ ਨਵੇਂ ਚਿੱਤਰ ਤੋਂ

ਪਰ ਉਸੇ ਸਮੇਂ, MVCC ਦਾ ਧੰਨਵਾਦ, ਟੇਬਲ ਦਾ ਆਕਾਰ ਬਿਲਕੁਲ ਦੁੱਗਣਾ ਵਧ ਜਾਵੇਗਾ! ਇੱਕ 1K ਅੱਪਡੇਟ ਦੇ ਕਾਰਨ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਰਿਕਾਰਡਾਂ ਦੀਆਂ +10M ਤਸਵੀਰਾਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਬੇਲੋੜੀ ਹੈ...

TRUNCATE dst

ਇੱਕ ਵਧੇਰੇ ਤਜਰਬੇਕਾਰ ਡਿਵੈਲਪਰ ਜਾਣਦਾ ਹੈ ਕਿ ਪੂਰੀ ਟੈਬਲੇਟ ਨੂੰ ਕਾਫ਼ੀ ਸਸਤੇ ਵਿੱਚ ਸਾਫ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

• ਸਾਫ ਕਰਨ ਲਈ (TRUNCATE) ਪੂਰੀ ਸਾਰਣੀ
• ਸੰਮਿਲਿਤ ਕਰਨ ਲਈ ਸਾਰੇ ਨਵੇਂ ਚਿੱਤਰ ਤੋਂ

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

ਮਤਲਬ ਕੇ:

• ਅਸੀਂ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਾਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਟ੍ਰਾਂਜੈਕਸ਼ਨ
• TRUNCATE ਲਗਾਉਂਦਾ ਹੈ ਐਕਸਕਲੂਸਿਵ- ਬਲਾਕਿੰਗ
• ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸੰਮਿਲਨ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਸ ਸਮੇਂ ਹਰ ਕੋਈ ਵੀ ਨਹੀਂ ਕਰ ਸਕਦੇ SELECT

ਕੁਝ ਠੀਕ ਨਹੀਂ ਚੱਲ ਰਿਹਾ...

ਸਾਰਣੀ ਬਦਲੋ… ਨਾਮ ਬਦਲੋ… / ਸਾਰਣੀ ਛੱਡੋ…

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

• ਅਜੇ ਵੀ ਐਕਸਕਲੂਸਿਵ, ਹਾਲਾਂਕਿ ਕਾਫ਼ੀ ਘੱਟ ਸਮਾਂ ਹੈ
• ਇਸ ਸਾਰਣੀ ਲਈ ਸਾਰੀਆਂ ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਵਾਂ/ਅੰਕੜੇ ਰੀਸੈਟ ਕੀਤੇ ਗਏ ਹਨ, ANALYZE ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ
• ਸਾਰੀਆਂ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀਆਂ ਟੁੱਟ ਗਈਆਂ ਹਨ (FK) ਮੇਜ਼ ਨੂੰ

ਸਾਈਮਨ ਰਿਗਸ ਤੋਂ ਇੱਕ WIP ਪੈਚ ਸੀ ਜਿਸ ਨੇ ਬਣਾਉਣ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਸੀ ALTER- ਅੰਕੜਿਆਂ ਅਤੇ FK ਨੂੰ ਛੂਹਣ ਤੋਂ ਬਿਨਾਂ, ਫਾਈਲ ਪੱਧਰ 'ਤੇ ਟੇਬਲ ਬਾਡੀ ਨੂੰ ਬਦਲਣ ਲਈ ਇੱਕ ਓਪਰੇਸ਼ਨ, ਪਰ ਕੋਰਮ ਇਕੱਠਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।

ਮਿਟਾਓ, ਅੱਪਡੇਟ ਕਰੋ, ਸ਼ਾਮਲ ਕਰੋ

ਇਸ ਲਈ, ਅਸੀਂ ਤਿੰਨ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਗੈਰ-ਬਲਾਕਿੰਗ ਵਿਕਲਪ 'ਤੇ ਸੈਟਲ ਕਰਦੇ ਹਾਂ। ਲਗਭਗ ਤਿੰਨ... ਇਹ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਕਰੀਏ?

-- все делаем в рамках транзакции, чтобы никто не видел "промежуточных" состояний
BEGIN;

-- создаем временную таблицу с импортируемыми данными
CREATE TEMPORARY TABLE tmp(
  LIKE dst INCLUDING INDEXES -- по образу и подобию, вместе с индексами
) ON COMMIT DROP; -- за рамками транзакции она нам не нужна

-- быстро-быстро вливаем новый образ через COPY
COPY tmp FROM STDIN;
-- ...
-- .

-- удаляем отсутствующие
DELETE FROM
  dst D
USING
  dst X
LEFT JOIN
  tmp Y
    USING(pk1, pk2) -- поля первичного ключа
WHERE
  (D.pk1, D.pk2) = (X.pk1, X.pk2) AND
  Y IS NOT DISTINCT FROM NULL; -- "антиджойн"

-- обновляем оставшиеся
UPDATE
  dst D
SET
  (f1, f2, f3) = (T.f1, T.f2, T.f3)
FROM
  tmp T
WHERE
  (D.pk1, D.pk2) = (T.pk1, T.pk2) AND
  (D.f1, D.f2, D.f3) IS DISTINCT FROM (T.f1, T.f2, T.f3); -- незачем обновлять совпадающие

-- вставляем отсутствующие
INSERT INTO
  dst
SELECT
  T.*
FROM
  tmp T
LEFT JOIN
  dst D
    USING(pk1, pk2)
WHERE
  D IS NOT DISTINCT FROM NULL;

COMMIT;

3.2 ਪੋਸਟ-ਪ੍ਰੋਸੈਸਿੰਗ ਆਯਾਤ ਕਰੋ

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

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

-- целевые таблицы
CREATE TABLE kladr(...);
CREATE TABLE kladr_house(...);

-- таблицы с историей изменений
CREATE TABLE kladr$log(
  ro kladr, -- тут лежат целые образы записей старой/новой
  rn kladr
);

CREATE TABLE kladr_house$log(
  ro kladr_house,
  rn kladr_house
);

-- общая функция логирования изменений
CREATE OR REPLACE FUNCTION diff$log() RETURNS trigger AS $$
DECLARE
  dst varchar = TG_TABLE_NAME || '$log';
  stmt text = '';
BEGIN
  -- проверяем необходимость логгирования при обновлении записи
  IF TG_OP = 'UPDATE' THEN
    IF NEW IS NOT DISTINCT FROM OLD THEN
      RETURN NEW;
    END IF;
  END IF;
  -- создаем запись лога
  stmt = 'INSERT INTO ' || dst::text || '(ro,rn)VALUES(';
  CASE TG_OP
    WHEN 'INSERT' THEN
      EXECUTE stmt || 'NULL,$1)' USING NEW;
    WHEN 'UPDATE' THEN
      EXECUTE stmt || '$1,$2)' USING OLD, NEW;
    WHEN 'DELETE' THEN
      EXECUTE stmt || '$1,NULL)' USING OLD;
  END CASE;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

ਹੁਣ ਅਸੀਂ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟਰਿਗਰਸ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ (ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਇਸ ਰਾਹੀਂ ਯੋਗ ਕਰ ਸਕਦੇ ਹਾਂ ALTER TABLE ... ENABLE TRIGGER ...):

CREATE TRIGGER log
  AFTER INSERT OR UPDATE OR DELETE
  ON kladr
    FOR EACH ROW
      EXECUTE PROCEDURE diff$log();

CREATE TRIGGER log
  AFTER INSERT OR UPDATE OR DELETE
  ON kladr_house
    FOR EACH ROW
      EXECUTE PROCEDURE diff$log();

ਅਤੇ ਫਿਰ ਅਸੀਂ ਲੌਗ ਟੇਬਲਾਂ ਤੋਂ ਸਾਨੂੰ ਲੋੜੀਂਦੀਆਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸ਼ਾਂਤੀ ਨਾਲ ਐਕਸਟਰੈਕਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਾਧੂ ਹੈਂਡਲਰ ਦੁਆਰਾ ਚਲਾਉਂਦੇ ਹਾਂ।

3.3 ਲਿੰਕ ਕੀਤੇ ਸੈੱਟਾਂ ਨੂੰ ਆਯਾਤ ਕਰਨਾ

ਉੱਪਰ ਅਸੀਂ ਉਹਨਾਂ ਮਾਮਲਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਜਦੋਂ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਦੇ ਡੇਟਾ ਢਾਂਚੇ ਇੱਕੋ ਜਿਹੇ ਹੁੰਦੇ ਹਨ। ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਕਿਸੇ ਬਾਹਰੀ ਸਿਸਟਮ ਤੋਂ ਅੱਪਲੋਡ ਦਾ ਫਾਰਮੈਟ ਸਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰੇਜ ਢਾਂਚੇ ਤੋਂ ਵੱਖਰਾ ਹੋਵੇ?

ਆਉ ਕਲਾਇੰਟਸ ਅਤੇ ਉਹਨਾਂ ਦੇ ਖਾਤਿਆਂ ਦੀ ਸਟੋਰੇਜ, ਕਲਾਸਿਕ "ਕਈ-ਟੂ-ਵਨ" ਵਿਕਲਪ ਨੂੰ ਉਦਾਹਰਣ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ:

CREATE TABLE client(
  client_id
    serial
      PRIMARY KEY
, inn
    varchar
      UNIQUE
, name
    varchar
);

CREATE TABLE invoice(
  invoice_id
    serial
      PRIMARY KEY
, client_id
    integer
      REFERENCES client(client_id)
, number
    varchar
, dt
    date
, sum
    numeric(32,2)
);

ਪਰ ਇੱਕ ਬਾਹਰੀ ਸਰੋਤ ਤੋਂ ਡਾਊਨਲੋਡ ਸਾਡੇ ਕੋਲ "ਸਭ ਵਿੱਚ ਇੱਕ" ਦੇ ਰੂਪ ਵਿੱਚ ਆਉਂਦਾ ਹੈ:

CREATE TEMPORARY TABLE invoice_import(
  client_inn
    varchar
, client_name
    varchar
, invoice_number
    varchar
, invoice_dt
    date
, invoice_sum
    numeric(32,2)
);

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਗਾਹਕ ਡੇਟਾ ਨੂੰ ਇਸ ਸੰਸਕਰਣ ਵਿੱਚ ਡੁਪਲੀਕੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੁੱਖ ਰਿਕਾਰਡ "ਖਾਤਾ" ਹੈ:

0123456789;Вася;A-01;2020-03-16;1000.00
9876543210;Петя;A-02;2020-03-16;666.00
0123456789;Вася;B-03;2020-03-16;9999.00

ਮਾਡਲ ਲਈ, ਅਸੀਂ ਸਿਰਫ਼ ਆਪਣਾ ਟੈਸਟ ਡੇਟਾ ਪਾਵਾਂਗੇ, ਪਰ ਯਾਦ ਰੱਖੋ - COPY ਵਧੇਰੇ ਕੁਸ਼ਲ!

INSERT INTO invoice_import
VALUES
  ('0123456789', 'Вася', 'A-01', '2020-03-16', 1000.00)
, ('9876543210', 'Петя', 'A-02', '2020-03-16', 666.00)
, ('0123456789', 'Вася', 'B-03', '2020-03-16', 9999.00);

ਪਹਿਲਾਂ, ਆਉ ਉਹਨਾਂ "ਕਟੌਤੀਆਂ" ਨੂੰ ਉਜਾਗਰ ਕਰੀਏ ਜਿਹਨਾਂ ਦਾ ਸਾਡੇ "ਤੱਥ" ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਨਵੌਇਸ ਗਾਹਕਾਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ:

CREATE TEMPORARY TABLE client_import AS
SELECT DISTINCT ON(client_inn)
-- можно просто SELECT DISTINCT, если данные заведомо непротиворечивы
  client_inn inn
, client_name "name"
FROM
  invoice_import;

ਖਾਤਿਆਂ ਨੂੰ ਗਾਹਕ IDs ਨਾਲ ਸਹੀ ਢੰਗ ਨਾਲ ਜੋੜਨ ਲਈ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਇਹਨਾਂ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਲੱਭਣ ਜਾਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਆਓ ਉਹਨਾਂ ਦੇ ਹੇਠਾਂ ਖੇਤਰ ਜੋੜੀਏ:

ALTER TABLE invoice_import ADD COLUMN client_id integer;
ALTER TABLE client_import ADD COLUMN client_id integer;

ਆਉ ਇੱਕ ਛੋਟੀ ਸੋਧ ਦੇ ਨਾਲ ਉੱਪਰ ਦੱਸੇ ਗਏ ਟੇਬਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰੀਏ - ਅਸੀਂ ਟਾਰਗੇਟ ਟੇਬਲ ਵਿੱਚ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਅਪਡੇਟ ਜਾਂ ਮਿਟਾ ਨਹੀਂ ਦੇਵਾਂਗੇ, ਕਿਉਂਕਿ ਅਸੀਂ ਕਲਾਇੰਟਸ ਨੂੰ "ਸਿਰਫ਼ ਜੋੜ" ਆਯਾਤ ਕਰਦੇ ਹਾਂ:

-- проставляем в таблице импорта ID уже существующих записей
UPDATE
  client_import T
SET
  client_id = D.client_id
FROM
  client D
WHERE
  T.inn = D.inn; -- unique key

-- вставляем отсутствовавшие записи и проставляем их ID
WITH ins AS (
  INSERT INTO client(
    inn
  , name
  )
  SELECT
    inn
  , name
  FROM
    client_import
  WHERE
    client_id IS NULL -- если ID не проставился
  RETURNING *
)
UPDATE
  client_import T
SET
  client_id = D.client_id
FROM
  ins D
WHERE
  T.inn = D.inn; -- unique key

-- проставляем ID клиентов у записей счетов
UPDATE
  invoice_import T
SET
  client_id = D.client_id
FROM
  client_import D
WHERE
  T.client_inn = D.inn; -- прикладной ключ

ਅਸਲ ਵਿੱਚ, ਸਭ ਕੁਝ ਅੰਦਰ ਹੈ invoice_import ਹੁਣ ਸਾਡੇ ਕੋਲ ਸੰਪਰਕ ਖੇਤਰ ਭਰ ਗਿਆ ਹੈ client_id, ਜਿਸ ਨਾਲ ਅਸੀਂ ਇਨਵੌਇਸ ਪਾਵਾਂਗੇ।

ਸਰੋਤ: www.habr.com