PostgreSQL-ൽ EAV-യെ JSONB ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു

ടിഎൽ; DR: JSONB-ന് അന്വേഷണ പ്രകടനത്തെ നഷ്ടപ്പെടുത്താതെ തന്നെ ഡാറ്റാബേസ് സ്കീമ വികസനം വളരെ ലളിതമാക്കാൻ കഴിയും.

ആമുഖം

ഒരു റിലേഷണൽ ഡാറ്റാബേസിൻ്റെ (ഡാറ്റാബേസ്) ലോകത്തിലെ ഏറ്റവും പഴയ ഉപയോഗ കേസുകളുടെ ഒരു മികച്ച ഉദാഹരണം നൽകാം: ഞങ്ങൾക്ക് ഒരു എൻ്റിറ്റിയുണ്ട്, ഈ എൻ്റിറ്റിയുടെ ചില പ്രോപ്പർട്ടികൾ (ആട്രിബ്യൂട്ടുകൾ) സംരക്ഷിക്കേണ്ടതുണ്ട്. എന്നാൽ എല്ലാ സംഭവങ്ങൾക്കും ഒരേ സെറ്റ് പ്രോപ്പർട്ടികൾ ഉണ്ടായിരിക്കണമെന്നില്ല, ഭാവിയിൽ കൂടുതൽ പ്രോപ്പർട്ടികൾ ചേർത്തേക്കാം.

ഓരോ പ്രോപ്പർട്ടി മൂല്യത്തിനും ഡാറ്റാബേസ് ടേബിളിൽ ഒരു കോളം സൃഷ്‌ടിക്കുക, കൂടാതെ ഒരു നിർദ്ദിഷ്ട എൻ്റിറ്റി ഉദാഹരണത്തിന് ആവശ്യമായവ പൂരിപ്പിക്കുക എന്നതാണ് ഈ പ്രശ്നം പരിഹരിക്കാനുള്ള എളുപ്പവഴി. കൊള്ളാം! പ്രശ്നം പരിഹരിച്ചു... നിങ്ങളുടെ ടേബിളിൽ ദശലക്ഷക്കണക്കിന് റെക്കോർഡുകൾ അടങ്ങിയിരിക്കുന്നതുവരെ നിങ്ങൾ ഒരു പുതിയ റെക്കോർഡ് ചേർക്കേണ്ടതുണ്ട്.

EAV പാറ്റേൺ പരിഗണിക്കുക (എൻ്റിറ്റി-ആട്രിബ്യൂട്ട്-മൂല്യം), ഇത് പലപ്പോഴും സംഭവിക്കാറുണ്ട്. ഒരു ടേബിളിൽ എൻ്റിറ്റികൾ (റെക്കോർഡുകൾ) അടങ്ങിയിരിക്കുന്നു, മറ്റൊരു പട്ടികയിൽ പ്രോപ്പർട്ടി നാമങ്ങൾ (ആട്രിബ്യൂട്ടുകൾ) അടങ്ങിയിരിക്കുന്നു, മൂന്നാമത്തെ ടേബിളിൽ എൻ്റിറ്റികളെ അവയുടെ ആട്രിബ്യൂട്ടുകളുമായി ബന്ധപ്പെടുത്തുകയും നിലവിലെ എൻ്റിറ്റിക്കുള്ള ആ ആട്രിബ്യൂട്ടുകളുടെ മൂല്യം ഉൾക്കൊള്ളുകയും ചെയ്യുന്നു. വ്യത്യസ്‌ത ഒബ്‌ജക്‌റ്റുകൾക്കായി വ്യത്യസ്‌ത സെറ്റ് പ്രോപ്പർട്ടികൾ ഉണ്ടായിരിക്കാനുള്ള കഴിവ് ഇത് നിങ്ങൾക്ക് നൽകുന്നു, കൂടാതെ ഡാറ്റാബേസ് ഘടന മാറ്റാതെ തന്നെ ഈച്ചയിൽ പ്രോപ്പർട്ടികൾ ചേർക്കുകയും ചെയ്യുന്നു.

എന്നിരുന്നാലും, EVA സമീപനത്തിന് ചില പോരായ്മകൾ ഇല്ലെങ്കിൽ ഞാൻ ഈ പോസ്റ്റ് എഴുതുകയില്ല. അതിനാൽ, ഉദാഹരണത്തിന്, 1 ആട്രിബ്യൂട്ട് ഉള്ള ഒന്നോ അതിലധികമോ എൻ്റിറ്റികൾ ലഭിക്കുന്നതിന്, അന്വേഷണത്തിൽ 2 ജോയിനുകൾ ആവശ്യമാണ്: ആദ്യത്തേത് ആട്രിബ്യൂട്ട് ടേബിളുമായി ചേരുന്നതാണ്, രണ്ടാമത്തേത് മൂല്യങ്ങളുടെ പട്ടികയുമായി ചേരുന്നതാണ്. ഒരു എൻ്റിറ്റിക്ക് 2 ആട്രിബ്യൂട്ടുകൾ ഉണ്ടെങ്കിൽ, 4 ജോയിനുകൾ ആവശ്യമാണ്! കൂടാതെ, എല്ലാ ആട്രിബ്യൂട്ടുകളും സാധാരണയായി സ്ട്രിംഗുകളായി സംഭരിക്കുന്നു, ഇത് ഫലത്തിനും WHERE ക്ലോസിനും ടൈപ്പ് കാസ്റ്റിംഗിന് കാരണമാകുന്നു. നിങ്ങൾ ധാരാളം ചോദ്യങ്ങൾ എഴുതുകയാണെങ്കിൽ, വിഭവ ഉപയോഗത്തിൻ്റെ കാര്യത്തിൽ ഇത് വളരെ പാഴായതാണ്.

ഈ വ്യക്തമായ പോരായ്മകൾ ഉണ്ടായിരുന്നിട്ടും, ഇത്തരത്തിലുള്ള പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ EAV വളരെക്കാലമായി ഉപയോഗിച്ചുവരുന്നു. ഇവ അനിവാര്യമായ പോരായ്മകളായിരുന്നു, മികച്ച ബദൽ ഒന്നുമില്ല.
എന്നാൽ PostgreSQL-ൽ ഒരു പുതിയ "സാങ്കേതികവിദ്യ" പ്രത്യക്ഷപ്പെട്ടു...

PostgreSQL 9.4 മുതൽ, JSON ബൈനറി ഡാറ്റ സംഭരിക്കുന്നതിന് JSONB ഡാറ്റ തരം ചേർത്തു. ഈ ഫോർമാറ്റിൽ JSON സംഭരിക്കുന്നതിന് സാധാരണയായി JSON എന്ന പ്ലെയിൻ ടെക്‌സ്‌റ്റിനേക്കാൾ കുറച്ച് സ്ഥലവും സമയവും എടുക്കുന്നുണ്ടെങ്കിലും, അതിൽ പ്രവർത്തനങ്ങൾ നടത്തുന്നത് വളരെ വേഗത്തിലാണ്. അന്വേഷണങ്ങളെ കൂടുതൽ വേഗത്തിലാക്കുന്ന സൂചികയെ JSONB പിന്തുണയ്ക്കുന്നു.

ഞങ്ങളുടെ എൻ്റിറ്റി ടേബിളിൽ ഒരു JSONB കോളം മാത്രം ചേർത്ത് ബുദ്ധിമുട്ടുള്ള EAV പാറ്റേൺ മാറ്റിസ്ഥാപിക്കാൻ JSONB ഡാറ്റ തരം ഞങ്ങളെ അനുവദിക്കുന്നു, ഇത് ഡാറ്റാബേസ് ഡിസൈൻ വളരെ ലളിതമാക്കുന്നു. പക്ഷേ, ഇതോടൊപ്പം ഉൽപ്പാദനക്ഷമത കുറയുകയും വേണം എന്ന് പലരും വാദിക്കുന്നു... അതുകൊണ്ടാണ് ഈ ലേഖനം എഴുതിയത്.

ഒരു ടെസ്റ്റ് ഡാറ്റാബേസ് സജ്ജീകരിക്കുന്നു

ഈ താരതമ്യത്തിനായി, $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"
  } 
}

അതിനാൽ രണ്ട് ഓപ്‌ഷനുകൾക്കും ഇപ്പോൾ ഞങ്ങൾക്ക് ഒരേ ഡാറ്റയുണ്ട്. ജോലിസ്ഥലത്ത് നടപ്പാക്കലുകൾ താരതമ്യം ചെയ്യാൻ തുടങ്ങാം!

നിങ്ങളുടെ ഡിസൈൻ ലളിതമാക്കുക

ഡാറ്റാബേസ് ഡിസൈൻ വളരെ ലളിതമാക്കിയിട്ടുണ്ടെന്ന് മുമ്പ് പ്രസ്താവിച്ചിരുന്നു: ഒരു ടേബിൾ, പ്രോപ്പർട്ടികൾക്കായി ഒരു JSONB കോളം ഉപയോഗിച്ച്, EAV-യ്‌ക്ക് മൂന്ന് ടേബിളുകൾ ഉപയോഗിക്കുന്നതിന് പകരം. എന്നാൽ അഭ്യർത്ഥനകളിൽ ഇത് എങ്ങനെ പ്രതിഫലിക്കുന്നു? ഒരു എൻ്റിറ്റി പ്രോപ്പർട്ടി അപ്ഡേറ്റ് ചെയ്യുന്നത് ഇതുപോലെയാണ്:

-- 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 കോളത്തിലെ സൂചികയ്ക്ക് ഇവിടെ യാതൊരു സ്വാധീനവുമില്ലെന്ന കാര്യം ശ്രദ്ധിക്കുക.

പ്രോപ്പർട്ടി മൂല്യത്തെ അടിസ്ഥാനമാക്കി ഡാറ്റ തിരഞ്ഞെടുക്കുന്നതിന്, ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഫലങ്ങൾ ലഭിക്കും (സാധാരണ സ്കെയിൽ):

സൂചികകളില്ലാതെ EAV-യെക്കാൾ വേഗത്തിൽ JSONB വീണ്ടും പ്രവർത്തിക്കുന്നത് നിങ്ങൾക്ക് ശ്രദ്ധിക്കാനാകും, എന്നാൽ EAV സൂചികകളുള്ളപ്പോൾ, അത് JSONB-യെക്കാൾ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു. എന്നാൽ JSONB അന്വേഷണങ്ങളുടെ സമയങ്ങൾ ഒന്നുതന്നെയാണെന്ന് ഞാൻ കണ്ടു, ഇത് GIN സൂചികകൾ പ്രവർത്തിക്കുന്നില്ല എന്ന വസ്തുതയിലേക്ക് എന്നെ പ്രേരിപ്പിച്ചു. ജനസംഖ്യയുള്ള പ്രോപ്പർട്ടികൾ ഉള്ള ഒരു കോളത്തിൽ നിങ്ങൾ ഒരു GIN സൂചിക ഉപയോഗിക്കുമ്പോൾ, @> എന്ന ഉൾപ്പെടുത്തൽ ഓപ്പറേറ്റർ ഉപയോഗിക്കുമ്പോൾ മാത്രമേ അത് പ്രാബല്യത്തിൽ വരികയുള്ളൂ. ഞാൻ ഇത് ഒരു പുതിയ ടെസ്റ്റിൽ ഉപയോഗിച്ചു, അത് സമയത്തിൽ വലിയ സ്വാധീനം ചെലുത്തി: 0,153 മി. ഇത് EAV-യെക്കാൾ 15000 മടങ്ങും ->> ഓപ്പറേറ്ററിനേക്കാൾ 25000 മടങ്ങും വേഗതയുള്ളതാണ്.

ഇത് മതിയായ വേഗതയുള്ളതാണെന്ന് ഞാൻ കരുതുന്നു!

ഡാറ്റാബേസ് പട്ടികയുടെ വലുപ്പം

രണ്ട് സമീപനങ്ങളുടെയും പട്ടിക വലുപ്പങ്ങൾ താരതമ്യം ചെയ്യാം. psql-ൽ, കമാൻഡ് ഉപയോഗിച്ച് നമുക്ക് എല്ലാ പട്ടികകളുടെയും സൂചികകളുടെയും വലുപ്പം കാണിക്കാൻ കഴിയും dti+

EAV സമീപനത്തിന്, ടേബിൾ വലുപ്പങ്ങൾ ഏകദേശം 3068 MB ഉം സൂചികകൾ 3427 MB വരെയും മൊത്തം 6,43 GB ആണ്. JSONB സമീപനം ടേബിളിനായി 1817 MB ഉം സൂചികകൾക്ക് 318 MB ഉം ഉപയോഗിക്കുന്നു, അതായത് 2,08 GB. ഇത് 3 മടങ്ങ് കുറവാണ്! എല്ലാ JSONB ഒബ്‌ജക്റ്റിലും ഞങ്ങൾ പ്രോപ്പർട്ടി നാമങ്ങൾ സംഭരിക്കുന്നതിനാൽ ഈ വസ്തുത എന്നെ അൽപ്പം ആശ്ചര്യപ്പെടുത്തി.

എന്നിട്ടും, അക്കങ്ങൾ സ്വയം സംസാരിക്കുന്നു: EAV-യിൽ ഓരോ ആട്രിബ്യൂട്ട് മൂല്യത്തിനും ഞങ്ങൾ 2 ഇൻ്റിഗർ വിദേശ കീകൾ സംഭരിക്കുന്നു, അതിൻ്റെ ഫലമായി 8 ബൈറ്റുകൾ അധിക ഡാറ്റ ലഭിക്കും. കൂടാതെ, EAV എല്ലാ പ്രോപ്പർട്ടി മൂല്യങ്ങളും ടെക്‌സ്‌റ്റായി സംഭരിക്കുന്നു, അതേസമയം JSONB സാധ്യമാകുന്നിടത്ത് സംഖ്യാ, ബൂളിയൻ മൂല്യങ്ങൾ ആന്തരികമായി ഉപയോഗിക്കും, അതിൻ്റെ ഫലമായി ഒരു ചെറിയ കാൽപ്പാട് ലഭിക്കും.

ഫലങ്ങൾ

മൊത്തത്തിൽ, JSONB ഫോർമാറ്റിൽ എൻ്റിറ്റി പ്രോപ്പർട്ടികൾ സംരക്ഷിക്കുന്നത് നിങ്ങളുടെ ഡാറ്റാബേസ് രൂപകൽപ്പന ചെയ്യുന്നതും പരിപാലിക്കുന്നതും വളരെ എളുപ്പമാക്കുമെന്ന് ഞാൻ കരുതുന്നു. നിങ്ങൾ ധാരാളം ചോദ്യങ്ങൾ പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, എൻ്റിറ്റിയുടെ അതേ പട്ടികയിൽ എല്ലാം സൂക്ഷിക്കുന്നത് യഥാർത്ഥത്തിൽ കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കും. ഇത് ഡാറ്റ തമ്മിലുള്ള ഇടപെടൽ ലളിതമാക്കുന്നു എന്നത് ഇതിനകം ഒരു പ്ലസ് ആണ്, എന്നാൽ തത്ഫലമായുണ്ടാകുന്ന ഡാറ്റാബേസ് വോളിയത്തിൽ 3 മടങ്ങ് ചെറുതാണ്.

കൂടാതെ, നടത്തിയ പരിശോധനകളെ അടിസ്ഥാനമാക്കി, പ്രകടന നഷ്ടം വളരെ നിസ്സാരമാണെന്ന് നമുക്ക് നിഗമനം ചെയ്യാം. ചില സന്ദർഭങ്ങളിൽ, JSONB EAV-യെക്കാൾ വേഗതയുള്ളതാണ്, ഇത് കൂടുതൽ മികച്ചതാക്കുന്നു. എന്നിരുന്നാലും, തീർച്ചയായും ഈ മാനദണ്ഡം എല്ലാ വശങ്ങളും ഉൾക്കൊള്ളുന്നില്ല (ഉദാ. വളരെ വലിയ പ്രോപ്പർട്ടികൾ ഉള്ള എൻ്റിറ്റികൾ, നിലവിലുള്ള ഡാറ്റയുടെ പ്രോപ്പർട്ടികളുടെ എണ്ണത്തിൽ ഗണ്യമായ വർദ്ധനവ്,...), അതിനാൽ അവ എങ്ങനെ മെച്ചപ്പെടുത്താം എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് എന്തെങ്കിലും നിർദ്ദേശങ്ങൾ ഉണ്ടെങ്കിൽ , അഭിപ്രായങ്ങളിൽ ഇടാൻ മടിക്കേണ്ടതില്ല!

അവലംബം: www.habr.com