ការជំនួស EAV ជាមួយ JSONB នៅក្នុង PostgreSQL

TL; DR: JSONB អាចជួយសម្រួលដល់ការអភិវឌ្ឍន៍គ្រោងការណ៍មូលដ្ឋានទិន្នន័យបានយ៉ាងងាយស្រួលដោយមិនចាំបាច់លះបង់ការអនុវត្តសំណួរ។

សេចក្តីណែនាំ

ចូរផ្តល់ឧទាហរណ៍បុរាណនៃករណីប្រើប្រាស់ចាស់បំផុតមួយនៅក្នុងពិភពនៃមូលដ្ឋានទិន្នន័យទំនាក់ទំនង (មូលដ្ឋានទិន្នន័យ): យើងមានអង្គភាពមួយ ហើយយើងត្រូវរក្សាទុកលក្ខណៈសម្បត្តិជាក់លាក់ (គុណលក្ខណៈ) នៃអង្គភាពនេះ។ ប៉ុន្តែមិនមែនគ្រប់ករណីទាំងអស់អាចមានសំណុំលក្ខណៈសម្បត្តិដូចគ្នានោះទេ ហើយលក្ខណៈសម្បត្តិជាច្រើនទៀតអាចត្រូវបានបន្ថែមនាពេលអនាគត។

មធ្យោបាយងាយស្រួលបំផុតដើម្បីដោះស្រាយបញ្ហានេះគឺដើម្បីបង្កើតជួរឈរក្នុងតារាងមូលដ្ឋានទិន្នន័យសម្រាប់តម្លៃទ្រព្យសម្បត្តិនីមួយៗ ហើយគ្រាន់តែបំពេញនូវអ្វីដែលត្រូវការសម្រាប់វត្ថុជាក់លាក់ណាមួយ។ អស្ចារ្យ! បញ្ហាត្រូវបានដោះស្រាយ... រហូតដល់តារាងរបស់អ្នកមានកំណត់ត្រារាប់លាន ហើយអ្នកត្រូវបន្ថែមកំណត់ត្រាថ្មី។

ពិចារណាគំរូ EAV (ធាតុ-គុណលក្ខណៈ-តម្លៃ) វាកើតឡើងជាញឹកញាប់។ តារាងមួយមានធាតុ (កំណត់ត្រា) តារាងមួយទៀតមានឈ្មោះទ្រព្យសម្បត្តិ (គុណលក្ខណៈ) និងតារាងទីបីភ្ជាប់ធាតុជាមួយគុណលក្ខណៈរបស់ពួកគេ និងមានតម្លៃនៃគុណលក្ខណៈទាំងនោះសម្រាប់អង្គភាពបច្ចុប្បន្ន។ វាផ្តល់ឱ្យអ្នកនូវសមត្ថភាពក្នុងការមានសំណុំលក្ខណៈសម្បត្តិផ្សេងៗគ្នាសម្រាប់វត្ថុផ្សេងៗគ្នា ហើយថែមទាំងបន្ថែមលក្ខណៈសម្បត្តិភ្លាមៗដោយមិនផ្លាស់ប្តូររចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យ។

ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំនឹងមិនសរសេរប្រកាសនេះទេ ប្រសិនបើមិនមានការចុះអន់ថយមួយចំនួនចំពោះវិធីសាស្រ្ត EVA ។ ដូច្នេះ ជាឧទាហរណ៍ ដើម្បីទទួលបានធាតុមួយ ឬច្រើនដែលមាន 1 attribute នីមួយៗ 2 Joins ត្រូវបានទាមទារនៅក្នុងសំណួរ៖ ទីមួយគឺ Join with the attribute table ទីពីរគឺ join with the values ​​table។ ប្រសិនបើអង្គភាពមួយមានគុណលក្ខណៈ 2 នោះ 4 Joins គឺចាំបាច់! លើសពីនេះ គុណលក្ខណៈទាំងអស់ជាធម្មតាត្រូវបានរក្សាទុកជាខ្សែអក្សរ ដែលនាំឱ្យការបញ្ជូនប្រភេទសម្រាប់លទ្ធផល និងឃ្លា WHERE ។ ប្រសិនបើអ្នកសរសេរសំណួរច្រើន នោះវាពិតជាខ្ជះខ្ជាយណាស់ ទាក់ទងនឹងការប្រើប្រាស់ធនធាន។

ទោះបីជាមានការខ្វះខាតជាក់ស្តែងទាំងនេះក៏ដោយ EAV ត្រូវបានប្រើប្រាស់ជាយូរមកហើយដើម្បីដោះស្រាយបញ្ហាទាំងនេះ។ ទាំងនេះគឺជាចំណុចខ្វះខាតដែលជៀសមិនរួច ហើយមិនមានជម្រើសប្រសើរជាងនេះទេ។
ប៉ុន្តែបន្ទាប់មក "បច្ចេកវិទ្យា" ថ្មីមួយបានបង្ហាញខ្លួននៅក្នុង PostgreSQL ...

ដោយចាប់ផ្តើមជាមួយ PostgreSQL 9.4 ប្រភេទទិន្នន័យ JSONB ត្រូវបានបន្ថែមដើម្បីរក្សាទុកទិន្នន័យគោលពីរ JSON ។ ទោះបីជាការរក្សាទុក JSON នៅក្នុងទម្រង់នេះជាធម្មតាត្រូវការទំហំ និងពេលវេលាច្រើនជាងបន្តិច JSON អត្ថបទធម្មតាក៏ដោយ ប្រតិបត្តិការលើវាគឺលឿនជាង។ JSONB ក៏គាំទ្រការបង្កើតលិបិក្រមផងដែរ ដែលធ្វើឱ្យសំណួរកាន់តែលឿន។

ប្រភេទទិន្នន័យ JSONB អនុញ្ញាតឱ្យយើងជំនួសគំរូ EAV ដ៏ស្មុគស្មាញដោយបន្ថែមជួរឈរ JSONB មួយទៅក្នុងតារាងអង្គភាពរបស់យើង ដែលធ្វើអោយការរចនាមូលដ្ឋានទិន្នន័យមានភាពសាមញ្ញ។ ប៉ុន្តែមនុស្សជាច្រើនបានប្រកែកថា នេះគួរតែត្រូវបានអមដោយការថយចុះនៃផលិតភាព... នោះហើយជាមូលហេតុដែលខ្ញុំសរសេរអត្ថបទនេះ។

ការដំឡើងមូលដ្ឋានទិន្នន័យសាកល្បង

សម្រាប់ការប្រៀបធៀបនេះ ខ្ញុំបានបង្កើតមូលដ្ឋានទិន្នន័យនៅលើការដំឡើងថ្មីនៃ PostgreSQL 9.5 នៅលើ $80 build DigitalOcean 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 ឈ្នះនៅទីនេះ! យើងប្រើប្រតិបត្តិករ JSON ->> ដើម្បីទទួលបានពណ៌ជាតម្លៃអត្ថបទពីវត្ថុ JSONB ។ វាក៏មានវិធីទីពីរដើម្បីសម្រេចបានលទ្ធផលដូចគ្នានៅក្នុងគំរូ JSONB ដោយប្រើ @> operator៖

-- 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 មិនអាចប្រើលិបិក្រមបានទេ (វាលគន្លឹះបរទេសមិនត្រូវបានធ្វើលិបិក្រមទេ)។ បន្ទាប់​ពី​នេះ ខ្ញុំ​បាន​បង្កើត​លិបិក្រម​មួយ​នៅ​លើ​ជួរ​ឈរ​គន្លឹះ​បរទេស 2 នៃ​តារាង​តម្លៃ EAV ព្រម​ទាំង​សន្ទស្សន៍ ជីន។ សម្រាប់ជួរឈរ JSONB ។

ការធ្វើបច្ចុប្បន្នភាពទិន្នន័យបានបង្ហាញពីលទ្ធផលដូចខាងក្រោមក្នុងលក្ខខណ្ឌនៃពេលវេលា (គិតជា ms)។ ចំណាំថាមាត្រដ្ឋានគឺលោការីត៖

យើងឃើញថា JSONB មានច្រើន (> 50000-x) លឿនជាង EAV ប្រសិនបើអ្នកមិនប្រើលិបិក្រមសម្រាប់ហេតុផលដែលបានរៀបរាប់ខាងលើ។ នៅពេលដែលយើងធ្វើលិបិក្រមជួរឈរជាមួយសោចម្បង ភាពខុសគ្នាស្ទើរតែបាត់ទៅហើយ ប៉ុន្តែ JSONB នៅតែលឿនជាង EAV 1,3 ដង។ ចំណាំថាលិបិក្រមនៅលើជួរឈរ JSONB មិនមានឥទ្ធិពលនៅទីនេះទេ ដោយសារយើងមិនប្រើជួរឈរលក្ខណសម្បត្តិក្នុងលក្ខណៈវិនិច្ឆ័យវាយតម្លៃ។

សម្រាប់ការជ្រើសរើសទិន្នន័យដោយផ្អែកលើតម្លៃអចលនទ្រព្យ យើងទទួលបានលទ្ធផលដូចខាងក្រោម (ខ្នាតធម្មតា)៖

អ្នកអាចកត់សំគាល់ថា JSONB ម្តងទៀតដំណើរការលឿនជាង EAV ដោយគ្មានលិបិក្រម ប៉ុន្តែនៅពេលដែល EAV ជាមួយលិបិក្រម វានៅតែដំណើរការលឿនជាង JSONB ។ ប៉ុន្តែបន្ទាប់មកខ្ញុំបានឃើញថាពេលវេលាសម្រាប់សំណួរ JSONB គឺដូចគ្នា នេះបានជំរុញឱ្យខ្ញុំដឹងថាសន្ទស្សន៍ GIN មិនដំណើរការ។ ជាក់ស្តែងនៅពេលដែលអ្នកប្រើសន្ទស្សន៍ GIN នៅលើជួរឈរដែលមានលក្ខណៈសម្បត្តិដែលបានបញ្ចូល វាមានប្រសិទ្ធភាពតែនៅពេលប្រើរួមបញ្ចូលប្រតិបត្តិករ @> ប៉ុណ្ណោះ។ ខ្ញុំបានប្រើវានៅក្នុងការធ្វើតេស្តថ្មីហើយវាមានឥទ្ធិពលយ៉ាងខ្លាំងទៅលើពេលវេលា៖ ត្រឹមតែ 0,153ms ប៉ុណ្ណោះ! នេះគឺលឿនជាង EAV 15000 ដង និងលឿនជាង 25000 ដងជាង ->> operator។

ខ្ញុំគិតថាវាលឿនល្មម!

ទំហំតារាងមូលដ្ឋានទិន្នន័យ

ចូរយើងប្រៀបធៀបទំហំតារាងសម្រាប់វិធីសាស្រ្តទាំងពីរ។ នៅក្នុង psql យើងអាចបង្ហាញទំហំនៃតារាង និងលិបិក្រមទាំងអស់ដោយប្រើពាក្យបញ្ជា dti+

សម្រាប់វិធីសាស្រ្ត EAV ទំហំតារាងគឺប្រហែល 3068 MB និងលិបិក្រមរហូតដល់ 3427 MB សម្រាប់ទំហំសរុប 6,43 GB។ វិធីសាស្រ្ត JSONB ប្រើ 1817 MB សម្រាប់តារាង និង 318 MB សម្រាប់លិបិក្រម ដែលមានទំហំ 2,08 GB។ វាប្រែជាតិចជាង 3 ដង! ការពិតនេះបានធ្វើឱ្យខ្ញុំភ្ញាក់ផ្អើលបន្តិចព្រោះយើងរក្សាទុកឈ្មោះអចលនទ្រព្យនៅក្នុងគ្រប់វត្ថុ JSONB ។

ប៉ុន្តែនៅតែលេខនិយាយសម្រាប់ខ្លួនគេ៖ នៅក្នុង EAV យើងរក្សាទុក 2 integer Foreign keys ក្នុងមួយតម្លៃ attribute ដែលបណ្តាលឱ្យមាន 8 bytes នៃទិន្នន័យបន្ថែម។ លើសពីនេះទៀត EAV រក្សាទុកតម្លៃទ្រព្យសម្បត្តិទាំងអស់ជាអត្ថបទ ខណៈពេលដែល JSONB នឹងប្រើលេខ និងតម្លៃប៊ូលីននៅខាងក្នុងតាមដែលអាចធ្វើទៅបាន ដែលបណ្តាលឱ្យមានស្នាមជើងតូចជាង។

លទ្ធផល

សរុបមក ខ្ញុំគិតថាការរក្សាទុកលក្ខណៈសម្បត្តិអង្គភាពក្នុងទម្រង់ JSONB អាចធ្វើឱ្យការរចនា និងការថែរក្សាមូលដ្ឋានទិន្នន័យរបស់អ្នកកាន់តែងាយស្រួល។ ប្រសិនបើអ្នកកំពុងដំណើរការសំណួរជាច្រើន នោះការរក្សាអ្វីៗគ្រប់យ៉ាងនៅក្នុងតារាងដូចគ្នាជាមួយនឹងអង្គភាពនឹងដំណើរការកាន់តែមានប្រសិទ្ធភាព។ ហើយការពិតដែលថាការនេះជួយសម្រួលអន្តរកម្មរវាងទិន្នន័យគឺជាការបូកមួយរួចទៅហើយ ប៉ុន្តែមូលដ្ឋានទិន្នន័យលទ្ធផលគឺតូចជាង 3 ដងក្នុងបរិមាណ។

ដូចគ្នានេះផងដែរ ដោយផ្អែកលើការធ្វើតេស្តដែលបានអនុវត្ត យើងអាចសន្និដ្ឋានថាការខាតបង់នៃការអនុវត្តគឺមិនសំខាន់ខ្លាំងណាស់។ ក្នុងករណីខ្លះ JSONB លឿនជាង EAV ដែលធ្វើឱ្យវាកាន់តែប្រសើរ។ ទោះជាយ៉ាងណាក៏ដោយ ស្តង់ដារនេះជាការពិតណាស់មិនគ្របដណ្តប់គ្រប់ទិដ្ឋភាពទាំងអស់ (ឧ. អង្គភាពដែលមានលក្ខណៈសម្បត្តិមួយចំនួនធំ ការកើនឡើងគួរឱ្យកត់សម្គាល់នៃចំនួនលក្ខណៈសម្បត្តិនៃទិន្នន័យដែលមានស្រាប់...) ដូច្នេះប្រសិនបើអ្នកមានការណែនាំអំពីវិធីកែលម្អពួកវា។ , សូមមានអារម្មណ៍សេរីក្នុងការបញ្ចេញមតិ!

ប្រភព: www.habr.com