PostgreSQL માં JSONB સાથે EAV ને બદલીને

TL; 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 ના નવા ઇન્સ્ટોલેશન પર ડેટાબેઝ બનાવ્યો DigitalOcean ઉબુન્ટુ 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 કૉલમ માટે.

ડેટા અપડેટે નીચેના પરિણામો સમયની દ્રષ્ટિએ દર્શાવ્યા (ms માં). નોંધ કરો કે સ્કેલ લઘુગણક છે:

અમે જોઈએ છીએ કે JSONB EAV કરતાં વધુ ઝડપી છે (> 50000-x) જો તમે ઉપર જણાવેલ કારણસર અનુક્રમણિકાઓનો ઉપયોગ કરતા નથી. જ્યારે આપણે પ્રાથમિક કી સાથે કૉલમને અનુક્રમિત કરીએ છીએ, ત્યારે તફાવત લગભગ અદૃશ્ય થઈ જાય છે, પરંતુ JSONB હજી પણ EAV કરતાં 1,3 ગણો ઝડપી છે. નોંધ કરો કે JSONB કૉલમ પરના ઇન્ડેક્સની અહીં કોઈ અસર નથી કારણ કે અમે મૂલ્યાંકનના માપદંડમાં પ્રોપર્ટી કૉલમનો ઉપયોગ કરતા નથી.

મિલકત મૂલ્યના આધારે ડેટા પસંદ કરવા માટે, અમને નીચેના પરિણામો (સામાન્ય સ્કેલ) મળે છે:

તમે નોંધ કરી શકો છો કે JSONB ફરીથી અનુક્રમણિકાઓ વિના EAV કરતાં વધુ ઝડપથી કામ કરે છે, પરંતુ જ્યારે EAV અનુક્રમણિકાઓ સાથે, તે હજુ પણ JSONB કરતાં વધુ ઝડપથી કાર્ય કરે છે. પરંતુ પછી મેં જોયું કે JSONB ક્વેરીઝ માટેનો સમય સમાન હતો, આનાથી મને એ હકીકત તરફ પ્રેરિત કરવામાં આવ્યું કે GIN ઇન્ડેક્સ કામ કરતા નથી. દેખીતી રીતે જ્યારે તમે વસ્તીવાળા પ્રોપર્ટીઝ સાથે કૉલમ પર 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