മെസഞ്ചർ ഡാറ്റാബേസ് (ഭാഗം 2): "ലാഭത്തിനായി" പാർട്ടീഷനിംഗ്

കത്തിടപാടുകൾ സംഭരിക്കുന്നതിനായി ഞങ്ങളുടെ PostgreSQL ഡാറ്റാബേസിന്റെ ഘടന ഞങ്ങൾ വിജയകരമായി രൂപകൽപ്പന ചെയ്തിട്ടുണ്ട്, ഒരു വർഷം കഴിഞ്ഞു, ഉപയോക്താക്കൾ അത് സജീവമായി പൂരിപ്പിക്കുന്നു, ഇപ്പോൾ അതിൽ അടങ്ങിയിരിക്കുന്നു ദശലക്ഷക്കണക്കിന് റെക്കോർഡുകൾ, ഒപ്പം... ഒന്ന് പതുക്കെ തുടങ്ങി.

• ഭാഗം 1: അടിസ്ഥാന ഫ്രെയിം രൂപകൽപ്പന ചെയ്യുന്നു
• ഭാഗം 2: "ലാഭത്തിനുവേണ്ടി" എന്ന വിഭാഗം

പോയിന്റ് എന്നതാണ് പട്ടികയുടെ വലുപ്പം വർദ്ധിക്കുന്നതിനനുസരിച്ച്, സൂചികകളുടെ "ആഴം" വർദ്ധിക്കുന്നു. - ലോഗരിതമാണെങ്കിലും. എന്നാൽ കാലക്രമേണ, ഇത് അതേ വായന/എഴുത്ത് ജോലികൾ ചെയ്യാൻ സെർവറിനെ പ്രേരിപ്പിക്കുന്നു ഡാറ്റയുടെ പല മടങ്ങ് കൂടുതൽ പേജുകൾ പ്രോസസ്സ് ചെയ്യുകതുടക്കത്തേക്കാൾ.

ഇവിടെയാണ് ഇത് രക്ഷാപ്രവർത്തനത്തിലേക്ക് വരുന്നത് വിഭജനം.

ഞങ്ങൾ സംസാരിക്കുന്നത് ഷാർഡിംഗിനെക്കുറിച്ചല്ല, അതായത്, വ്യത്യസ്ത ഡാറ്റാബേസുകൾ അല്ലെങ്കിൽ സെർവറുകൾക്കിടയിൽ ഡാറ്റ വിതരണം ചെയ്യുന്നതിനെക്കുറിച്ച്. കാരണം ഡാറ്റയെ വിഭജിക്കുന്നത് പോലും പലതും സെർവറുകൾ, കാലക്രമേണ സൂചികകളുടെ "വീക്കം" എന്ന പ്രശ്നത്തിൽ നിന്ന് നിങ്ങൾക്ക് മുക്തി നേടാനാവില്ല. എല്ലാ ദിവസവും ഒരു പുതിയ സെർവർ പ്രവർത്തനക്ഷമമാക്കാൻ നിങ്ങൾക്ക് കഴിയുമെങ്കിൽ, നിങ്ങളുടെ പ്രശ്നങ്ങൾ ഒരു നിർദ്ദിഷ്ട ഡാറ്റാബേസിന്റെ തലത്തിൽ ഇനി ഉണ്ടാകില്ല എന്നത് വ്യക്തമാണ്.

“ഹാർഡ്‌വെയറിൽ” പാർട്ടീഷനിംഗ് നടപ്പിലാക്കുന്നതിനുള്ള നിർദ്ദിഷ്ട സ്‌ക്രിപ്റ്റുകളല്ല ഞങ്ങൾ പരിഗണിക്കുന്നത്, മറിച്ച് സമീപനം തന്നെ - എന്ത്, എങ്ങനെ “സ്ലൈസുകളായി മുറിക്കണം”, അത്തരമൊരു ആഗ്രഹം എന്തിലേക്ക് നയിക്കുന്നു.

ആശയം

നമുക്ക് ഒരിക്കൽ കൂടി നമ്മുടെ ലക്ഷ്യം നിർവചിക്കാം: ഇന്നും, നാളെയും, ഒരു വർഷവും, ഏതെങ്കിലും റീഡ്/റൈറ്റ് ഓപ്പറേഷൻ സമയത്ത് PostgreSQL വായിക്കുന്ന ഡാറ്റയുടെ അളവ് ഏകദേശം ഒരേ പോലെ തന്നെ നിലനിൽക്കുമെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ഏതിനും കാലക്രമത്തിൽ ശേഖരിച്ച ഡാറ്റ (സന്ദേശങ്ങൾ, പ്രമാണങ്ങൾ, ലോഗുകൾ, ആർക്കൈവുകൾ, ...) ഒരു പാർട്ടീഷനിംഗ് കീ എന്ന നിലയിൽ സ്വാഭാവിക തിരഞ്ഞെടുപ്പ് ഇവന്റ് തീയതി/സമയം. ഞങ്ങളുടെ കാര്യത്തിൽ, അത്തരമൊരു സംഭവം സന്ദേശം അയയ്ക്കുന്ന നിമിഷം.

ഉപയോക്താക്കൾ മിക്കവാറും എപ്പോഴും ശ്രദ്ധിക്കുക "ഏറ്റവും പുതിയവ" ഉപയോഗിച്ച് മാത്രം പ്രവർത്തിക്കുക അത്തരം ഡാറ്റ - അവർ ഏറ്റവും പുതിയ സന്ദേശങ്ങൾ വായിക്കുന്നു, ഏറ്റവും പുതിയ ലോഗുകൾ വിശകലനം ചെയ്യുന്നു,... ഇല്ല, തീർച്ചയായും, അവർക്ക് കൂടുതൽ സമയം പിന്നോട്ട് സ്ക്രോൾ ചെയ്യാൻ കഴിയും, പക്ഷേ അവർ ഇത് വളരെ അപൂർവമായി മാത്രമേ ചെയ്യുന്നുള്ളൂ.

ഈ നിയന്ത്രണങ്ങളിൽ നിന്ന് ഒപ്റ്റിമൽ മെസേജ് സൊല്യൂഷൻ ആയിരിക്കും എന്ന് വ്യക്തമാണ് "പ്രതിദിന" വിഭാഗങ്ങൾ - എല്ലാത്തിനുമുപരി, ഞങ്ങളുടെ ഉപയോക്താവ് “ഇന്ന്” അല്ലെങ്കിൽ “ഇന്നലെ” തനിക്ക് വന്നതെന്താണെന്ന് എല്ലായ്പ്പോഴും വായിക്കും.

പകൽ സമയത്ത് ഒരു വിഭാഗത്തിൽ മാത്രം എഴുതുകയും വായിക്കുകയും ചെയ്താൽ, ഇതും നമുക്ക് നൽകുന്നു മെമ്മറിയുടെയും ഡിസ്കിന്റെയും കൂടുതൽ കാര്യക്ഷമമായ ഉപയോഗം - എല്ലാ വിഭാഗ സൂചികകളും റാമിലേക്ക് എളുപ്പത്തിൽ യോജിക്കുന്നതിനാൽ, പട്ടികയിലുടനീളമുള്ള “വലിയതും തടിച്ചതുമായ”തിൽ നിന്ന് വ്യത്യസ്തമായി.

പടി പടിയായി

പൊതുവേ, മുകളിൽ പറഞ്ഞതെല്ലാം തുടർച്ചയായ ലാഭം പോലെയാണ്. ഇത് കൈവരിക്കാനാകും, പക്ഷേ ഇതിനായി ഞങ്ങൾ കഠിനമായി ശ്രമിക്കേണ്ടതുണ്ട് - കാരണം എന്റിറ്റികളിലൊന്നിനെ വിഭജിക്കാനുള്ള തീരുമാനം ബന്ധപ്പെട്ടവയെ "കാണുക" എന്നതിന്റെ ആവശ്യകതയിലേക്ക് നയിക്കുന്നു.

സന്ദേശം, അതിന്റെ ഗുണങ്ങളും പ്രൊജക്ഷനുകളും

തീയതികൾ അനുസരിച്ച് സന്ദേശങ്ങൾ വെട്ടിക്കുറയ്ക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചതിനാൽ, അവയെ ആശ്രയിക്കുന്ന (അറ്റാച്ചുചെയ്ത ഫയലുകൾ, സ്വീകർത്താക്കളുടെ പട്ടിക) എന്റിറ്റികൾ-പ്രോപ്പർട്ടികൾ വിഭജിക്കുന്നതിൽ അർത്ഥമുണ്ട്. സന്ദേശത്തിന്റെ തീയതി പ്രകാരം.

ഞങ്ങളുടെ സാധാരണ ടാസ്‌ക്കുകളിൽ ഒന്ന് സന്ദേശ രജിസ്റ്ററുകൾ (വായിക്കാത്തവ, ഇൻകമിംഗ്, എല്ലാം) കൃത്യമായി കാണുന്നതിനാൽ, സന്ദേശ തീയതികൾ അനുസരിച്ച് പാർട്ടീഷനിലേക്ക് "അവയെ വലിച്ചിടുക" എന്നത് യുക്തിസഹമാണ്.

എല്ലാ പട്ടികകളിലേക്കും ഞങ്ങൾ പാർട്ടീഷനിംഗ് കീ (സന്ദേശ തീയതി) ചേർക്കുന്നു: സ്വീകർത്താക്കൾ, ഫയൽ, രജിസ്ട്രികൾ. നിങ്ങൾ അത് സന്ദേശത്തിലേക്ക് തന്നെ ചേർക്കേണ്ടതില്ല, എന്നാൽ നിലവിലുള്ള 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