ਜਦੋਂ ਵੈਕਿਊਮ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਸੀਂ ਟੇਬਲ ਨੂੰ ਹੱਥੀਂ ਸਾਫ਼ ਕਰਦੇ ਹਾਂ

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

ਪਰ ਕੀ ਜੇ ਅਜਿਹੀ ਕੋਝਾ ਕਿਸਮ (ਇੱਕ OLTP ਡੇਟਾਬੇਸ 'ਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ OLAP ਲੋਡ) ਅਜੇ ਵੀ ਮੌਜੂਦ ਹੈ? ਕਿਵੇਂ ਸਰਗਰਮੀ ਨਾਲ ਬਦਲਣ ਵਾਲੀ ਸਾਰਣੀ ਨੂੰ ਸਾਫ਼ ਕਰੋ ਲੰਬੇ ਸਵਾਲਾਂ ਨਾਲ ਘਿਰਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਰੇਕ 'ਤੇ ਕਦਮ ਨਹੀਂ ਰੱਖਦਾ?

ਰੇਕ ਨੂੰ ਖੋਲ੍ਹਣਾ

ਪਹਿਲਾਂ, ਆਓ ਇਹ ਨਿਰਧਾਰਤ ਕਰੀਏ ਕਿ ਅਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਇਹ ਕਿਵੇਂ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ।

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

ਆਉ ਰੇਟਿੰਗਾਂ ਦੇ ਨਾਲ ਵਿਕਲਪ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ:

CREATE TABLE tbl(k text PRIMARY KEY, v integer);
CREATE INDEX ON tbl(v DESC); -- по этому индексу будем строить рейтинг

INSERT INTO
  tbl
SELECT
  chr(ascii('a'::text) + i) k
, 0 v
FROM
  generate_series(0, 25) i;

ਅਤੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚ, ਇੱਕ ਹੋਰ ਕੁਨੈਕਸ਼ਨ ਵਿੱਚ, ਇੱਕ ਲੰਮੀ, ਲੰਮੀ ਬੇਨਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਕੁਝ ਗੁੰਝਲਦਾਰ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਦੇ ਹਨ, ਪਰ ਸਾਡੇ ਟੇਬਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰ ਰਿਹਾ:

SELECT pg_sleep(10000);

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

DO $$
DECLARE
  i integer;
  tsb timestamp;
  tse timestamp;
  d double precision;
BEGIN
  PERFORM dblink_connect('dbname=' || current_database() || ' port=' || current_setting('port'));
  FOR i IN 1..10000 LOOP
    tsb = clock_timestamp();
    PERFORM dblink($e$UPDATE tbl SET v = v + 1 WHERE k = 'a';$e$);
    tse = clock_timestamp();
    IF i % 1000 = 0 THEN
      d = (extract('epoch' from tse) - extract('epoch' from tsb)) * 1000;
      RAISE NOTICE 'i = %, exectime = %', lpad(i::text, 5), lpad(d::text, 5);
    END IF;
  END LOOP;
  PERFORM dblink_disconnect();
END;
$$ LANGUAGE plpgsql;

NOTICE:  i =  1000, exectime = 0.524
NOTICE:  i =  2000, exectime = 0.739
NOTICE:  i =  3000, exectime = 1.188
NOTICE:  i =  4000, exectime = 2.508
NOTICE:  i =  5000, exectime = 1.791
NOTICE:  i =  6000, exectime = 2.658
NOTICE:  i =  7000, exectime = 2.318
NOTICE:  i =  8000, exectime = 2.572
NOTICE:  i =  9000, exectime = 2.929
NOTICE:  i = 10000, exectime = 3.808

ਕੀ ਹੋਇਆ? ਇੱਕ ਸਿੰਗਲ ਰਿਕਾਰਡ ਦੇ ਸਧਾਰਨ ਅੱਪਡੇਟ ਲਈ ਵੀ ਕਿਉਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ 7 ਗੁਣਾ ਘਟਾਇਆ ਗਿਆ - 0.524ms ਤੋਂ 3.808ms ਤੱਕ? ਅਤੇ ਸਾਡੀ ਰੇਟਿੰਗ ਹੌਲੀ-ਹੌਲੀ ਬਣ ਰਹੀ ਹੈ।

ਇਹ ਸਭ MVCC ਦਾ ਕਸੂਰ ਹੈ।

ਇਹ ਸਭ ਦੇ ਬਾਰੇ ਹੈ MVCC ਵਿਧੀ, ਜੋ ਕਿ ਇੰਦਰਾਜ਼ ਦੇ ਸਾਰੇ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਵੇਖਣ ਲਈ ਪੁੱਛਗਿੱਛ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਇਸ ਲਈ ਆਓ ਆਪਣੇ ਟੇਬਲ ਨੂੰ "ਮ੍ਰਿਤ" ਸੰਸਕਰਣਾਂ ਤੋਂ ਸਾਫ਼ ਕਰੀਏ:

VACUUM VERBOSE tbl;

INFO:  vacuuming "public.tbl"
INFO:  "tbl": found 0 removable, 10026 nonremovable row versions in 45 out of 45 pages
DETAIL:  10000 dead row versions cannot be removed yet, oldest xmin: 597439602

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

ਸਾਰਣੀ ਨੂੰ "ਟੁੱਟਣਾ"

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

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

#0: ਸਥਿਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਓਪਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ ਟੇਬਲ ਦੇ ਨਾਲ ਕੁਝ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਰਥ ਨਹੀਂ ਰੱਖਦਾ - ਮੇਨਟੇਨੈਂਸ ਓਵਰਹੈੱਡ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਸ਼ਾਨਾ ਸਵਾਲਾਂ ਦੇ ਥ੍ਰਰੂਪੁਟ ਤੋਂ ਵੱਧ ਹੋਵੇਗਾ।

ਆਓ ਮਾਪਦੰਡ ਤਿਆਰ ਕਰੀਏ - "ਇਹ ਕੰਮ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ" ਜੇਕਰ:

• ਵੈਕਿਊਮ ਨੂੰ ਕਾਫੀ ਸਮਾਂ ਪਹਿਲਾਂ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ
  ਸਾਨੂੰ ਇੱਕ ਭਾਰੀ ਬੋਝ ਦੀ ਉਮੀਦ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਹੋਣ ਦਿਓ 60 ਸਕਿੰਟ ਪਿਛਲੇ [ਆਟੋ] ਵੈਕਿਊਮ ਤੋਂ।
• ਭੌਤਿਕ ਸਾਰਣੀ ਦਾ ਆਕਾਰ ਟੀਚੇ ਤੋਂ ਵੱਡਾ ਹੈ
  ਚਲੋ ਇਸਨੂੰ ਘੱਟੋ-ਘੱਟ ਆਕਾਰ ਦੇ ਮੁਕਾਬਲੇ ਪੰਨਿਆਂ ਦੀ ਸੰਖਿਆ (8KB ਬਲਾਕ) ਦੇ ਦੁੱਗਣੇ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੀਏ - ਹੀਪ ਲਈ 1 blk + ਹਰੇਕ ਸੂਚਕਾਂਕ ਲਈ 1 blk - ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖਾਲੀ ਟੇਬਲ ਲਈ। ਜੇ ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਡੇਟਾ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਾਤਰਾ ਹਮੇਸ਼ਾ "ਆਮ ਤੌਰ 'ਤੇ" ਬਫਰ ਵਿੱਚ ਰਹੇਗੀ, ਤਾਂ ਇਸ ਫਾਰਮੂਲੇ ਨੂੰ ਬਦਲਣਾ ਉਚਿਤ ਹੈ।

ਪੁਸ਼ਟੀਕਰਨ ਬੇਨਤੀ

SELECT
  relpages
, ((
    SELECT
      count(*)
    FROM
      pg_index
    WHERE
      indrelid = cl.oid
  ) + 1) << 13 size_norm -- тут правильнее делать * current_setting('block_size')::bigint, но кто меняет размер блока?..
, pg_total_relation_size(oid) size
, coalesce(extract('epoch' from (now() - greatest(
    pg_stat_get_last_vacuum_time(oid)
  , pg_stat_get_last_autovacuum_time(oid)
  ))), 1 << 30) vaclag
FROM
  pg_class cl
WHERE
  oid = $1::regclass -- tbl
LIMIT 1;

relpages | size_norm | size    | vaclag
-------------------------------------------
       0 |     24576 | 1105920 | 3392.484835

#1: ਅਜੇ ਵੀ ਵੈਕਿਊਮ

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

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

#2: ਕੀ ਕੋਈ ਘਰ ਹੈ?

ਆਉ ਜਾਂਚ ਕਰੀਏ ਕਿ ਕੀ ਸਾਰਣੀ ਵਿੱਚ ਕੁਝ ਵੀ ਹੈ:

TABLE tbl LIMIT 1;

ਜੇਕਰ ਇੱਕ ਵੀ ਰਿਕਾਰਡ ਨਹੀਂ ਬਚਿਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਸਿਰਫ਼ ਕਰ ਕੇ ਪ੍ਰੋਸੈਸਿੰਗ 'ਤੇ ਬਹੁਤ ਕੁਝ ਬਚਾ ਸਕਦੇ ਹਾਂ ਸੱਚਾਈ:

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

ਕੀ ਤੁਹਾਨੂੰ ਟੇਬਲ ਕ੍ਰਮ ਕਾਊਂਟਰ (ਰੀਸਟਾਰਟ ਆਈਡੈਂਟਿਟੀ) ਨੂੰ ਰੀਸੈਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਫੈਸਲਾ ਤੁਹਾਡੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

#3: ਹਰ ਕੋਈ - ਵਾਰੀ ਲਓ!

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

ਅਜਿਹਾ ਕਰਨ ਲਈ ਸਾਨੂੰ ਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਗੰਭੀਰ-ਸਾਡੇ ਲੈਣ-ਦੇਣ ਲਈ ਅਲੱਗ-ਥਲੱਗ (ਹਾਂ, ਇੱਥੇ ਅਸੀਂ ਇੱਕ ਲੈਣ-ਦੇਣ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ) ਅਤੇ ਟੇਬਲ ਨੂੰ "ਕੰਟ" ਨਾਲ ਲਾਕ ਕਰਦੇ ਹਾਂ:

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
LOCK TABLE tbl IN ACCESS EXCLUSIVE MODE;

ਬਲਾਕਿੰਗ ਦਾ ਇਹ ਪੱਧਰ ਉਹਨਾਂ ਓਪਰੇਸ਼ਨਾਂ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਇਸ 'ਤੇ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

#4: ਹਿੱਤਾਂ ਦਾ ਟਕਰਾਅ

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

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

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸੈਸ਼ਨ ਵੇਰੀਏਬਲ ਸੈੱਟ ਕਰੋ lock_timeout (ਸੰਸਕਰਣ 9.3+ ਲਈ) ਜਾਂ/ਅਤੇ ਸਟੇਟਮੈਂਟ_ਟਾਈਮਆਊਟ. ਯਾਦ ਰੱਖਣ ਵਾਲੀ ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਟੇਟਮੈਂਟ_ਟਾਈਮਆਉਟ ਮੁੱਲ ਸਿਰਫ ਅਗਲੇ ਸਟੇਟਮੈਂਟ ਤੋਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਯਾਨੀ ਗਲੂਇੰਗ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ - ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ:

SET statement_timeout = ...;LOCK TABLE ...;

ਵੇਰੀਏਬਲ ਦੇ "ਪੁਰਾਣੇ" ਮੁੱਲ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਬਹਾਲ ਕਰਨ ਨਾਲ ਨਜਿੱਠਣ ਲਈ, ਅਸੀਂ ਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਸਥਾਨਕ ਸੈੱਟ ਕਰੋ, ਜੋ ਮੌਜੂਦਾ ਲੈਣ-ਦੇਣ ਲਈ ਸੈਟਿੰਗ ਦੇ ਦਾਇਰੇ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।

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

#5: ਡਾਟਾ ਕਾਪੀ ਕਰੋ

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

CREATE TEMPORARY TABLE _tmp_swap ON COMMIT DROP AS TABLE tbl;

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

ਕਿਉਂਕਿ ਅਸੀਂ ਇਹ ਮੰਨਦੇ ਹਾਂ ਕਿ ਇੱਥੇ ਬਹੁਤ ਸਾਰਾ "ਲਾਈਵ" ਡੇਟਾ ਨਹੀਂ ਹੈ, ਇਹ ਕਾਰਵਾਈ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਖੈਰ, ਇਹ ਸਭ ਕੁਝ ਹੈ! ਲੈਣ-ਦੇਣ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ ਨਾ ਭੁੱਲੋ ਵਿਸ਼ਲੇਸ਼ਣ ਚਲਾਓ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਾਰਣੀ ਦੇ ਅੰਕੜਿਆਂ ਨੂੰ ਆਮ ਬਣਾਉਣ ਲਈ।

ਅੰਤਿਮ ਸਕ੍ਰਿਪਟ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ

ਅਸੀਂ ਇਸ "ਸੂਡੋ-ਪਾਈਥਨ" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ:

# собираем статистику с таблицы
stat <-
  SELECT
    relpages
  , ((
      SELECT
        count(*)
      FROM
        pg_index
      WHERE
        indrelid = cl.oid
    ) + 1) << 13 size_norm
  , pg_total_relation_size(oid) size
  , coalesce(extract('epoch' from (now() - greatest(
      pg_stat_get_last_vacuum_time(oid)
    , pg_stat_get_last_autovacuum_time(oid)
    ))), 1 << 30) vaclag
  FROM
    pg_class cl
  WHERE
    oid = $1::regclass -- table_name
  LIMIT 1;

# таблица больше целевого размера и VACUUM был давно
if stat.size > 2 * stat.size_norm and stat.vaclag is None or stat.vaclag > 60:
  -> VACUUM %table;
  try:
    -> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
    # пытаемся захватить монопольную блокировку с предельным временем ожидания 1s
    -> SET LOCAL statement_timeout = '1s'; SET LOCAL lock_timeout = '1s';
    -> LOCK TABLE %table IN ACCESS EXCLUSIVE MODE;
    # надо убедиться в пустоте таблицы внутри транзакции с блокировкой
    row <- TABLE %table LIMIT 1;
    # если в таблице нет ни одной "живой" записи - очищаем ее полностью, в противном случае - "перевставляем" все записи через временную таблицу
    if row is None:
      -> TRUNCATE TABLE %table RESTART IDENTITY;
    else:
      # создаем временную таблицу с данными таблицы-оригинала
      -> CREATE TEMPORARY TABLE _tmp_swap ON COMMIT DROP AS TABLE %table;
      # очищаем оригинал без сброса последовательности
      -> TRUNCATE TABLE %table;
      # вставляем все сохраненные во временной таблице данные обратно
      -> INSERT INTO %table TABLE _tmp_swap;
    -> COMMIT;
  except Exception as e:
    # если мы получили ошибку, но соединение все еще "живо" - словили таймаут
    if not isinstance(e, InterfaceError):
      -> ROLLBACK;

ਕੀ ਦੂਜੀ ਵਾਰ ਡੇਟਾ ਦੀ ਨਕਲ ਨਾ ਕਰਨਾ ਸੰਭਵ ਹੈ?ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇਹ ਸੰਭਵ ਹੈ ਜੇਕਰ ਸਾਰਣੀ ਦਾ oid ਖੁਦ BL ਸਾਈਡ ਜਾਂ FK DB ਪਾਸੇ ਤੋਂ ਕਿਸੇ ਹੋਰ ਗਤੀਵਿਧੀਆਂ ਨਾਲ ਨਹੀਂ ਜੁੜਿਆ ਹੋਇਆ ਹੈ:

CREATE TABLE _swap_%table(LIKE %table INCLUDING ALL);
INSERT INTO _swap_%table TABLE %table;
DROP TABLE %table;
ALTER TABLE _swap_%table RENAME TO %table;

ਆਉ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸਰੋਤ ਸਾਰਣੀ 'ਤੇ ਚਲਾਉਂਦੇ ਹਾਂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ:

VACUUM tbl;
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
  SET LOCAL statement_timeout = '1s'; SET LOCAL lock_timeout = '1s';
  LOCK TABLE tbl IN ACCESS EXCLUSIVE MODE;
  CREATE TEMPORARY TABLE _tmp_swap ON COMMIT DROP AS TABLE tbl;
  TRUNCATE TABLE tbl;
  INSERT INTO tbl TABLE _tmp_swap;
COMMIT;

relpages | size_norm | size   | vaclag
-------------------------------------------
       0 |     24576 |  49152 | 32.705771

ਸਭ ਕੁਝ ਕੰਮ ਕੀਤਾ! ਸਾਰਣੀ 50 ਵਾਰ ਸੁੰਗੜ ਗਈ ਹੈ ਅਤੇ ਸਾਰੇ ਅੱਪਡੇਟ ਦੁਬਾਰਾ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਰਹੇ ਹਨ।

ਸਰੋਤ: www.habr.com