Messenger දත්ත සමුදාය (2 කොටස): "ලාභය සඳහා" කොටස් කිරීම

ලිපි හුවමාරුව ගබඩා කිරීම සඳහා අපගේ PostgreSQL දත්ත සමුදායේ ව්‍යුහය අපි සාර්ථකව නිර්මාණය කර ඇත, වසරක් ගත වී ඇත, පරිශීලකයින් එය සක්‍රියව පුරවමින් සිටින අතර දැන් එහි අඩංගු වේ මිලියන ගණනක් වාර්තා, හා... යමක් මන්දගාමී වීමට පටන් ගත්තේය.

• 1 කොටස: මූලික රාමුව සැලසුම් කිරීම
• 2 කොටස: "ලාභය සඳහා" කොටස් කිරීම

කාරණය එයයි මේසයේ ප්රමාණය වර්ධනය වන විට, දර්ශකවල "ගැඹුර" වැඩි වේ. - ලඝුගණක වශයෙන් වුවද. නමුත් කාලයත් සමඟම මෙම සේවාදායකයට කියවීමට/ලිවීමට සමාන කාර්යයන් සිදු කිරීමට බල කරයි දත්ත පිටු ගණනකට වඩා වැඩි ප්‍රමාණයක් සකසන්නආරම්භයට වඩා.

ගලවා ගැනීම සඳහා පැමිණෙන්නේ මෙයයි කොටස් කිරීම.

අපි කතා කරන්නේ බෙදා හැරීම, එනම් විවිධ දත්ත සමුදායන් හෝ සේවාදායකයන් අතර දත්ත බෙදා හැරීම ගැන නොවන බව මම සටහන් කරමි. දත්ත පවා බෙදීම නිසා කිහිපයක් ඇත සේවාදායකයන්, කාලයත් සමඟ දර්ශක “ඉදිමීමේ” ගැටලුවෙන් ඔබ මිදෙන්නේ නැත. සෑම දිනකම නව සේවාදායකයක් ක්‍රියාත්මක කිරීමට ඔබට හැකි නම්, ඔබේ ගැටළු තවදුරටත් නිශ්චිත දත්ත සමුදායක තලයේ නොසිටින බව පැහැදිලිය.

අපි සලකා බලන්නේ “දෘඪාංගයේ” කොටස් කිරීම ක්‍රියාත්මක කිරීම සඳහා නිශ්චිත ස්ක්‍රිප්ට් නොව, ප්‍රවේශයමයි - “පෙති වලට කපා” ගත යුත්තේ කුමක්ද සහ කෙසේද සහ එවැනි ආශාවක් ඇති කරන්නේ කුමක්ද යන්නයි.

සංකල්පය

අපි නැවත වරක් අපගේ ඉලක්කය නිර්වචනය කරමු: අද, හෙට සහ වසරක් තුළ, ඕනෑම කියවීමේ/ලිවීමේ මෙහෙයුමකදී PostgreSQL විසින් කියවන ලද දත්ත ප්‍රමාණය දළ වශයෙන් සමානව පවතින බව සහතික කර ගැනීමට අපට අවශ්‍යය.

ඕනෑම දෙයක් සඳහා කාලානුක්‍රමිකව සමුච්චිත දත්ත (පණිවිඩ, ලේඛන, ලඝු-සටහන්, ලේඛනාගාර, ...) කොටස් කිරීමේ යතුරක් ලෙස ස්වාභාවික තේරීම වේ සිදුවීම් දිනය/වේලාව. අපගේ නඩුවේදී, එවැනි සිදුවීමක් වේ පණිවිඩය යැවීමේ මොහොත.

පරිශීලකයන් සෑම විටම පාහේ බව සලකන්න "නවතම" අය සමඟ පමණක් වැඩ කරන්න එවැනි දත්ත - ඔවුන් නවතම පණිවිඩ කියවයි, නවතම ලඝු-සටහන් විශ්ලේෂණය කරයි,... නැත, ඇත්ත වශයෙන්ම, ඔවුන්ට කාලය තුළ තව දුරටත් අනුචලනය කළ හැකිය, නමුත් ඔවුන් මෙය කරන්නේ ඉතා කලාතුරකිනි.

මෙම සීමාවන්ගෙන් ප්‍රශස්ත පණිවිඩ විසඳුම වනු ඇති බව පැහැදිලිය "දිනපතා" කොටස් - සියල්ලට පසු, අපගේ පරිශීලකයා සෑම විටම පාහේ "අද" හෝ "ඊයේ" ඔහුට පැමිණි දේ කියවනු ඇත.

අපි දිවා කාලයේ එක් කොටසක පමණක් ලිවීමට සහ කියවන්නේ නම්, මෙයද අපට ලබා දෙයි මතකය සහ තැටිය වඩාත් කාර්යක්ෂමව භාවිතා කිරීම - සියලුම කොටස් දර්ශක පහසුවෙන් RAM එකට ගැලපෙන බැවින්, මේසය පුරා ඇති "විශාල සහ මේදය" ඒවාට වඩා වෙනස්ව.

පියවරෙන් පියවර

පොදුවේ ගත් කල, ඉහත කී සෑම දෙයක්ම අඛණ්ඩ ලාභයක් ලෙස පෙනේ. එය සාක්ෂාත් කරගත හැකි නමුත් මේ සඳහා අපට දැඩි උත්සාහයක් දැරීමට සිදුවනු ඇත - මන්ද එක් ආයතනයක් කොටස් කිරීමට තීරණය කිරීම සම්බන්ධිත "දුටු" අවශ්යතාවයට මග පාදයි.

පණිවිඩය, එහි ගුණාංග සහ ප්රක්ෂේපණ

අපි දිනයන් අනුව පණිවිඩ කපා හැරීමට තීරණය කළ බැවින්, ඒවා මත යැපෙන ආයතන-ගුණාංග බෙදීම අර්ථවත් කරයි (අමුණූ ගොනු, ලබන්නන්ගේ ලැයිස්තුව) සහ පණිවිඩයේ දිනය අනුවද.

අපගේ සාමාන්‍ය කර්තව්‍යයන්ගෙන් එකක් වන්නේ පණිවිඩ ලේඛන නිවැරදිව බැලීම (කියවා නැති, එන, සියල්ල), පණිවිඩ දිනයන් අනුව කොටස් කිරීමට “ඒවා ඇද ගැනීම” තාර්කික ය.

අපි සියලුම වගු වලට කොටස් කිරීමේ යතුර (පණිවිඩ දිනය) එකතු කරමු: ලබන්නන්, ගොනුව, රෙජිස්ට්‍රි. ඔබට එය පණිවිඩයටම එකතු කිරීමට අවශ්‍ය නැත, නමුත් පවතින DateTime භාවිතා කරන්න.

නූල්

පණිවිඩ කිහිපයක් සඳහා එක් මාතෘකාවක් පමණක් ඇති බැවින්, එය එකම ආකෘතියේ "කපා" කිරීමට ක්රමයක් නොමැත; ඔබට වෙනත් දෙයක් මත විශ්වාසය තැබිය යුතුය. අපගේ නඩුවේදී එය පරිපූර්ණයි ලිපි හුවමාරුවේ පළමු පණිවිඩයේ දිනය - එනම්, මැවීමේ මොහොත, ඇත්ත වශයෙන්ම, මාතෘකාව.

සියලුම වගු වලට කොටස් කිරීමේ යතුර (මාතෘකා දිනය) එක් කරන්න: මාතෘකාව, සහභාගිවන්නා.

නමුත් දැන් අපට එකවර ගැටලු දෙකක් තිබේ:

• මා මාතෘකාව පිළිබඳ පණිවිඩ සෙවිය යුත්තේ කුමන කොටසෙහිද?
• පණිවිඩයෙන් මා මාතෘකාව සෙවිය යුත්තේ කුමන කොටසෙහිද?

ඇත්ත වශයෙන්ම, අපට සියලු අංශවල සෙවීම දිගටම කරගෙන යා හැකිය, නමුත් මෙය ඉතා කණගාටුදායක වන අතර අපගේ සියලු ජයග්‍රහණ ප්‍රතික්ෂේප කරනු ඇත. එබැවින්, හරියටම බැලිය යුත්තේ කොතැනදැයි දැන ගැනීම සඳහා, අපි කොටස් වෙත තාර්කික සබැඳි/පොයින්ටර් සාදන්නෙමු:

• අපි පණිවිඩයට එකතු කරන්නෙමු මාතෘකාව දින ක්ෂේත්රය
• අපි මාතෘකාවට එකතු කරමු පණිවිඩ දිනය සකසා ඇත මෙම ලිපි හුවමාරුව (වෙනම වගුවක් හෝ දින මාලාවක් විය හැක)

එක් එක් ලිපි හුවමාරුව සඳහා පණිවිඩ දින ලැයිස්තුවේ වෙනස් කිරීම් කිහිපයක් ඇති බැවින් (සියල්ලට පසු, සියලුම පණිවිඩ පාහේ යාබද දින 1-2 කට වැටේ), මම මෙම විකල්පය කෙරෙහි අවධානය යොමු කරමි.

සමස්තයක් වශයෙන්, කොටස් කිරීම සැලකිල්ලට ගනිමින් අපගේ දත්ත සමුදායේ ව්‍යුහය පහත දැක්වෙන ස්වරූපය ගත්තේය:

වගු: RU, ඔබට වගු/ක්ෂේත්‍රවල නම්වල සිරිලික් හෝඩියට පිළිකුලක් තිබේ නම්, නොබැලීම වඩා හොඳය.

-- секции по дате сообщения
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
);

ලස්සන සතයක් ඉතිරි කරන්න

හොඳයි, අපි භාවිතා නොකරන්නේ නම් කුමක් කළ යුතුද? සම්භාව්ය කොටස් විකල්පය ක්ෂේත්‍ර අගයන් බෙදා හැරීම මත පදනම්ව (ප්‍රේරක සහ උරුමය හෝ කොටස් මගින්), සහ යෙදුම් මට්ටමින් “අතින්”, කොටස් කිරීමේ යතුරේ අගය දැනටමත් වගුවේ නමේම ගබඩා කර ඇති බව ඔබට පෙනෙනු ඇත.

ඉතින් ඔබ එසේ නම් ගබඩා කර ඇති දත්ත ප්‍රමාණය ගැන ඔබ කනස්සල්ලට පත්ව සිටිනවාද?, එවිට ඔබට මෙම "අතිරේක" ක්ෂේත්ර ඉවත් කර විශේෂිත වගු ඇමතීමට හැකිය. ඇත්ත, මෙම නඩුවේ කොටස් කිහිපයකින් සියලුම තේරීම් යෙදුම් පැත්තට මාරු කිරීමට සිදුවනු ඇත.

මූලාශ්රය: www.habr.com