EAV ကို PostgreSQL တွင် JSONB ဖြင့် အစားထိုးခြင်း။

TL; DR- JSONB သည် query စွမ်းဆောင်ရည်ကို မထိခိုက်စေဘဲ database schema ဖွံ့ဖြိုးတိုးတက်မှုကို များစွာရိုးရှင်းစေသည်။

နိဒါန်း

ဆက်စပ်ဒေတာဘေ့စ် (ဒေတာဘေ့စ်) လောကမှာ ရှေးအကျဆုံး အသုံးပြုမှုကိစ္စများထဲမှ ဖြစ်နိုင်ချေရှိတဲ့ ဂန္တဝင်ဥပမာတစ်ခုကို ပေးပါရစေ- ကျွန်ုပ်တို့တွင် အကြောင်းအရာတစ်ခုရှိပြီး၊ ဤအရာ၏ ဂုဏ်သတ္တိများ (attributes) အချို့ကို သိမ်းဆည်းရန် လိုအပ်ပါသည်။ သို့သော် သာမာန်အားလုံးတွင် တူညီသောဂုဏ်သတ္တိများ ရှိနိုင်မည်မဟုတ်ပါ၊ နှင့် နောက်ထပ်ဂုဏ်သတ္တိများကို အနာဂတ်တွင် ထပ်ပေါင်းထည့်နိုင်သည်။

ဤပြဿနာကိုဖြေရှင်းရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ ပစ္စည်းတန်ဖိုးတစ်ခုစီအတွက် ဒေတာဘေ့စ်ဇယားတွင် ကော်လံတစ်ခုဖန်တီးပြီး တိကျသောအကြောင်းအရာတစ်ခုအတွက် လိုအပ်သည့်အရာများကို ရိုးရှင်းစွာဖြည့်စွက်ပါ။ မိုက်တယ်! ပြဿနာဖြေရှင်းပြီးပြီ... သင့်ဇယားတွင် သန်းပေါင်းများစွာသော မှတ်တမ်းများပါရှိပြီး မှတ်တမ်းအသစ်တစ်ခု ထပ်ထည့်ရန် လိုအပ်သည်အထိ။

EAV ပုံစံကို သုံးသပ်ပါ (Entity-Attribute-Value) မကြာခဏဖြစ်ပေါ်သည်။ ဇယားတစ်ခုတွင် အကြောင်းအရာများ (မှတ်တမ်းများ)၊ အခြားဇယားတစ်ခုတွင် ပိုင်ဆိုင်မှုအမည်များ (attributes) ပါ၀င်ပြီး တတိယဇယားတစ်ခုသည် ၎င်းတို့၏ attribute များနှင့် တွဲဖက်လုပ်ဆောင်သည့်အရာများဖြစ်ပြီး လက်ရှိ entity အတွက် ထို attribute များ၏ တန်ဖိုးများပါရှိသည်။ ၎င်းသည် သင့်အား မတူညီသော အရာဝတ္ထုများအတွက် မတူညီသော ဂုဏ်သတ္တိများ အစုံအလင်ရှိစေကာ ဒေတာဘေ့စ်ဖွဲ့စည်းပုံကို မပြောင်းလဲဘဲ ပျံသန်းခြင်းတွင် ဂုဏ်သတ္တိများ ပေါင်းထည့်နိုင်သည်။

သို့သော် EVA ချဉ်းကပ်မှုတွင် အားနည်းချက်အချို့မရှိပါက ဤပို့စ်ကို ကျွန်ုပ်ရေးမည်မဟုတ်ပါ။ ထို့ကြောင့် ဥပမာအားဖြင့်၊ တစ်ခုစီတွင် ရည်ညွှန်းချက် 1 ခုပါသော တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော အရာများကို ရယူရန် query တွင် ချိတ်ဆက်မှု 2 ခု လိုအပ်သည်- ပထမတစ်ခုသည် attribute table နှင့် join ဖြစ်ပြီး၊ ဒုတိယသည် values ​​table နှင့် join တစ်ခုဖြစ်သည်။ အကယ်၍ အဖွဲ့အစည်းတစ်ခုတွင် ရည်ညွှန်းချက် 2 ခုပါပါက ချိတ်ဆက်မှု 4 ခု လိုအပ်ပါသည်။ ထို့အပြင်၊ ရည်ညွှန်းချက်အားလုံးကို ပုံမှန်အားဖြင့် strings များအဖြစ် သိမ်းဆည်းထားပြီး ရလဒ်နှင့် WHERE clause နှစ်ခုစလုံးအတွက် အမျိုးအစားကာစ်တ်ကို ဖြစ်ပေါ်စေသည်။ အကယ်၍ သင်သည် မေးခွန်းများစွာကို ရေးသားပါက၊ အရင်းအမြစ်အသုံးပြုမှုနှင့်ပတ်သက်၍ ၎င်းသည် အလွန်ဖြုန်းတီးမှုဖြစ်သည်။

ဤကဲ့သို့သော ချို့ယွင်းချက်များ ရှိနေသော်လည်း EAV သည် ဤပြဿနာမျိုးများကို ဖြေရှင်းရန် အချိန်အတော်ကြာ အသုံးပြုခဲ့သည်။ ယင်းတို့သည် မလွှဲမရှောင်သာ ချို့ယွင်းချက်များ ဖြစ်၍ ပိုမိုကောင်းမွန်သော အခြားရွေးချယ်စရာ မရှိပေ။
သို့သော် PostgreSQL တွင် "နည်းပညာ" အသစ်တစ်ခုပေါ်လာသည်။

PostgreSQL 9.4 ဖြင့် စတင်၍ JSONB ဒေတာအမျိုးအစားကို JSON ဒွိဒေတာ သိမ်းဆည်းရန် ထည့်သွင်းခဲ့သည်။ JSON ကို ဤဖော်မတ်တွင် သိမ်းဆည်းခြင်းသည် သာမန်အားဖြင့် ရိုးရိုးစာသား JSON ထက် နေရာနှင့် အချိန် အနည်းငယ် ပိုယူသော်လည်း ၎င်းကို လုပ်ဆောင်ခြင်းမှာ ပိုမိုမြန်ဆန်ပါသည်။ JSONB သည် စုံစမ်းမေးမြန်းမှုများကို ပိုမိုမြန်ဆန်စေသည့် ညွှန်းကိန်းပြုလုပ်ခြင်းကိုလည်း ပံ့ပိုးပေးပါသည်။

JSONB ဒေတာအမျိုးအစားသည် ကျွန်ုပ်တို့အား ကျွန်ုပ်တို့၏ entity table သို့ JSONB ကော်လံတစ်ခုမျှထည့်ခြင်းဖြင့် ရှုပ်ထွေးသော EAV ပုံစံကို အစားထိုးနိုင်စေပြီး ဒေတာဘေ့စ်ဒီဇိုင်းကို များစွာရိုးရှင်းစေသည်။ ဒါပေမယ့် တော်တော်များများက ဒါဟာ ကုန်ထုတ်စွမ်းအား ကျဆင်းခြင်းနဲ့ တွဲသင့်တယ်လို့ စောဒကတက်ကြတယ်... အဲဒါကြောင့် ကျွန်တော် ဒီဆောင်းပါးကို ရေးခဲ့ပါတယ်။

စမ်းသပ်ဒေတာဘေ့စ်တစ်ခုတည်ဆောက်ခြင်း။

ဤနှိုင်းယှဉ်မှုအတွက်၊ ကျွန်ုပ်သည် $9.5 တည်ဆောက်မှုတွင် PostgreSQL 80 အသစ်တပ်ဆင်မှုတွင် ဒေတာဘေ့စ်ကို ဖန်တီးခဲ့သည်။ DigitalOcean Ubuntu 14.04 postgresql.conf တွင် အချို့သော parameters များကို သတ်မှတ်ပြီးနောက် ကျွန်တော် run ခဲ့သည်။ ဤ psql ကို အသုံးပြု၍ script ကို 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 tables များသို့ ပေါင်းထည့်ခဲ့သည် (entity & 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 အတွက် ဇယားသုံးခုကိုသုံးမည့်အစား Properties အတွက် 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 အရာဝတ္ထုအဖြစ် ကျော်သွားသင့်သည်။ သို့သော်၊ မည်သည့် identifier ကိုမဆို ကြိုတင်သိရန် မလိုအပ်ပါ။ 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 အရာဝတ္ထုတွင် @> အော်ပရေတာ၏ ညာဘက်တွင်ရှိသော အရာတစ်ခုပါရှိခြင်း ရှိ၊ မရှိ စစ်ဆေးကြည့်ပါ။ ဖတ်ရှုနိုင်မှုနည်းပြီး အကျိုးဖြစ်ထွန်းမှု ပိုနည်းသည် (အောက်တွင် ကြည့်ပါ)။

Properties အများအပြားကို တစ်ပြိုင်နက် ရွေးချယ်ရန်လိုအပ်သောအခါ JSONB ကိုပိုမိုလွယ်ကူအောင်ပြုလုပ်ကြပါစို့။ ဤသည်မှာ JSONB ချဉ်းကပ်မှု အမှန်တကယ် ရောက်ရှိလာသည်- ကျွန်ုပ်တို့သည် ချိတ်ဆက်မှုများမလိုအပ်ဘဲ ကျွန်ုပ်တို့၏ရလဒ်အတွက် ကော်လံများအဖြစ် သတ်မှတ်သည့် အပိုကော်လံများအဖြစ် ဂုဏ်သတ္တိများကို ရွေးချယ်သည်-

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

EAV ဖြင့် သင်မေးမြန်းလိုသော ပစ္စည်းတစ်ခုစီအတွက် Join 2 ခု လိုအပ်ပါမည်။ ကျွန်ုပ်၏အမြင်အရ၊ အထက်ဖော်ပြပါမေးခွန်းများသည် ဒေတာဘေ့စ်ဒီဇိုင်းတွင် အလွန်ရိုးရှင်းမှုကိုပြသသည်။ JSONB သို့ queries ရေးနည်း၏ နောက်ထပ်နမူနာများကိုလည်း ကြည့်ရှုနိုင်ပါသည်။ ဤ ပို့စ်။
အခုက Performance အကြောင်းပြောဖို့အချိန်ရောက်ပြီ။

ထွက်နိုင်ရေး

စွမ်းဆောင်ရည်ကို နှိုင်းယှဉ်ဖို့ ကျွန်တော်သုံးတယ်။ ခွဲခြမ်းစိတ်ဖြာရှင်းပြပါ။ စုံစမ်းမှုများတွင်၊ လုပ်ဆောင်ချိန်ကို တွက်ချက်ရန်။ query planner သည် ပထမအကြိမ်ထက် ပိုကြာသောကြောင့် query တစ်ခုစီကို အနည်းဆုံး သုံးကြိမ် လုပ်ဆောင်ခဲ့သည်။ ပထမဦးစွာ ကျွန်ုပ်သည် အညွှန်းများမပါဘဲ မေးခွန်းများကို လုပ်ဆောင်ခဲ့သည်။ EAV အတွက် လိုအပ်သော ချိတ်ဆက်မှုများသည် အညွှန်းများကို အသုံးမပြုနိုင်သောကြောင့် ၎င်းသည် JSONB ၏ အားသာချက်တစ်ခုဖြစ်သည်မှာ ထင်ရှားပါသည်။ ၎င်းပြီးနောက် EAV တန်ဖိုးဇယား၏ နိုင်ငံခြားကီးကော်လံ 2 ခုတွင် အညွှန်းတစ်ခုအပြင် အညွှန်းတစ်ခုကို ဖန်တီးခဲ့သည်။ Gin JSONB ကော်လံအတွက်။

ဒေတာအပ်ဒိတ်သည် အချိန်ကာလသတ်မှတ်ချက် (ms in) တွင် အောက်ပါရလဒ်များကို ပြသခဲ့သည်။ စကေးသည် လော့ဂရစ်သမ်ဖြစ်သည်ကို သတိပြုပါ။

အထက်တွင်ဖော်ပြထားသောအကြောင်းပြချက်ကြောင့် အညွှန်းများကိုအသုံးမပြုပါက JSONB သည် EAV ထက် (> 50000-x) ပိုမြန်သည်ကို ကျွန်ုပ်တို့မြင်ရပါသည်။ ကျွန်ုပ်တို့သည် ပင်မကီးများဖြင့် ကော်လံများကို ညွှန်းသောအခါ၊ ကွာခြားချက်မှာ ပျောက်ကွယ်လုနီးပါးဖြစ်သော်လည်း JSONB သည် EAV ထက် 1,3 ဆ ပိုမြန်နေသေးသည်။ ကျွန်ုပ်တို့သည် အကဲဖြတ်မှုစံသတ်မှတ်ချက်များတွင် ပိုင်ဆိုင်မှုကော်လံကို အသုံးမပြုသောကြောင့် JSONB ကော်လံရှိ အညွှန်းသည် ဤနေရာတွင် သက်ရောက်မှုမရှိကြောင်း သတိပြုပါ။

ပိုင်ဆိုင်မှုတန်ဖိုးပေါ်မူတည်၍ ဒေတာရွေးချယ်ခြင်းအတွက်၊ ကျွန်ုပ်တို့သည် အောက်ပါရလဒ်များ (သာမန်စကေး) ကို ရရှိသည်-

JSONB သည် အညွှန်းများမပါဘဲ EAV ထက်ပိုမိုမြန်ဆန်စွာအလုပ်လုပ်သည်ကို သင်သတိပြုမိနိုင်သော်လည်း EAV သည် အညွှန်းများပါရှိသည့်အချိန်တွင် JSONB ထက်ပိုမိုမြန်ဆန်စွာအလုပ်လုပ်နေသေးသည်။ ဒါပေမယ့် JSONB မေးမြန်းချက်တွေအတွက် အချိန်တွေက အတူတူပါပဲလို့ ကျွန်တော်မြင်ခဲ့တယ်၊ ဒါက GIN အညွှန်းကိန်းတွေ အလုပ်မလုပ်တော့ဘူးဆိုတာ သိလိုက်ရတယ်။ လူနေထူထပ်သည့် ဂုဏ်သတ္တိများပါရှိသော ကော်လံတစ်ခုပေါ်တွင် GIN အညွှန်းကို သင်အသုံးပြုသောအခါတွင် ပါဝင်သည့် အော်ပရေတာ @> ကိုအသုံးပြုသည့်အခါမှသာ အကျိုးသက်ရောက်မှုရှိမည်ဖြစ်သည်။ ၎င်းကို စမ်းသပ်မှုအသစ်တွင် ကျွန်တော်အသုံးပြုခဲ့ပြီး ၎င်းသည် အချိန်အပေါ် ကြီးမားသောအကျိုးသက်ရောက်မှုရှိခဲ့သည်- 0,153ms သာရှိသည်။ ၎င်းသည် EAV ထက် အဆ 15000 ပိုမြန်ပြီး -->> အော်ပရေတာထက် အဆ 25000 ပိုမြန်သည်။

လုံလောက်ပြီထင်တယ်!

ဒေတာဘေ့စ်ဇယားအရွယ်အစား

နည်းလမ်းနှစ်ခုလုံးအတွက် ဇယားအရွယ်အစားကို နှိုင်းယှဉ်ကြည့်ရအောင်။ psql တွင်ကျွန်ုပ်တို့သည် command ကိုအသုံးပြု၍ ဇယားများနှင့်အညွှန်းများအားလုံး၏အရွယ်အစားကိုပြသနိုင်သည်။ dti+

EAV ချဉ်းကပ်မှုအတွက်၊ ဇယားအရွယ်အစားများသည် 3068 MB ဝန်းကျင်ရှိပြီး စုစုပေါင်း 3427 GB အတွက် အညွှန်း 6,43 MB အထိရှိသည်။ JSONB ချဉ်းကပ်မှုသည် ဇယားအတွက် 1817 MB နှင့် 318 GB ဖြစ်သည့် အညွှန်းကိန်းများအတွက် 2,08 MB ကိုအသုံးပြုသည်။ 3 ဆ လျော့နည်းသွားသည် ။ ကျွန်ုပ်တို့သည် JSONB အရာဝတ္ထုတိုင်းတွင် ပိုင်ဆိုင်မှုအမည်များကို သိမ်းဆည်းထားသောကြောင့် ဤအချက်က ကျွန်ုပ်ကို အနည်းငယ် အံ့အားသင့်စေပါသည်။

သို့သော်၊ နံပါတ်များသည် ၎င်းတို့အတွက် ပြောဆိုနေကြသည်- EAV တွင် ကျွန်ုပ်တို့သည် attribute value တစ်ခုလျှင် integer Foreign keys 2 ခုကို သိမ်းဆည်းထားပြီး အပိုဒေတာ 8 bytes ရရှိစေသည်။ ထို့အပြင် EAV သည် ပိုင်ဆိုင်မှုတန်ဖိုးများအားလုံးကို စာသားအဖြစ် သိမ်းဆည်းထားပြီး JSONB သည် ဖြစ်နိုင်ပါက ကိန်းဂဏာန်းနှင့် ဘူလီယံတန်ဖိုးများကို အတွင်းပိုင်း၌ အသုံးပြုမည်ဖြစ်ပြီး ပိုမိုသေးငယ်သောခြေရာကို ရရှိစေမည်ဖြစ်သည်။

ရလဒ်များကို

ယေဘူယျအားဖြင့်၊ JSONB ဖော်မတ်တွင် entity ဂုဏ်သတ္တိများကို သိမ်းဆည်းခြင်းသည် သင့်ဒေတာဘေ့စ်ကို ဒီဇိုင်းဆွဲခြင်းနှင့် ထိန်းသိမ်းခြင်းကို ပိုမိုလွယ်ကူစေသည်ဟု ကျွန်ုပ်ထင်ပါတယ်။ အကယ်၍ သင်သည် မေးခွန်းများစွာကို လုပ်ဆောင်နေပါက၊ အရာခပ်သိမ်းကို ဇယားတစ်ခုတည်းတွင် ထားရှိခြင်းက အမှန်တကယ် ပိုမိုထိရောက်စွာ လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ဒေတာများကြား အပြန်အလှန်ဆက်သွယ်မှုကို ရိုးရှင်းစေသည့်အချက်မှာ အပေါင်းဖြစ်နေပြီဖြစ်သော်လည်း ရလဒ်ဒေတာဘေ့စ်သည် ထုထည်တွင် ၃ ဆ ပိုသေးငယ်သည်။

ထို့အပြင်၊ လုပ်ဆောင်ခဲ့သော စမ်းသပ်မှုများအပေါ် အခြေခံ၍ စွမ်းဆောင်ရည် ဆုံးရှုံးမှုများသည် အလွန်အရေးမပါကြောင်း ကျွန်ုပ်တို့ ကောက်ချက်ချနိုင်ပါသည်။ အချို့ကိစ္စများတွင်၊ JSONB သည် EAV ထက်ပင် ပိုမြန်သောကြောင့် ၎င်းကို ပိုကောင်းစေသည်။ သို့သော်၊ ဤစံနှုန်းသည် ကဏ္ဍအားလုံးကို အကျုံးဝင်မည်မဟုတ်ပါ (ဥပမာ- ဂုဏ်သတ္တိများစွာရှိသော အရာများ၊ ရှိပြီးသားဒေတာများ၏ ဂုဏ်သတ္တိအရေအတွက် သိသိသာသာတိုးလာခြင်း၊...)၊ ထို့ကြောင့် ၎င်းတို့ကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် အကြံပြုချက်များရှိပါက သင့်တွင်၊ ကျေးဇူးပြု၍ မှတ်ချက်များတွင်ချန်ထားခဲ့ပါ။

source: www.habr.com