PostgreSQL ನಲ್ಲಿ EAV ಅನ್ನು JSONB ನೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತಿದೆ

ಟಿಎಲ್; DR: JSONB ಪ್ರಶ್ನೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತ್ಯಾಗ ಮಾಡದೆಯೇ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.

ಪರಿಚಯ

ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್ (ಡೇಟಾಬೇಸ್) ಪ್ರಪಂಚದ ಅತ್ಯಂತ ಹಳೆಯ ಬಳಕೆಯ ಪ್ರಕರಣಗಳ ಒಂದು ಶ್ರೇಷ್ಠ ಉದಾಹರಣೆಯನ್ನು ನೀಡೋಣ: ನಾವು ಒಂದು ಘಟಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಈ ಘಟಕದ ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳನ್ನು (ಗುಣಲಕ್ಷಣಗಳನ್ನು) ಉಳಿಸಬೇಕಾಗಿದೆ. ಆದರೆ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ಒಂದೇ ರೀತಿಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸೇರಿಸಬಹುದು.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ ಪ್ರತಿ ಆಸ್ತಿ ಮೌಲ್ಯಕ್ಕಾಗಿ ಡೇಟಾಬೇಸ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಕಾಲಮ್ ಅನ್ನು ರಚಿಸುವುದು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಘಟಕದ ನಿದರ್ಶನಕ್ಕೆ ಅಗತ್ಯವಿರುವದನ್ನು ಸರಳವಾಗಿ ಭರ್ತಿ ಮಾಡುವುದು. ಗ್ರೇಟ್! ನಿಮ್ಮ ಟೇಬಲ್ ಲಕ್ಷಾಂತರ ದಾಖಲೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವವರೆಗೆ ಮತ್ತು ನೀವು ಹೊಸ ದಾಖಲೆಯನ್ನು ಸೇರಿಸುವವರೆಗೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ.

EAV ಮಾದರಿಯನ್ನು ಪರಿಗಣಿಸಿ (ಅಸ್ತಿತ್ವ-ಗುಣಲಕ್ಷಣ-ಮೌಲ್ಯ), ಇದು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುತ್ತದೆ. ಒಂದು ಕೋಷ್ಟಕವು ಘಟಕಗಳನ್ನು (ದಾಖಲೆಗಳು) ಒಳಗೊಂಡಿದೆ, ಇನ್ನೊಂದು ಕೋಷ್ಟಕವು ಆಸ್ತಿ ಹೆಸರುಗಳನ್ನು (ಗುಣಲಕ್ಷಣಗಳನ್ನು) ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಮೂರನೇ ಕೋಷ್ಟಕವು ಘಟಕಗಳನ್ನು ಅವುಗಳ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಘಟಕಕ್ಕೆ ಆ ಗುಣಲಕ್ಷಣಗಳ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇದು ವಿಭಿನ್ನ ವಸ್ತುಗಳಿಗೆ ವಿಭಿನ್ನ ಸೆಟ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ರಚನೆಯನ್ನು ಬದಲಾಯಿಸದೆ ಫ್ಲೈನಲ್ಲಿ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಆದಾಗ್ಯೂ, EVA ವಿಧಾನಕ್ಕೆ ಕೆಲವು ತೊಂದರೆಗಳಿಲ್ಲದಿದ್ದರೆ ನಾನು ಈ ಪೋಸ್ಟ್ ಅನ್ನು ಬರೆಯುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, ಪ್ರತಿಯೊಂದೂ 1 ಗುಣಲಕ್ಷಣವನ್ನು ಹೊಂದಿರುವ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಘಟಕಗಳನ್ನು ಪಡೆಯಲು, ಪ್ರಶ್ನೆಯಲ್ಲಿ 2 ಸೇರ್ಪಡೆಗಳು ಅಗತ್ಯವಿದೆ: ಮೊದಲನೆಯದು ಗುಣಲಕ್ಷಣ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಸೇರ್ಪಡೆಯಾಗಿದೆ, ಎರಡನೆಯದು ಮೌಲ್ಯಗಳ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಸೇರ್ಪಡೆಯಾಗಿದೆ. ಒಂದು ಘಟಕವು 2 ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ 4 ಸೇರ್ಪಡೆಗಳ ಅಗತ್ಯವಿದೆ! ಹೆಚ್ಚುವರಿಯಾಗಿ, ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಟ್ರಿಂಗ್‌ಗಳಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಇದು ಫಲಿತಾಂಶ ಮತ್ತು WHERE ಷರತ್ತು ಎರಡಕ್ಕೂ ಟೈಪ್ ಕ್ಯಾಸ್ಟಿಂಗ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನೀವು ಬಹಳಷ್ಟು ಪ್ರಶ್ನೆಗಳನ್ನು ಬರೆದರೆ, ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ವಿಷಯದಲ್ಲಿ ಇದು ಸಾಕಷ್ಟು ವ್ಯರ್ಥವಾಗುತ್ತದೆ.

ಈ ಸ್ಪಷ್ಟ ನ್ಯೂನತೆಗಳ ಹೊರತಾಗಿಯೂ, ಈ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು EAV ಅನ್ನು ದೀರ್ಘಕಾಲ ಬಳಸಲಾಗಿದೆ. ಇವು ಅನಿವಾರ್ಯ ನ್ಯೂನತೆಗಳು, ಮತ್ತು ಸರಳವಾಗಿ ಉತ್ತಮ ಪರ್ಯಾಯ ಇರಲಿಲ್ಲ.
ಆದರೆ ನಂತರ PostgreSQL ನಲ್ಲಿ ಹೊಸ "ತಂತ್ರಜ್ಞಾನ" ಕಾಣಿಸಿಕೊಂಡಿತು...

PostgreSQL 9.4 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ, JSON ಬೈನರಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು JSONB ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಈ ಸ್ವರೂಪದಲ್ಲಿ JSON ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸರಳ ಪಠ್ಯ JSON ಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸ್ಥಳ ಮತ್ತು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದರ ಮೇಲೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ. JSONB ಇಂಡೆಕ್ಸಿಂಗ್ ಅನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದು ಪ್ರಶ್ನೆಗಳನ್ನು ಇನ್ನಷ್ಟು ವೇಗಗೊಳಿಸುತ್ತದೆ.

JSONB ಡೇಟಾ ಪ್ರಕಾರವು ನಮ್ಮ ಘಟಕದ ಕೋಷ್ಟಕಕ್ಕೆ ಕೇವಲ ಒಂದು JSONB ಕಾಲಮ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ತೊಡಕಿನ EAV ಮಾದರಿಯನ್ನು ಬದಲಾಯಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಉತ್ಪಾದಕತೆಯ ಇಳಿಕೆಯೊಂದಿಗೆ ಇರಬೇಕು ಎಂದು ಹಲವರು ವಾದಿಸುತ್ತಾರೆ ... ಅದಕ್ಕಾಗಿಯೇ ನಾನು ಈ ಲೇಖನವನ್ನು ಬರೆದಿದ್ದೇನೆ.

ಪರೀಕ್ಷಾ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ

ಈ ಹೋಲಿಕೆಗಾಗಿ, ನಾನು $9.5 ಬಿಲ್ಡ್‌ನಲ್ಲಿ PostgreSQL 80 ನ ಹೊಸ ಸ್ಥಾಪನೆಯಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸಿದೆ ಡಿಜಿಟಲ್ಓಶನ್ Ubuntu 14.04 postgresql.conf ನಲ್ಲಿ ಕೆಲವು ನಿಯತಾಂಕಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನಂತರ ನಾನು ಓಡಿದೆ ಇದು psql ಬಳಸಿ ಸ್ಕ್ರಿಪ್ಟ್. EAV ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ಕೆಳಗಿನ ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ:

CREATE TABLE entity ( 
  id           SERIAL PRIMARY KEY, 
  name         TEXT, 
  description  TEXT
);
CREATE TABLE entity_attribute (
  id          SERIAL PRIMARY KEY, 
  name        TEXT
);
CREATE TABLE entity_attribute_value (
  id                  SERIAL PRIMARY KEY, 
  entity_id           INT    REFERENCES entity(id), 
  entity_attribute_id INT    REFERENCES entity_attribute(id), 
  value               TEXT
);

ಅದೇ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಟೇಬಲ್ ಕೆಳಗೆ ಇದೆ, ಆದರೆ JSONB ಪ್ರಕಾರದ ಕಾಲಮ್‌ನಲ್ಲಿ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ - ಗುಣಗಳು.

CREATE TABLE entity_jsonb (
  id          SERIAL PRIMARY KEY, 
  name        TEXT, 
  description TEXT,
  properties  JSONB
);

ಇದು ತುಂಬಾ ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ, ಅಲ್ಲವೇ? ನಂತರ ಅದನ್ನು ಘಟಕದ ಕೋಷ್ಟಕಗಳಿಗೆ ಸೇರಿಸಲಾಯಿತು (ಅಸ್ತಿತ್ವ & entity_jsonb) 10 ಮಿಲಿಯನ್ ದಾಖಲೆಗಳು, ಮತ್ತು ಅದರ ಪ್ರಕಾರ, EAV ಪ್ಯಾಟರ್ನ್ ಮತ್ತು JSONB ಕಾಲಮ್‌ನ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಟೇಬಲ್ ಅನ್ನು ಅದೇ ಡೇಟಾದಿಂದ ತುಂಬಿಸಲಾಗಿದೆ - entity_jsonb.properties. ಹೀಗಾಗಿ, ನಾವು ಸಂಪೂರ್ಣ ಗುಣಲಕ್ಷಣಗಳ ಗುಂಪಿನಲ್ಲಿ ಹಲವಾರು ವಿಭಿನ್ನ ಡೇಟಾ ಪ್ರಕಾರಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆ ಡೇಟಾ:

{
  id:          1
  name:        "Entity1"
  description: "Test entity no. 1"
  properties:  {
    color:        "red"
    lenght:       120
    width:        3.1882420
    hassomething: true
    country:      "Belgium"
  } 
}

ಆದ್ದರಿಂದ ಈಗ ನಾವು ಎರಡೂ ಆಯ್ಕೆಗಳಿಗೆ ಒಂದೇ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕೆಲಸದಲ್ಲಿ ಅನುಷ್ಠಾನಗಳನ್ನು ಹೋಲಿಸಲು ಪ್ರಾರಂಭಿಸೋಣ!

ನಿಮ್ಮ ವಿನ್ಯಾಸವನ್ನು ಸರಳಗೊಳಿಸಿ

ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಹಿಂದೆ ಹೇಳಲಾಗಿದೆ: EAV ಗಾಗಿ ಮೂರು ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸುವ ಬದಲು ಗುಣಲಕ್ಷಣಗಳಿಗಾಗಿ JSONB ಕಾಲಮ್ ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ಒಂದು ಟೇಬಲ್. ಆದರೆ ಇದು ವಿನಂತಿಗಳಲ್ಲಿ ಹೇಗೆ ಪ್ರತಿಫಲಿಸುತ್ತದೆ? ಒಂದು ಘಟಕದ ಆಸ್ತಿಯನ್ನು ನವೀಕರಿಸುವುದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

-- EAV
UPDATE entity_attribute_value 
SET value = 'blue' 
WHERE entity_attribute_id = 1 
  AND entity_id = 120;

-- JSONB
UPDATE entity_jsonb 
SET properties = jsonb_set(properties, '{"color"}', '"blue"') 
WHERE id = 120;

ನೀವು ನೋಡುವಂತೆ, ಕೊನೆಯ ವಿನಂತಿಯು ಸರಳವಾಗಿ ಕಾಣುತ್ತಿಲ್ಲ. JSONB ವಸ್ತುವಿನಲ್ಲಿ ಆಸ್ತಿಯ ಮೌಲ್ಯವನ್ನು ನವೀಕರಿಸಲು ನಾವು ಕಾರ್ಯವನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ jsonb_set(), ಮತ್ತು ನಮ್ಮ ಹೊಸ ಮೌಲ್ಯವನ್ನು JSONB ಆಬ್ಜೆಕ್ಟ್ ಆಗಿ ರವಾನಿಸಬೇಕು. ಆದಾಗ್ಯೂ, ನಾವು ಯಾವುದೇ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಮುಂಚಿತವಾಗಿ ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ. EAV ಉದಾಹರಣೆಯನ್ನು ನೋಡುವಾಗ, ನವೀಕರಣವನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು entity_id ಮತ್ತು entity_attribute_id ಎರಡನ್ನೂ ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ವಸ್ತುವಿನ ಹೆಸರನ್ನು ಆಧರಿಸಿ JSONB ಕಾಲಮ್‌ನಲ್ಲಿ ಆಸ್ತಿಯನ್ನು ನವೀಕರಿಸಲು ನೀವು ಬಯಸಿದರೆ, ನಂತರ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ.

ಈಗ ಅದರ ಹೊಸ ಬಣ್ಣವನ್ನು ಆಧರಿಸಿ ನಾವು ನವೀಕರಿಸಿದ ಘಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡೋಣ:

-- EAV
SELECT e.name 
FROM entity e 
  INNER JOIN entity_attribute_value eav ON e.id = eav.entity_id
  INNER JOIN entity_attribute ea ON eav.entity_attribute_id = ea.id
WHERE ea.name = 'color' AND eav.value = 'blue';

-- JSONB
SELECT name 
FROM entity_jsonb 
WHERE properties ->> 'color' = 'blue';

ಎರಡನೆಯದು ಚಿಕ್ಕದಾಗಿದೆ (ಸೇರುವುದಿಲ್ಲ!) ಮತ್ತು ಆದ್ದರಿಂದ ಹೆಚ್ಚು ಓದಬಲ್ಲದು ಎಂದು ನಾವು ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. JSONB ಇಲ್ಲಿ ಗೆಲ್ಲುತ್ತದೆ! JSONB ಆಬ್ಜೆಕ್ಟ್‌ನಿಂದ ಬಣ್ಣವನ್ನು ಪಠ್ಯ ಮೌಲ್ಯವಾಗಿ ಪಡೆಯಲು ನಾವು JSON ->> ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. @> ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು JSONB ಮಾದರಿಯಲ್ಲಿ ಅದೇ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಲು ಎರಡನೇ ಮಾರ್ಗವಿದೆ:

-- JSONB 
SELECT name 
FROM entity_jsonb 
WHERE properties @> '{"color": "blue"}';

ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ: ಅದರ ಗುಣಲಕ್ಷಣಗಳ ಕಾಲಮ್‌ನಲ್ಲಿರುವ JSON ಆಬ್ಜೆಕ್ಟ್ @> ಆಪರೇಟರ್‌ನ ಬಲಭಾಗದಲ್ಲಿರುವ ವಸ್ತುವನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಕಡಿಮೆ ಓದಬಲ್ಲ, ಹೆಚ್ಚು ಉತ್ಪಾದಕ (ಕೆಳಗೆ ನೋಡಿ).

ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಬಹು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಆಯ್ಕೆಮಾಡಬೇಕಾದಾಗ JSONB ಅನ್ನು ಇನ್ನಷ್ಟು ಸುಲಭಗೊಳಿಸೋಣ. ಇಲ್ಲಿ JSONB ವಿಧಾನವು ನಿಜವಾಗಿಯೂ ಬರುತ್ತದೆ: ಸೇರ್ಪಡೆಗಳ ಅಗತ್ಯವಿಲ್ಲದೆಯೇ ನಮ್ಮ ಫಲಿತಾಂಶ ಸೆಟ್‌ನಲ್ಲಿ ನಾವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೆಚ್ಚುವರಿ ಕಾಲಮ್‌ಗಳಾಗಿ ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ:

-- JSONB 
SELECT name
  , properties ->> 'color'
  , properties ->> 'country'
FROM entity_jsonb 
WHERE id = 120;

EAV ಯೊಂದಿಗೆ ನೀವು ಪ್ರಶ್ನಿಸಲು ಬಯಸುವ ಪ್ರತಿಯೊಂದು ಆಸ್ತಿಗೆ 2 ಸೇರ್ಪಡೆಗಳ ಅಗತ್ಯವಿದೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಮೇಲಿನ ಪ್ರಶ್ನೆಗಳು ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸದಲ್ಲಿ ಉತ್ತಮವಾದ ಸರಳೀಕರಣವನ್ನು ತೋರಿಸುತ್ತವೆ. JSONB ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡಿ ಇದು ಪೋಸ್ಟ್.
ಈಗ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವ ಸಮಯ ಬಂದಿದೆ.

ಉತ್ಪಾದಕತೆ

ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೋಲಿಸಲು ನಾನು ಬಳಸಿದ್ದೇನೆ ವಿವರಿಸಿ ವಿಶ್ಲೇಷಿಸಿ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ, ಮರಣದಂಡನೆಯ ಸಮಯವನ್ನು ಲೆಕ್ಕಹಾಕಲು. ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ಕನಿಷ್ಠ ಮೂರು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ ಪ್ರಶ್ನೆ ಯೋಜಕವು ಮೊದಲ ಬಾರಿಗೆ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮೊದಲಿಗೆ ನಾನು ಯಾವುದೇ ಸೂಚಿಕೆಗಳಿಲ್ಲದೆ ಪ್ರಶ್ನೆಗಳನ್ನು ನಡೆಸಿದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಇದು JSONB ಯ ಪ್ರಯೋಜನವಾಗಿದೆ, ಏಕೆಂದರೆ EAV ಗೆ ಅಗತ್ಯವಿರುವ ಸೇರ್ಪಡೆಗಳು ಸೂಚ್ಯಂಕಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ (ವಿದೇಶಿ ಪ್ರಮುಖ ಕ್ಷೇತ್ರಗಳನ್ನು ಸೂಚಿಕೆ ಮಾಡಲಾಗಿಲ್ಲ). ಇದರ ನಂತರ ನಾನು EAV ಮೌಲ್ಯದ ಕೋಷ್ಟಕದ 2 ವಿದೇಶಿ ಕೀ ಕಾಲಮ್‌ಗಳಲ್ಲಿ ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸಿದೆ, ಜೊತೆಗೆ ಒಂದು ಸೂಚ್ಯಂಕ ಜಿನ್ JSONB ಕಾಲಮ್‌ಗಾಗಿ.

ಡೇಟಾ ಅಪ್‌ಡೇಟ್ ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶಗಳನ್ನು ಸಮಯದ ಪರಿಭಾಷೆಯಲ್ಲಿ ತೋರಿಸಿದೆ (ಎಂಎಸ್‌ನಲ್ಲಿ). ಪ್ರಮಾಣವು ಲಾಗರಿಥಮಿಕ್ ಆಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ:

ಮೇಲೆ ತಿಳಿಸಿದ ಕಾರಣಕ್ಕಾಗಿ ನೀವು ಸೂಚ್ಯಂಕಗಳನ್ನು ಬಳಸದಿದ್ದರೆ JSONB EAV ಗಿಂತ ಹೆಚ್ಚು (> 50000-x) ವೇಗವಾಗಿರುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ನಾವು ಪ್ರಾಥಮಿಕ ಕೀಲಿಗಳೊಂದಿಗೆ ಕಾಲಮ್‌ಗಳನ್ನು ಸೂಚಿಸಿದಾಗ, ವ್ಯತ್ಯಾಸವು ಬಹುತೇಕ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ, ಆದರೆ JSONB ಇನ್ನೂ EAV ಗಿಂತ 1,3 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ. ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾನದಂಡದಲ್ಲಿ ಆಸ್ತಿ ಕಾಲಮ್ ಅನ್ನು ಬಳಸದ ಕಾರಣ JSONB ಕಾಲಮ್‌ನಲ್ಲಿನ ಸೂಚ್ಯಂಕವು ಇಲ್ಲಿ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಆಸ್ತಿ ಮೌಲ್ಯದ ಆಧಾರದ ಮೇಲೆ ಡೇಟಾವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು, ನಾವು ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ (ಸಾಮಾನ್ಯ ಪ್ರಮಾಣ):

JSONB ಮತ್ತೆ ಇಂಡೆಕ್ಸ್‌ಗಳಿಲ್ಲದೆ EAV ಗಿಂತ ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಗಮನಿಸಬಹುದು, ಆದರೆ EAV ಸೂಚಿಕೆಗಳೊಂದಿಗೆ, ಅದು ಇನ್ನೂ JSONB ಗಿಂತ ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ JSONB ಪ್ರಶ್ನೆಗಳ ಸಮಯವು ಒಂದೇ ಆಗಿರುವುದನ್ನು ನಾನು ನೋಡಿದೆ, ಇದು GIN ಸೂಚಿಕೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂಬ ಅಂಶಕ್ಕೆ ನನ್ನನ್ನು ಪ್ರೇರೇಪಿಸಿತು. ಜನಸಂಖ್ಯೆಯ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಕಾಲಮ್‌ನಲ್ಲಿ ನೀವು ಜಿಐಎನ್ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಬಳಸಿದಾಗ, ಆಯೋಜಕರು @> ಅನ್ನು ಒಳಗೊಂಡಿರುವಾಗ ಮಾತ್ರ ಅದು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ನಾನು ಇದನ್ನು ಹೊಸ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಬಳಸಿದ್ದೇನೆ ಮತ್ತು ಇದು ಸಮಯದ ಮೇಲೆ ಭಾರಿ ಪರಿಣಾಮ ಬೀರಿದೆ: ಕೇವಲ 0,153ms! ಇದು EAV ಗಿಂತ 15000 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ ಮತ್ತು ->> ಆಪರೇಟರ್‌ಗಿಂತ 25000 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ.

ಇದು ಸಾಕಷ್ಟು ವೇಗವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ!

ಡೇಟಾಬೇಸ್ ಟೇಬಲ್ ಗಾತ್ರ

ಎರಡೂ ವಿಧಾನಗಳಿಗಾಗಿ ಟೇಬಲ್ ಗಾತ್ರಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡೋಣ. psql ನಲ್ಲಿ ನಾವು ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಸೂಚಿಕೆಗಳ ಗಾತ್ರವನ್ನು ತೋರಿಸಬಹುದು dti+

EAV ವಿಧಾನಕ್ಕಾಗಿ, ಟೇಬಲ್ ಗಾತ್ರಗಳು ಸುಮಾರು 3068 MB ಮತ್ತು ಒಟ್ಟು 3427 GB ವರೆಗೆ 6,43 MB ವರೆಗಿನ ಸೂಚ್ಯಂಕಗಳು. JSONB ವಿಧಾನವು ಟೇಬಲ್‌ಗಾಗಿ 1817 MB ಮತ್ತು ಸೂಚ್ಯಂಕಗಳಿಗೆ 318 MB ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು 2,08 GB ಆಗಿದೆ. ಇದು 3 ಪಟ್ಟು ಕಡಿಮೆ ತಿರುಗುತ್ತದೆ! ಪ್ರತಿಯೊಂದು JSONB ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿ ನಾವು ಆಸ್ತಿ ಹೆಸರುಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಕಾರಣ ಈ ಸಂಗತಿಯು ನನಗೆ ಸ್ವಲ್ಪ ಆಶ್ಚರ್ಯವನ್ನುಂಟು ಮಾಡಿದೆ.

ಆದರೆ ಇನ್ನೂ, ಸಂಖ್ಯೆಗಳು ಸ್ವತಃ ಮಾತನಾಡುತ್ತವೆ: EAV ನಲ್ಲಿ ನಾವು ಗುಣಲಕ್ಷಣ ಮೌಲ್ಯಕ್ಕೆ 2 ಪೂರ್ಣಾಂಕ ವಿದೇಶಿ ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ 8 ಬೈಟ್‌ಗಳ ಹೆಚ್ಚುವರಿ ಡೇಟಾ. ಹೆಚ್ಚುವರಿಯಾಗಿ, EAV ಎಲ್ಲಾ ಆಸ್ತಿ ಮೌಲ್ಯಗಳನ್ನು ಪಠ್ಯವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಆದರೆ JSONB ಆಂತರಿಕವಾಗಿ ಸಾಧ್ಯವಿರುವಲ್ಲಿ ಸಾಂಖ್ಯಿಕ ಮತ್ತು ಬೂಲಿಯನ್ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಸಣ್ಣ ಹೆಜ್ಜೆಗುರುತನ್ನು ನೀಡುತ್ತದೆ.

ಫಲಿತಾಂಶಗಳು

ಒಟ್ಟಾರೆಯಾಗಿ, JSONB ಸ್ವರೂಪದಲ್ಲಿ ಘಟಕದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಉಳಿಸುವುದರಿಂದ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸ ಮತ್ತು ನಿರ್ವಹಣೆಯನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಬಹಳಷ್ಟು ಪ್ರಶ್ನೆಗಳನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದರೆ, ಘಟಕದಂತೆಯೇ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸುವುದು ವಾಸ್ತವವಾಗಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ಡೇಟಾದ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಎಂಬ ಅಂಶವು ಈಗಾಗಲೇ ಪ್ಲಸ್ ಆಗಿದೆ, ಆದರೆ ಪರಿಣಾಮವಾಗಿ ಡೇಟಾಬೇಸ್ ಪರಿಮಾಣದಲ್ಲಿ 3 ಪಟ್ಟು ಚಿಕ್ಕದಾಗಿದೆ.

ಅಲ್ಲದೆ, ನಡೆಸಿದ ಪರೀಕ್ಷೆಗಳ ಆಧಾರದ ಮೇಲೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ನಷ್ಟವು ಬಹಳ ಅತ್ಯಲ್ಪವಾಗಿದೆ ಎಂದು ನಾವು ತೀರ್ಮಾನಿಸಬಹುದು. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, JSONB EAV ಗಿಂತಲೂ ವೇಗವಾಗಿರುತ್ತದೆ, ಇದು ಇನ್ನಷ್ಟು ಉತ್ತಮವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಈ ಮಾನದಂಡವು ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ (ಉದಾಹರಣೆಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುವ ಘಟಕಗಳು, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾದ ಗುಣಲಕ್ಷಣಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳ,...), ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಹೇಗೆ ಸುಧಾರಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನೀವು ಯಾವುದೇ ಸಲಹೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ , ದಯವಿಟ್ಟು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬಿಡಲು ಮುಕ್ತವಾಗಿರಿ!

ಮೂಲ: www.habr.com