PostgreSQL ನಲ್ಲಿ ದೊಡ್ಡ ಸಂಪುಟಗಳಲ್ಲಿ ಒಂದು ಪೈಸೆ ಉಳಿಸಿ

ಸಂಗ್ರಹಿಸಿದ ದೊಡ್ಡ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವ ವಿಷಯವನ್ನು ಮುಂದುವರಿಸುವುದು ವಿಭಜನೆಯ ಬಗ್ಗೆ ಹಿಂದಿನ ಲೇಖನ, ಇದರಲ್ಲಿ ನೀವು ಮಾಡಬಹುದಾದ ಮಾರ್ಗಗಳನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ ಸಂಗ್ರಹಿಸಿದ "ಭೌತಿಕ" ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡಿ PostgreSQL ನಲ್ಲಿ, ಮತ್ತು ಸರ್ವರ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಅವುಗಳ ಪ್ರಭಾವ.

ನಾವು ಮಾತನಾಡುತ್ತೇವೆ TOAST ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ಜೋಡಣೆ. "ಸರಾಸರಿಯಾಗಿ," ಈ ವಿಧಾನಗಳು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸದೆಯೇ.

ಆದಾಗ್ಯೂ, ನಮ್ಮ ಅನುಭವವು ಈ ವಿಷಯದಲ್ಲಿ ಬಹಳ ಉತ್ಪಾದಕವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದರ ಸ್ವಭಾವದಿಂದ ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣೆಯ ಸಂಗ್ರಹಣೆಯು ಇರುತ್ತದೆ ಹೆಚ್ಚಾಗಿ ಅನುಬಂಧ-ಮಾತ್ರ ದಾಖಲಾದ ಡೇಟಾದ ವಿಷಯದಲ್ಲಿ. ಮತ್ತು ಬದಲಿಗೆ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲು ಡೇಟಾಬೇಸ್ ಅನ್ನು ನೀವು ಹೇಗೆ ಕಲಿಸಬಹುದು ಎಂದು ನೀವು ಆಶ್ಚರ್ಯ ಪಡುತ್ತಿದ್ದರೆ 200MB / s ಅರ್ಧದಷ್ಟು - ದಯವಿಟ್ಟು ಬೆಕ್ಕಿನ ಕೆಳಗೆ.

ದೊಡ್ಡ ಡೇಟಾದ ಸಣ್ಣ ರಹಸ್ಯಗಳು

ಉದ್ಯೋಗ ಪ್ರೊಫೈಲ್ ಮೂಲಕ ನಮ್ಮ ಸೇವೆ, ಅವರು ನಿಯಮಿತವಾಗಿ ಕೊಟ್ಟಿಗೆಗಳಿಂದ ಅವನಿಗೆ ಹಾರುತ್ತಾರೆ ಪಠ್ಯ ಪ್ಯಾಕೇಜುಗಳು.

ಮತ್ತು ಅಂದಿನಿಂದ VLSI ಸಂಕೀರ್ಣನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಡೇಟಾಬೇಸ್ ಸಂಕೀರ್ಣ ಡೇಟಾ ರಚನೆಗಳೊಂದಿಗೆ ಬಹು-ಘಟಕ ಉತ್ಪನ್ನವಾಗಿದೆ, ನಂತರ ಪ್ರಶ್ನೆಗಳು ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಈ ರೀತಿ ತಿರುಗಿ ಸಂಕೀರ್ಣ ಅಲ್ಗಾರಿದಮಿಕ್ ತರ್ಕದೊಂದಿಗೆ "ಮಲ್ಟಿ-ವಾಲ್ಯೂಮ್". ಆದ್ದರಿಂದ ನಮಗೆ ಬರುವ ಲಾಗ್‌ನಲ್ಲಿ ವಿನಂತಿಯ ಪ್ರತಿಯೊಂದು ವೈಯಕ್ತಿಕ ನಿದರ್ಶನದ ಪರಿಮಾಣ ಅಥವಾ ಅದರ ಪರಿಣಾಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಯೋಜನೆಯು "ಸರಾಸರಿ" ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ.

ನಾವು "ಕಚ್ಚಾ" ಡೇಟಾವನ್ನು ಬರೆಯುವ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಒಂದರ ರಚನೆಯನ್ನು ನೋಡೋಣ - ಅಂದರೆ, ಲಾಗ್ ಪ್ರವೇಶದಿಂದ ಮೂಲ ಪಠ್ಯ ಇಲ್ಲಿದೆ:

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

ಒಂದು ವಿಶಿಷ್ಟ ಚಿಹ್ನೆ (ಈಗಾಗಲೇ ವಿಭಾಗಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಇದು ವಿಭಾಗ ಟೆಂಪ್ಲೇಟ್ ಆಗಿದೆ), ಅಲ್ಲಿ ಪ್ರಮುಖ ವಿಷಯ ಪಠ್ಯವಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ.

PG ಯಲ್ಲಿನ ಒಂದು ದಾಖಲೆಯ "ಭೌತಿಕ" ಗಾತ್ರವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಪುಟದ ಡೇಟಾವನ್ನು ಆಕ್ರಮಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೆನಪಿಸಿಕೊಳ್ಳಿ, ಆದರೆ "ತಾರ್ಕಿಕ" ಗಾತ್ರವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಷಯವಾಗಿದೆ. ಒಂದು ಕ್ಷೇತ್ರಕ್ಕೆ ವಾಲ್ಯೂಮೆಟ್ರಿಕ್ ಮೌಲ್ಯವನ್ನು (ವರ್ಚಾರ್/ಪಠ್ಯ/ಬೈಟಿಯಾ) ಬರೆಯಲು, ಬಳಸಿ TOAST ತಂತ್ರಜ್ಞಾನ:

PostgreSQL ಸ್ಥಿರ ಪುಟದ ಗಾತ್ರವನ್ನು ಬಳಸುತ್ತದೆ (ಸಾಮಾನ್ಯವಾಗಿ 8 KB), ಮತ್ತು tuples ಬಹು ಪುಟಗಳನ್ನು ವ್ಯಾಪಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ದೊಡ್ಡ ಕ್ಷೇತ್ರ ಮೌಲ್ಯಗಳನ್ನು ನೇರವಾಗಿ ಸಂಗ್ರಹಿಸುವುದು ಅಸಾಧ್ಯ. ಈ ಮಿತಿಯನ್ನು ನಿವಾರಿಸಲು, ದೊಡ್ಡ ಕ್ಷೇತ್ರ ಮೌಲ್ಯಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು/ಅಥವಾ ಬಹು ಭೌತಿಕ ರೇಖೆಗಳಲ್ಲಿ ವಿಭಜಿಸಲಾಗುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರಿಂದ ಗಮನಿಸದೆ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸರ್ವರ್ ಕೋಡ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಈ ವಿಧಾನವನ್ನು TOAST ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ...

ವಾಸ್ತವವಾಗಿ, "ಸಂಭಾವ್ಯವಾಗಿ ದೊಡ್ಡ" ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಪ್ರತಿ ಟೇಬಲ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ "ಸ್ಲೈಸಿಂಗ್" ನೊಂದಿಗೆ ಜೋಡಿಯಾಗಿರುವ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ 2KB ವಿಭಾಗಗಳಲ್ಲಿ ಪ್ರತಿ "ದೊಡ್ಡ" ದಾಖಲೆ:

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

ಅಂದರೆ, ನಾವು "ದೊಡ್ಡ" ಮೌಲ್ಯದೊಂದಿಗೆ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಬರೆಯಬೇಕಾದರೆ data, ನಂತರ ನಿಜವಾದ ರೆಕಾರ್ಡಿಂಗ್ ಸಂಭವಿಸುತ್ತದೆ ಮುಖ್ಯ ಟೇಬಲ್ ಮತ್ತು ಅದರ PK ಗೆ ಮಾತ್ರವಲ್ಲದೆ TOAST ಮತ್ತು ಅದರ PK ಗೂ ಸಹ.

TOAST ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆಗೊಳಿಸುವುದು

ಆದರೆ ನಮ್ಮ ಹೆಚ್ಚಿನ ದಾಖಲೆಗಳು ಇನ್ನೂ ದೊಡ್ಡದಾಗಿಲ್ಲ, 8KB ಗೆ ಹೊಂದಿಕೊಳ್ಳಬೇಕು - ನಾನು ಇದರಲ್ಲಿ ಹಣವನ್ನು ಹೇಗೆ ಉಳಿಸಬಹುದು? ..

ಇಲ್ಲಿಯೇ ಗುಣಲಕ್ಷಣವು ನಮ್ಮ ಸಹಾಯಕ್ಕೆ ಬರುತ್ತದೆ STORAGE ಟೇಬಲ್ ಕಾಲಂನಲ್ಲಿ:

• ವಿಸ್ತರಿಸಲಾಗಿದೆ ಸಂಕೋಚನ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಣೆ ಎರಡನ್ನೂ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಪ್ರಮಾಣಿತ ಆಯ್ಕೆ ಹೆಚ್ಚಿನ TOAST ಕಂಪ್ಲೈಂಟ್ ಡೇಟಾ ಪ್ರಕಾರಗಳಿಗೆ. ಇದು ಮೊದಲು ಸಂಕೋಚನವನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ನಂತರ ಸಾಲು ಇನ್ನೂ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಅದನ್ನು ಮೇಜಿನ ಹೊರಗೆ ಸಂಗ್ರಹಿಸುತ್ತದೆ.
• ಮುಖ್ಯ ಸಂಕೋಚನವನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಆದರೆ ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಣೆಯಲ್ಲ. (ವಾಸ್ತವವಾಗಿ, ಅಂತಹ ಕಾಲಮ್‌ಗಳಿಗಾಗಿ ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಣೆಯನ್ನು ಇನ್ನೂ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಮಾತ್ರ ಕೊನೆಯ ಉಪಾಯವಾಗಿ, ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಕುಗ್ಗಿಸಲು ಬೇರೆ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದಾಗ ಅದು ಪುಟಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.)

ವಾಸ್ತವವಾಗಿ, ಪಠ್ಯಕ್ಕಾಗಿ ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಇದೇ - ಅದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕುಗ್ಗಿಸಿ, ಮತ್ತು ಅದು ಸರಿಹೊಂದದಿದ್ದರೆ, ಅದನ್ನು 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_TUPLE_THRESHOLD ಬೈಟ್‌ಗಳಿಗಿಂತ (ಸಾಮಾನ್ಯವಾಗಿ 2 KB) ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮಾತ್ರ TOAST ಸಂಸ್ಕರಣಾ ಕೋಡ್ ಫೈರ್ ಆಗುತ್ತದೆ. ಸಾಲು ಮೌಲ್ಯವು TOAST_TUPLE_TARGET ಬೈಟ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆಯಾಗುವವರೆಗೆ (ವೇರಿಯಬಲ್ ಮೌಲ್ಯ, ಸಾಮಾನ್ಯವಾಗಿ 2 KB) ಅಥವಾ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗದವರೆಗೆ TOAST ಕೋಡ್ ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು/ಅಥವಾ ಕ್ಷೇತ್ರ ಮೌಲ್ಯಗಳನ್ನು ಟೇಬಲ್‌ನಿಂದ ಹೊರಕ್ಕೆ ಸರಿಸುತ್ತದೆ.

ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಹೊಂದಿರುವ ಡೇಟಾವು "ತುಂಬಾ ಚಿಕ್ಕದು" ಅಥವಾ "ಬಹಳ ಉದ್ದವಾಗಿದೆ" ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಕನಿಷ್ಟ ಸಂಭವನೀಯ ಮೌಲ್ಯಕ್ಕೆ ನಮ್ಮನ್ನು ಮಿತಿಗೊಳಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ:

ALTER TABLE rawplan_orig SET (toast_tuple_target = 128);

ಮರುಸಂರಚನೆಯ ನಂತರ ಹೊಸ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಡಿಸ್ಕ್ ಲೋಡಿಂಗ್ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ:

ಕೆಟ್ಟದ್ದಲ್ಲ! ಸರಾಸರಿ ಡಿಸ್ಕ್‌ಗೆ ಕ್ಯೂ ಕಡಿಮೆಯಾಗಿದೆ ಸರಿಸುಮಾರು 1.5 ಬಾರಿ, ಮತ್ತು ಡಿಸ್ಕ್ "ಬ್ಯುಸಿ" 20 ಪ್ರತಿಶತ! ಆದರೆ ಇದು ಹೇಗಾದರೂ CPU ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದೇ?

ಕನಿಷ್ಠ ಅದು ಕೆಟ್ಟದಾಗಲಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಅಂತಹ ಸಂಪುಟಗಳು ಇನ್ನೂ ಸರಾಸರಿ CPU ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ನಿರ್ಣಯಿಸುವುದು ಕಷ್ಟ 5%.

ನಿಯಮಗಳ ಸ್ಥಳಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ, ಮೊತ್ತವು... ಬದಲಾಗುತ್ತದೆ!

ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಒಂದು ಪೆನ್ನಿಯು ರೂಬಲ್ ಅನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಶೇಖರಣಾ ಸಂಪುಟಗಳೊಂದಿಗೆ ಅದು ಸುಮಾರು 10TB/ತಿಂಗಳು ಸ್ವಲ್ಪ ಆಪ್ಟಿಮೈಸೇಶನ್ ಕೂಡ ಉತ್ತಮ ಲಾಭವನ್ನು ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಮ್ಮ ಡೇಟಾದ ಭೌತಿಕ ರಚನೆಗೆ ನಾವು ಗಮನ ನೀಡಿದ್ದೇವೆ - ಎಷ್ಟು ನಿಖರವಾಗಿ ದಾಖಲೆಯ ಒಳಗೆ "ಸ್ಟ್ಯಾಕ್ ಮಾಡಿದ" ಕ್ಷೇತ್ರಗಳು ಪ್ರತಿಯೊಂದು ಕೋಷ್ಟಕಗಳು.

ಏಕೆಂದರೆ ಏಕೆಂದರೆ ಡೇಟಾ ಜೋಡಣೆ ಇದು ನೇರವಾಗಿ ಮುಂದಿದೆ ಪರಿಣಾಮವಾಗಿ ಪರಿಮಾಣದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ:

ಅನೇಕ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಯಂತ್ರ ಪದದ ಗಡಿಗಳ ಮೇಲೆ ಡೇಟಾ ಜೋಡಣೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, 32-ಬಿಟ್ x86 ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ, ಪೂರ್ಣಾಂಕಗಳನ್ನು (ಪೂರ್ಣಾಂಕ ಪ್ರಕಾರ, 4 ಬೈಟ್‌ಗಳು) 4-ಬೈಟ್ ಪದದ ಗಡಿಯಲ್ಲಿ ಜೋಡಿಸಲಾಗುತ್ತದೆ, ಹಾಗೆಯೇ ಡಬಲ್ ನಿಖರವಾದ ಫ್ಲೋಟಿಂಗ್ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆಗಳು (ಡಬಲ್ ಪ್ರಿಸಿಶನ್ ಫ್ಲೋಟಿಂಗ್ ಪಾಯಿಂಟ್, 8 ಬೈಟ್‌ಗಳು). ಮತ್ತು 64-ಬಿಟ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ, ಡಬಲ್ ಮೌಲ್ಯಗಳನ್ನು 8-ಬೈಟ್ ಪದದ ಗಡಿಗಳಿಗೆ ಜೋಡಿಸಲಾಗುತ್ತದೆ. ಇದು ಅಸಾಮರಸ್ಯಕ್ಕೆ ಮತ್ತೊಂದು ಕಾರಣವಾಗಿದೆ.

ಜೋಡಣೆಯ ಕಾರಣದಿಂದಾಗಿ, ಟೇಬಲ್ ಸಾಲಿನ ಗಾತ್ರವು ಕ್ಷೇತ್ರಗಳ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಈ ಪರಿಣಾಮವು ತುಂಬಾ ಗಮನಿಸುವುದಿಲ್ಲ, ಆದರೆ ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಗಾತ್ರದಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೀವು ಚಾರ್(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