PostgreSQL ਵਿੱਚ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਇੱਕ ਪੈਸਾ ਬਚਾਓ

ਦੁਆਰਾ ਉਠਾਏ ਗਏ ਵੱਡੇ ਡੇਟਾ ਸਟ੍ਰੀਮ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਦੇ ਵਿਸ਼ੇ ਨੂੰ ਜਾਰੀ ਰੱਖਣਾ ਵੰਡ ਬਾਰੇ ਪਿਛਲਾ ਲੇਖ, ਇਸ ਵਿੱਚ ਅਸੀਂ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਨੂੰ ਦੇਖਾਂਗੇ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਸਟੋਰ ਕੀਤੇ "ਭੌਤਿਕ" ਆਕਾਰ ਨੂੰ ਘਟਾਓ PostgreSQL ਵਿੱਚ, ਅਤੇ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਉਹਨਾਂ ਦਾ ਪ੍ਰਭਾਵ.

ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ TOAST ਸੈਟਿੰਗਾਂ ਅਤੇ ਡਾਟਾ ਅਲਾਈਨਮੈਂਟ. “ਔਸਤਨ,” ਇਹ ਵਿਧੀਆਂ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਬੱਚਤ ਨਹੀਂ ਕਰਨਗੀਆਂ, ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਸੋਧੇ ਬਿਨਾਂ।

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

ਵੱਡੇ ਡੇਟਾ ਦੇ ਛੋਟੇ ਰਾਜ਼

ਨੌਕਰੀ ਪ੍ਰੋਫਾਈਲ ਦੁਆਰਾ ਸਾਡੀ ਸੇਵਾ, ਉਹ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ lairs ਤੱਕ ਉਸ ਨੂੰ ਉੱਡਦੀ ਹੈ ਟੈਕਸਟ ਪੈਕੇਜ.

ਅਤੇ ਉਦੋਂ ਤੋਂ VLSI ਕੰਪਲੈਕਸਜਿਸਦੇ ਡੇਟਾਬੇਸ ਦੀ ਅਸੀਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ, ਗੁੰਝਲਦਾਰ ਡੇਟਾ ਢਾਂਚੇ ਦੇ ਨਾਲ ਇੱਕ ਬਹੁ-ਕੰਪੋਨੈਂਟ ਉਤਪਾਦ ਹੈ, ਫਿਰ ਪੁੱਛਗਿੱਛ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਬਿਲਕੁਲ ਇਸ ਤਰ੍ਹਾਂ ਬਾਹਰ ਨਿਕਲੋ ਗੁੰਝਲਦਾਰ ਐਲਗੋਰਿਦਮਿਕ ਤਰਕ ਦੇ ਨਾਲ "ਮਲਟੀ-ਵਾਲਿਊਮ". ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਆਉਣ ਵਾਲੇ ਲੌਗ ਵਿੱਚ ਇੱਕ ਬੇਨਤੀ ਦੇ ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਉਦਾਹਰਨ ਜਾਂ ਨਤੀਜੇ ਵਜੋਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਦੀ ਮਾਤਰਾ "ਔਸਤਨ" ਕਾਫ਼ੀ ਵੱਡੀ ਹੁੰਦੀ ਹੈ।

ਆਉ ਉਹਨਾਂ ਟੇਬਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਬਣਤਰ ਨੂੰ ਵੇਖੀਏ ਜਿਸ ਵਿੱਚ ਅਸੀਂ "ਕੱਚਾ" ਡੇਟਾ ਲਿਖਦੇ ਹਾਂ - ਯਾਨੀ, ਇੱਥੇ ਲੌਗ ਐਂਟਰੀ ਤੋਂ ਅਸਲ ਟੈਕਸਟ ਹੈ:

CREATE TABLE rawdata_orig(
  pack -- PK
    uuid NOT NULL
, recno -- PK
    smallint NOT NULL
, dt -- ключ секции
    date
, data -- самое главное
    text
, PRIMARY KEY(pack, recno)
);

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

ਯਾਦ ਕਰੋ ਕਿ ਇੱਕ ਪੀਜੀ ਵਿੱਚ ਇੱਕ ਰਿਕਾਰਡ ਦਾ "ਭੌਤਿਕ" ਆਕਾਰ ਇੱਕ ਤੋਂ ਵੱਧ ਪੰਨਿਆਂ ਦੇ ਡੇਟਾ ਨੂੰ ਨਹੀਂ ਲੈ ਸਕਦਾ, ਪਰ "ਲਾਜ਼ੀਕਲ" ਆਕਾਰ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਵੋਲਯੂਮੈਟ੍ਰਿਕ ਮੁੱਲ (varchar/text/bytea) ਲਿਖਣ ਲਈ, ਵਰਤੋ ਟੋਸਟ ਤਕਨਾਲੋਜੀ:

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

ਵਾਸਤਵ ਵਿੱਚ, "ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਵੱਡੇ" ਖੇਤਰਾਂ ਵਾਲੀ ਹਰੇਕ ਸਾਰਣੀ ਲਈ, ਆਪਣੇ ਆਪ "ਸਲਾਈਸਿੰਗ" ਦੇ ਨਾਲ ਇੱਕ ਪੇਅਰਡ ਟੇਬਲ ਬਣਾਇਆ ਗਿਆ ਹੈ 2KB ਖੰਡਾਂ ਵਿੱਚ ਹਰੇਕ "ਵੱਡਾ" ਰਿਕਾਰਡ:

TOAST(
  chunk_id
    integer
, chunk_seq
    integer
, chunk_data
    bytea
, PRIMARY KEY(chunk_id, chunk_seq)
);

ਭਾਵ, ਜੇਕਰ ਸਾਨੂੰ "ਵੱਡੇ" ਮੁੱਲ ਦੇ ਨਾਲ ਇੱਕ ਸਤਰ ਲਿਖਣੀ ਹੈ data, ਫਿਰ ਅਸਲੀ ਰਿਕਾਰਡਿੰਗ ਹੋਵੇਗੀ ਨਾ ਸਿਰਫ਼ ਮੁੱਖ ਟੇਬਲ ਅਤੇ ਇਸਦੇ PK ਲਈ, ਸਗੋਂ TOAST ਅਤੇ ਇਸਦੇ PK ਲਈ ਵੀ.

ਟੋਸਟ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣਾ

ਪਰ ਸਾਡੇ ਬਹੁਤੇ ਰਿਕਾਰਡ ਅਜੇ ਵੀ ਇੰਨੇ ਵੱਡੇ ਨਹੀਂ ਹਨ, 8KB ਵਿੱਚ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ - ਮੈਂ ਇਸ 'ਤੇ ਪੈਸੇ ਕਿਵੇਂ ਬਚਾ ਸਕਦਾ ਹਾਂ? ..

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਗੁਣ ਸਾਡੀ ਸਹਾਇਤਾ ਲਈ ਆਉਂਦਾ ਹੈ STORAGE ਟੇਬਲ ਕਾਲਮ 'ਤੇ:

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

ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਸਾਨੂੰ ਪਾਠ ਲਈ ਲੋੜੀਂਦਾ ਹੈ - ਇਸ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸੰਕੁਚਿਤ ਕਰੋ, ਅਤੇ ਜੇਕਰ ਇਹ ਬਿਲਕੁਲ ਵੀ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਟੋਸਟ ਵਿੱਚ ਪਾਓ. ਇਹ ਇੱਕ ਹੁਕਮ ਨਾਲ, ਫਲਾਈ 'ਤੇ ਸਿੱਧਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

ALTER TABLE rawdata_orig ALTER COLUMN data SET STORAGE MAIN;

ਪ੍ਰਭਾਵ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

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

ਅਨੁਭਾਗ ਤਬਦੀਲੀਆਂ ਤੋਂ ਪਹਿਲਾਂ:

heap  = 37GB (39%)
TOAST = 54GB (57%)
PK    =  4GB ( 4%)

ਅਨੁਭਾਗ ਬਦਲਾਅ ਦੇ ਬਾਅਦ:

heap  = 37GB (67%)
TOAST = 16GB (29%)
PK    =  2GB ( 4%)

ਵਾਸਤਵ ਵਿੱਚ, ਅਸੀਂ TOAST ਨੂੰ 2 ਵਾਰ ਘੱਟ ਵਾਰ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਜਿਸ ਨੇ ਨਾ ਸਿਰਫ਼ ਡਿਸਕ, ਸਗੋਂ CPU ਨੂੰ ਵੀ ਅਨਲੋਡ ਕੀਤਾ:

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

ਕੌਣ PostgreSQL 11 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਰਹਿ ਸਕਦਾ ਹੈ

PG11 ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ TOAST ਨੂੰ "ਟਿਊਨਿੰਗ" ਜਾਰੀ ਰੱਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ ਦੇਖਿਆ ਕਿ ਇਸ ਸੰਸਕਰਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ ਪੈਰਾਮੀਟਰ ਟਿਊਨਿੰਗ ਲਈ ਉਪਲਬਧ ਹੋ ਗਿਆ ਹੈ। toast_tuple_target:

TOAST ਪ੍ਰੋਸੈਸਿੰਗ ਕੋਡ ਉਦੋਂ ਹੀ ਚਾਲੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਾਰਣੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਕਤਾਰ ਦਾ ਮੁੱਲ TOAST_TUPLE_THRESHOLD ਬਾਈਟ (ਆਮ ਤੌਰ 'ਤੇ 2 KB) ਤੋਂ ਵੱਡਾ ਹੁੰਦਾ ਹੈ। TOAST ਕੋਡ ਸੰਕੁਚਿਤ ਅਤੇ/ਜਾਂ ਫੀਲਡ ਮੁੱਲਾਂ ਨੂੰ ਸਾਰਣੀ ਤੋਂ ਬਾਹਰ ਲਿਜਾਏਗਾ ਜਦੋਂ ਤੱਕ ਕਤਾਰ ਦਾ ਮੁੱਲ TOAST_TUPLE_TARGET ਬਾਈਟ (ਵੇਰੀਏਬਲ ਮੁੱਲ, ਆਮ ਤੌਰ 'ਤੇ 2 KB) ਤੋਂ ਘੱਟ ਨਹੀਂ ਹੋ ਜਾਂਦਾ ਜਾਂ ਆਕਾਰ ਨੂੰ ਘਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ।

ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਜੋ ਡੇਟਾ ਹੁੰਦਾ ਹੈ ਉਹ ਜਾਂ ਤਾਂ "ਬਹੁਤ ਛੋਟਾ" ਜਾਂ "ਬਹੁਤ ਲੰਮਾ" ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਸੰਭਵ ਮੁੱਲ ਤੱਕ ਸੀਮਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ:

ALTER TABLE rawplan_orig SET (toast_tuple_target = 128);

ਆਓ ਦੇਖੀਏ ਕਿ ਨਵੀਂ ਸੈਟਿੰਗਾਂ ਨੇ ਮੁੜ ਸੰਰਚਨਾ ਤੋਂ ਬਾਅਦ ਡਿਸਕ ਲੋਡਿੰਗ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ:

ਭੈੜਾ ਨਹੀਂ! ਔਸਤ ਡਿਸਕ ਦੀ ਕਤਾਰ ਘਟ ਗਈ ਹੈ ਲਗਭਗ 1.5 ਗੁਣਾ, ਅਤੇ ਡਿਸਕ "ਵਿਅਸਤ" 20 ਪ੍ਰਤੀਸ਼ਤ ਹੈ! ਪਰ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਤਰ੍ਹਾਂ CPU ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰੇ?

ਘੱਟੋ-ਘੱਟ ਇਹ ਹੋਰ ਵੀ ਵਿਗੜਿਆ ਨਹੀਂ। ਹਾਲਾਂਕਿ, ਇਹ ਨਿਰਣਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਕੀ ਅਜਿਹੇ ਵਾਲੀਅਮ ਅਜੇ ਵੀ ਔਸਤ CPU ਲੋਡ ਨੂੰ ਉੱਚਾ ਨਹੀਂ ਵਧਾ ਸਕਦੇ ਹਨ 5%.

ਸ਼ਰਤਾਂ ਦੇ ਸਥਾਨਾਂ ਨੂੰ ਬਦਲਣ ਨਾਲ, ਜੋੜ... ਬਦਲਦਾ ਹੈ!

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

ਦੇ ਕਾਰਨ ਡਾਟਾ ਅਨੁਕੂਲਤਾ ਇਹ ਸਿੱਧਾ ਅੱਗੇ ਹੈ ਨਤੀਜੇ ਵਾਲੀਅਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ:

ਕਈ ਆਰਕੀਟੈਕਚਰ ਮਸ਼ੀਨ ਸ਼ਬਦਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ 'ਤੇ ਡਾਟਾ ਅਲਾਈਨਮੈਂਟ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ 32-ਬਿੱਟ x86 ਸਿਸਟਮ 'ਤੇ, ਪੂਰਨ ਅੰਕ (ਪੂਰਨ ਅੰਕ ਕਿਸਮ, 4 ਬਾਈਟ) ਨੂੰ 4-ਬਾਈਟ ਸ਼ਬਦ ਸੀਮਾ 'ਤੇ ਇਕਸਾਰ ਕੀਤਾ ਜਾਵੇਗਾ, ਜਿਵੇਂ ਕਿ ਡਬਲ ਸਟੀਕਸ਼ਨ ਫਲੋਟਿੰਗ ਪੁਆਇੰਟ ਨੰਬਰ (ਡਬਲ ਸਟੀਕਸ਼ਨ ਫਲੋਟਿੰਗ ਪੁਆਇੰਟ, 8 ਬਾਈਟ)। ਅਤੇ ਇੱਕ 64-ਬਿੱਟ ਸਿਸਟਮ 'ਤੇ, ਡਬਲ ਮੁੱਲ 8-ਬਾਈਟ ਸ਼ਬਦਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਾਲ ਇਕਸਾਰ ਹੋਣਗੇ। ਇਹ ਅਸੰਗਤਤਾ ਦਾ ਇੱਕ ਹੋਰ ਕਾਰਨ ਹੈ.

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

ਆਉ ਸਿੰਥੈਟਿਕ ਮਾਡਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ:

SELECT pg_column_size(ROW(
  '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
, '2019-01-01'::date
));
-- 48 байт

SELECT pg_column_size(ROW(
  '2019-01-01'::date
, '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
));
-- 46 байт

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

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

ਸ਼ੁਰੂਆਤੀ ਬਣਤਰ:

CREATE TABLE public.plan_20190220
(
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  dt date,
  CONSTRAINT plan_20190220_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190220_dt_check CHECK (dt = '2019-02-20'::date)
)
INHERITS (public.plan)

ਕਾਲਮ ਕ੍ਰਮ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਸੈਕਸ਼ਨ - ਬਿਲਕੁਲ ਇੱਕੋ ਖੇਤਰ, ਸਿਰਫ਼ ਵੱਖਰਾ ਕ੍ਰਮ:

CREATE TABLE public.plan_20190221
(
-- Унаследована from table plan:  dt date NOT NULL,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
  CONSTRAINT plan_20190221_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190221_dt_check CHECK (dt = '2019-02-21'::date)
)
INHERITS (public.plan)

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

ਘਟਾਓ 6% ਵਾਲੀਅਮ, ਬਹੁਤ ਵਧੀਆ!

ਪਰ ਹਰ ਚੀਜ਼, ਬੇਸ਼ਕ, ਇੰਨੀ ਗੁਲਾਬੀ ਨਹੀਂ ਹੈ - ਆਖਰਕਾਰ, ਸੂਚਕਾਂਕ ਵਿੱਚ ਅਸੀਂ ਖੇਤਰਾਂ ਦਾ ਕ੍ਰਮ ਨਹੀਂ ਬਦਲ ਸਕਦੇ, ਅਤੇ ਇਸਲਈ "ਆਮ ਤੌਰ 'ਤੇ" (pg_total_relation_size) ...

...ਅਜੇ ਵੀ ਇੱਥੇ ਹੈ 1.5% ਬਚਾਇਆਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ. ਹਾ ਹਾ!

ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਖੇਤਰਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਨ ਲਈ ਉਪਰੋਕਤ ਵਿਕਲਪ ਇਹ ਤੱਥ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਹੈ. ਕਿਉਂਕਿ ਤੁਸੀਂ ਸੁਹਜ ਦੇ ਕਾਰਨਾਂ ਕਰਕੇ ਖੇਤਰਾਂ ਦੇ ਕੁਝ ਬਲਾਕਾਂ ਨੂੰ "ਫਾੜਨਾ" ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ - ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਜੋੜਾ (pack, recno), ਜੋ ਕਿ ਇਸ ਸਾਰਣੀ ਲਈ PK ਹੈ।

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

ਸਰੋਤ: www.habr.com