មូលដ្ឋានទិន្នន័យកម្មវិធីផ្ញើសារ (ផ្នែកទី 2): ការបែងចែក "សម្រាប់ប្រាក់ចំណេញ"

យើងបានរចនារចនាសម្ព័ន្ធនៃមូលដ្ឋានទិន្នន័យ PostgreSQL របស់យើងដោយជោគជ័យសម្រាប់ការរក្សាទុកការឆ្លើយឆ្លង មួយឆ្នាំបានកន្លងផុតទៅ អ្នកប្រើប្រាស់កំពុងបំពេញវាយ៉ាងសកម្ម ហើយឥឡូវនេះវាមាន កំណត់ត្រារាប់លានហើយ... អ្វីមួយបានចាប់ផ្តើមយឺត។

• ផ្នែកទី 1: ការរចនាស៊ុមមូលដ្ឋាន
• ផ្នែកទី 2: ផ្នែក "សម្រាប់ប្រាក់ចំណេញ"

ចំណុចនោះគឺថា នៅពេលដែលទំហំតារាងកើនឡើង "ជម្រៅ" នៃសន្ទស្សន៍ក៏ដូចគ្នាដែរ។ - ទោះបីជាលោការីត។ ប៉ុន្តែយូរ ៗ ទៅនេះបង្ខំឱ្យម៉ាស៊ីនមេឱ្យបំពេញភារកិច្ចអាន / សរសេរដូចគ្នា។ ដំណើរការទំព័រជាច្រើនដងនៃទិន្នន័យជាងនៅដើម។

នេះគឺជាកន្លែងដែលវាមកជួយសង្គ្រោះ ផ្នែក.

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

យើងនឹងពិចារណាមិនមែនជាស្គ្រីបជាក់លាក់សម្រាប់ការអនុវត្តការបែងចែក "នៅក្នុងផ្នែករឹង" ប៉ុន្តែវិធីសាស្រ្តខ្លួនវា - អ្វីនិងរបៀបគួរតែត្រូវបាន "កាត់ជាចំណិត" និងអ្វីដែលបំណងប្រាថ្នាបែបនេះនាំឱ្យមាន។

គំនិត

ចូរកំណត់គោលដៅរបស់យើងម្តងទៀត៖ យើងចង់ធ្វើឱ្យប្រាកដថា ថ្ងៃនេះ ថ្ងៃស្អែក និងក្នុងមួយឆ្នាំ ចំនួនទិន្នន័យដែលបានអានដោយ PostgreSQL ក្នុងអំឡុងពេលប្រតិបត្តិការអាន/សរសេរណាមួយនៅតែមានប្រហាក់ប្រហែល។

សម្រាប់ណាមួយ។ ទិន្នន័យប្រមូលតាមកាលប្បវត្តិ (សារ, ឯកសារ, កំណត់ហេតុ, បណ្ណសារ, ...) ជម្រើសធម្មជាតិជាគន្លឹះបំបែកគឺ កាលបរិច្ឆេទ / ពេលវេលាព្រឹត្តិការណ៍. ក្នុងករណីរបស់យើងព្រឹត្តិការណ៍បែបនេះគឺ ពេលផ្ញើសារ.

ចំណាំថាអ្នកប្រើប្រាស់ស្ទើរតែជានិច្ច ធ្វើការតែជាមួយ "ចុងក្រោយ" ប៉ុណ្ណោះ។ ទិន្នន័យបែបនេះ - ពួកគេអានសារចុងក្រោយ វិភាគកំណត់ហេតុចុងក្រោយបង្អស់ ... ទេ ពិតណាស់ ពួកគេអាចរំកិលទៅមុខបានទាន់ពេល ប៉ុន្តែពួកគេធ្វើបែបនេះកម្រណាស់។

ពីឧបសគ្គទាំងនេះ វាច្បាស់ណាស់ថាដំណោះស្រាយសារដ៏ល្អប្រសើរនឹងត្រូវបាន ផ្នែក "ប្រចាំថ្ងៃ" - យ៉ាងណាមិញ អ្នកប្រើប្រាស់របស់យើងស្ទើរតែតែងតែអាននូវអ្វីដែលបានមករកគាត់ “ថ្ងៃនេះ” ឬ “ម្សិលមិញ”។

ប្រសិនបើយើងសរសេរ និងអានស្ទើរតែតែមួយផ្នែកក្នុងអំឡុងពេលថ្ងៃ នោះវាក៏ផ្តល់ឱ្យយើងផងដែរ។ ការប្រើប្រាស់អង្គចងចាំ និងថាសកាន់តែមានប្រសិទ្ធភាព - ចាប់តាំងពីសន្ទស្សន៍ផ្នែកទាំងអស់សមនឹង RAM យ៉ាងងាយស្រួល ផ្ទុយទៅនឹង "ធំ និងធាត់" ពេញតារាង។

ជំហានដោយជំហាន

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

សារ លក្ខណៈសម្បត្តិ និងការព្យាករណ៍របស់វា។

ដោយសារយើងសម្រេចចិត្តកាត់សារតាមកាលបរិច្ឆេទ វាសមហេតុផលក្នុងការបែងចែកអង្គភាព-លក្ខណសម្បត្តិដែលអាស្រ័យលើពួកវា (ឯកសារភ្ជាប់ បញ្ជីអ្នកទទួល) និង តាមកាលបរិច្ឆេទនៃសារផងដែរ។.

ដោយសារកិច្ចការធម្មតារបស់យើងមួយគឺការមើលការចុះឈ្មោះសារយ៉ាងជាក់លាក់ (មិនទាន់អាន ​​ចូល ទាំងអស់) វាក៏សមហេតុផលផងដែរក្នុងការ "គូរពួកវាចូល" ទៅក្នុងការបែងចែកតាមកាលបរិច្ឆេទសារ។

យើងបន្ថែមកូនសោបែងចែក (កាលបរិច្ឆេទសារ) ទៅតារាងទាំងអស់៖ អ្នកទទួល ឯកសារ បញ្ជីឈ្មោះ។ អ្នកមិនចាំបាច់បន្ថែមវាទៅសារខ្លួនឯងទេ ប៉ុន្តែប្រើ DateTime ដែលមានស្រាប់។

ខ្សែស្រឡាយ

ដោយសារមានប្រធានបទតែមួយសម្រាប់សារជាច្រើន វាមិនមានវិធីដើម្បី "កាត់" វានៅក្នុងគំរូដូចគ្នាទេ អ្នកត្រូវតែពឹងផ្អែកលើអ្វីផ្សេងទៀត។ ក្នុងករណីរបស់យើងវាគឺជាឧត្តមគតិ កាលបរិច្ឆេទនៃសារដំបូងក្នុងការឆ្លើយឆ្លង — នោះ​គឺ​ជា​ពេល​នៃ​ការ​បង្កើត​តាម​ពិត​ទៅ​នៃ​ប្រធាន​បទ​។

បន្ថែមគ្រាប់ចុចបែងចែក (កាលបរិច្ឆេទប្រធានបទ) ទៅតារាងទាំងអស់៖ ប្រធានបទ អ្នកចូលរួម។

ប៉ុន្តែឥឡូវនេះយើងមានបញ្ហាពីរក្នុងពេលតែមួយ៖

• តើ​ខ្ញុំ​គួរ​ស្វែង​រក​សារ​លើ​ប្រធាន​បទ​ក្នុង​ផ្នែក​ណា?
• តើ​ខ្ញុំ​គួរ​ស្វែង​រក​ប្រធាន​បទ​ពី​សារ​ក្នុង​ផ្នែក​ណា?

ជាការពិតណាស់ យើងអាចបន្តស្វែងរកគ្រប់ផ្នែកទាំងអស់ ប៉ុន្តែវានឹងជារឿងសោកសៅបំផុត ហើយនឹងបដិសេធការឈ្នះទាំងអស់របស់យើង។ ដូច្នេះ ដើម្បីដឹងពីកន្លែងដែលត្រូវរកមើល យើងនឹងបង្កើតតំណភ្ជាប់/ចង្អុលទៅផ្នែក៖

• យើងនឹងបន្ថែមនៅក្នុងសារ វាលកាលបរិច្ឆេទប្រធានបទ
• តោះបន្ថែមលើប្រធានបទ កំណត់កាលបរិច្ឆេទសារ ការឆ្លើយឆ្លងនេះ (អាចជាតារាងដាច់ដោយឡែក ឬអារេនៃកាលបរិច្ឆេទ)

ដោយសារវានឹងមានការកែប្រែមួយចំនួនចំពោះបញ្ជីកាលបរិច្ឆេទសារសម្រាប់ការឆ្លើយឆ្លងនីមួយៗ (បន្ទាប់ពីទាំងអស់ សារស្ទើរតែទាំងអស់ធ្លាក់នៅថ្ងៃទី 1-2) ខ្ញុំនឹងផ្តោតលើជម្រើសនេះ។

សរុបមក រចនាសម្ព័ននៃមូលដ្ឋានទិន្នន័យរបស់យើងបានយកទម្រង់ដូចខាងក្រោម ដោយគិតគូរពីការបែងចែក៖

តារាង៖ RU ប្រសិនបើអ្នកមានការច្រណែននឹងអក្ខរក្រម Cyrillic នៅក្នុងឈ្មោះតារាង/វាល វាជាការប្រសើរជាងកុំមើល

-- секции по дате сообщения
CREATE TABLE "Сообщение_YYYYMMDD"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "ДатаТемы"
    date
, "Автор"
    uuid
, "ДатаВремя" -- используем как дату
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

CREATE TABLE "РеестрСообщений_YYYYMMDD"(
  "ДатаСообщения"
    date
, "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений_YYYYMMDD"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

-- секции по дате темы
CREATE TABLE "Тема_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "УчастникТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

CREATE TABLE "ДатыСообщенийТемы_YYYYMMDD"(
  "ДатаТемы"
    date
, "Тема"
    uuid
      PRIMARY KEY
, "Дата"
    date
);

សន្សំមួយកាក់ស្អាត

ចុះបើយើងមិនប្រើ ជម្រើសផ្នែកបុរាណ ដោយផ្អែកលើការចែកចាយតម្លៃវាល (តាមរយៈគន្លឹះ និងមរតក ឬ PARTITION BY) និង "ដោយដៃ" នៅកម្រិតកម្មវិធី អ្នកនឹងសម្គាល់ឃើញថាតម្លៃនៃ partitioning key ត្រូវបានរក្សាទុកក្នុងឈ្មោះតារាងខ្លួនឯងរួចហើយ។

ដូច្នេះប្រសិនបើអ្នកគឺដូច្នេះ តើ​អ្នក​មាន​ការ​ព្រួយ​បារម្ភ​យ៉ាង​ខ្លាំង​អំពី​ចំនួន​នៃ​ទិន្នន័យ​ដែល​បាន​រក្សា​ទុក​?បន្ទាប់មក អ្នកអាចកម្ចាត់វាល "បន្ថែម" ទាំងនេះ និងអាសយដ្ឋានតារាងជាក់លាក់។ ពិត ការជ្រើសរើសទាំងអស់ពីផ្នែកជាច្រើនក្នុងករណីនេះនឹងត្រូវផ្ទេរទៅផ្នែកកម្មវិធី។

ប្រភព: www.habr.com