મેસેન્જર ડેટાબેઝ (ભાગ 2): "નફા માટે" પાર્ટીશન

અમે પત્રવ્યવહાર સ્ટોર કરવા માટે અમારા PostgreSQL ડેટાબેઝનું માળખું સફળતાપૂર્વક ડિઝાઇન કર્યું છે, એક વર્ષ વીતી ગયું છે, વપરાશકર્તાઓ તેને સક્રિયપણે ભરી રહ્યાં છે, અને હવે તેમાં લાખો રેકોર્ડ, અને... કંઈક ધીમું થવા લાગ્યું.

• ભાગ 1: આધાર ફ્રેમ ડિઝાઇન
• ભાગ 2: "નફા માટે" વિભાગીકરણ

હકીકત એ છે કે જેમ જેમ ટેબલનું કદ વધતું જાય છે તેમ તેમ સૂચકાંકોની "ઊંડાઈ" પણ વધે છે. - લઘુગણકની રીતે હોવા છતાં. પરંતુ સમય જતાં આ સર્વરને સમાન વાંચન/લખવા કાર્યો કરવા દબાણ કરે છે ડેટાના અનેક ગણા વધુ પૃષ્ઠો પર પ્રક્રિયા કરોશરૂઆતમાં કરતાં.

આ તે છે જ્યાં તે બચાવમાં આવે છે વિભાગીકરણ.

મને નોંધ લેવા દો કે અમે શાર્ડિંગ વિશે વાત કરી રહ્યા નથી, એટલે કે, વિવિધ ડેટાબેઝ અથવા સર્વર્સ વચ્ચે ડેટાનું વિતરણ કરવું. કારણ કે તેમાં પણ ડેટાનું વિભાજન કેટલાક સર્વરો, તમે સમય જતાં ઇન્ડેક્સ "સોજો" ની સમસ્યાથી છુટકારો મેળવશો નહીં. તે સ્પષ્ટ છે કે જો તમે દરરોજ એક નવું સર્વર કાર્યરત કરવાનું પરવડી શકો છો, તો પછી તમારી સમસ્યાઓ હવે કોઈ ચોક્કસ ડેટાબેઝના પ્લેનમાં રહેતી નથી.

અમે "હાર્ડવેરમાં" પાર્ટીશનના અમલીકરણ માટે ચોક્કસ સ્ક્રિપ્ટો પર વિચારણા કરીશું નહીં, પરંતુ અભિગમ પોતે જ - શું અને કેવી રીતે "સ્લાઇસમાં કાપવા" જોઈએ, અને આવી ઇચ્છા શું તરફ દોરી જાય છે.

ખ્યાલ

ચાલો અમારા ધ્યેયને ફરી એકવાર વ્યાખ્યાયિત કરીએ: અમે ખાતરી કરવા માંગીએ છીએ કે આજે, આવતીકાલે અને એક વર્ષમાં, કોઈપણ વાંચવા/લેખવાની કામગીરી દરમિયાન PostgreSQL દ્વારા વાંચવામાં આવેલ ડેટાનો જથ્થો લગભગ સમાન રહે.

કોઈપણ માટે કાલક્રમિક રીતે સંચિત ડેટા (સંદેશાઓ, દસ્તાવેજો, લોગ્સ, આર્કાઇવ્સ, ...) પાર્ટીશન કી તરીકે કુદરતી પસંદગી છે ઘટના તારીખ/સમય. અમારા કિસ્સામાં, આવી ઘટના છે સંદેશ મોકલવાની ક્ષણ.

નોંધ કરો કે વપરાશકર્તાઓ લગભગ હંમેશા ફક્ત "નવીનતમ" સાથે કામ કરો આવા ડેટા - તેઓ નવીનતમ સંદેશાઓ વાંચે છે, નવીનતમ લૉગ્સનું વિશ્લેષણ કરે છે,... ના, અલબત્ત, તેઓ સમયસર વધુ પાછળ સ્ક્રોલ કરી શકે છે, પરંતુ તેઓ આ ખૂબ જ ભાગ્યે જ કરે છે.

આ અવરોધો પરથી તે સ્પષ્ટ છે કે શ્રેષ્ઠ સંદેશ ઉકેલ હશે "દૈનિક" વિભાગો - છેવટે, અમારા વપરાશકર્તા લગભગ હંમેશા વાંચશે કે તેને "આજે" અથવા "ગઈકાલે" શું આવ્યું છે.

જો આપણે દિવસ દરમિયાન લગભગ ફક્ત એક જ વિભાગમાં લખીએ અને વાંચીએ, તો આ પણ આપણને આપે છે મેમરી અને ડિસ્કનો વધુ કાર્યક્ષમ ઉપયોગ - કારણ કે તમામ વિભાગ સૂચકાંકો સરળતાથી RAM માં ફિટ થઈ જાય છે, સમગ્ર કોષ્ટકમાં "મોટા અને ચરબીવાળા" મુદ્દાઓથી વિપરીત.

ઉત્તરોત્તર

સામાન્ય રીતે, ઉપર જણાવેલ બધું એક સતત નફા જેવું લાગે છે. અને તે પ્રાપ્ત કરી શકાય તેવું છે, પરંતુ આ માટે આપણે સખત પ્રયાસ કરવો પડશે - કારણ કે એક એન્ટિટીને વિભાજિત કરવાનો નિર્ણય સંબંધિતને "જોયા" કરવાની જરૂરિયાત તરફ દોરી જાય છે.

સંદેશ, તેના ગુણધર્મો અને અંદાજો

અમે તારીખો પ્રમાણે સંદેશા કાપવાનું નક્કી કર્યું હોવાથી, તેના પર આધાર રાખતી એન્ટિટી-પ્રોપર્ટીઝ (જોડેલી ફાઇલો, પ્રાપ્તકર્તાઓની સૂચિ) ને પણ વિભાજિત કરવામાં અર્થપૂર્ણ છે. સંદેશની તારીખ દ્વારા પણ.

અમારા સામાન્ય કાર્યોમાંનું એક સંદેશ રજીસ્ટર (ન વાંચેલા, આવનારા, બધા) ચોક્કસ રીતે જોવાનું હોવાથી, સંદેશ તારીખો દ્વારા પાર્ટીશનમાં "તેમને દોરવા" એ પણ તાર્કિક છે.

અમે તમામ કોષ્ટકોમાં પાર્ટીશનીંગ કી (સંદેશ તારીખ) ઉમેરીએ છીએ: પ્રાપ્તકર્તાઓ, ફાઇલ, રજિસ્ટ્રીઝ. તમારે તેને મેસેજમાં જ ઉમેરવાની જરૂર નથી, પરંતુ હાલની તારીખ સમયનો ઉપયોગ કરો.

સૂત્રો

ઘણા સંદેશાઓ માટે ફક્ત એક જ વિષય હોવાથી, તેને સમાન મોડેલમાં "કટ" કરવાની કોઈ રીત નથી; તમારે બીજા કંઈક પર આધાર રાખવો પડશે. અમારા કિસ્સામાં તે આદર્શ છે પત્રવ્યવહારમાં પ્રથમ સંદેશની તારીખ - એટલે કે, બનાવટની ક્ષણ, હકીકતમાં, વિષયની.

બધા કોષ્ટકોમાં પાર્ટીશન કી (વિષય તારીખ) ઉમેરો: વિષય, સહભાગી.

પરંતુ હવે અમારી પાસે એક સાથે બે સમસ્યાઓ છે:

• કયા વિભાગમાં મારે વિષય પરના સંદેશાઓ જોવા જોઈએ?
• મારે કયા વિભાગમાં સંદેશમાંથી વિષય શોધવો જોઈએ?

અમે, અલબત્ત, તમામ વિભાગોમાં શોધ કરવાનું ચાલુ રાખી શકીએ છીએ, પરંતુ આ ખૂબ જ દુઃખદ હશે અને અમારી બધી જીતને નકારી કાઢશે. તેથી, બરાબર ક્યાં જોવું તે જાણવા માટે, અમે વિભાગોની લોજિકલ લિંક્સ/પોઇન્ટર્સ બનાવીશું:

• અમે સંદેશમાં ઉમેરીશું વિષય તારીખ ક્ષેત્ર
• ચાલો વિષયમાં ઉમેરીએ સંદેશ તારીખ સેટ આ પત્રવ્યવહાર (એક અલગ કોષ્ટક અથવા તારીખોની શ્રેણી હોઈ શકે છે)

દરેક વ્યક્તિગત પત્રવ્યવહાર માટે સંદેશની તારીખોની સૂચિમાં થોડા ફેરફારો કરવામાં આવશે (છેવટે, લગભગ તમામ સંદેશાઓ 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
);

એક સુંદર પૈસો બચાવો

સારું, જો આપણે ઉપયોગ ન કરીએ તો શું ક્લાસિક વિભાગીકરણ વિકલ્પ ફીલ્ડ મૂલ્યોના વિતરણના આધારે (ટ્રિગર્સ અને વારસા દ્વારા અથવા PARTITION BY દ્વારા), અને એપ્લિકેશન સ્તરે "મેન્યુઅલી", તમે જોશો કે પાર્ટીશન કીની કિંમત પહેલેથી જ કોષ્ટકના નામમાં સંગ્રહિત છે.

તેથી જો તમે આવા છો શું તમે સંગ્રહિત ડેટાની માત્રા વિશે ખૂબ ચિંતિત છો?, તો પછી તમે આ "વધારાની" ફીલ્ડ્સમાંથી છુટકારો મેળવી શકો છો અને ચોક્કસ કોષ્ટકોને સરનામું આપી શકો છો. સાચું છે, આ કિસ્સામાં કેટલાક વિભાગોમાંથી બધી પસંદગીઓ એપ્લિકેશન બાજુ પર સ્થાનાંતરિત કરવી પડશે.

સોર્સ: www.habr.com