మెసెంజర్ డేటాబేస్ (పార్ట్ 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
);

ఒక అందమైన పెన్నీ ఆదా చేయండి

సరే, మనం ఉపయోగించకపోతే ఏమి చేయాలి క్లాసిక్ సెక్షన్ ఎంపిక ఫీల్డ్ విలువల పంపిణీ (ట్రిగ్గర్‌లు మరియు వారసత్వం లేదా పార్టిషన్ ద్వారా) మరియు అప్లికేషన్ స్థాయిలో “మాన్యువల్‌గా” ఆధారంగా, విభజన కీ విలువ ఇప్పటికే పట్టిక పేరులోనే నిల్వ చేయబడిందని మీరు గమనించవచ్చు.

కాబట్టి మీరు అలా అయితే నిల్వ చేయబడిన డేటా మొత్తం గురించి మీరు చాలా ఆందోళన చెందుతున్నారా?, అప్పుడు మీరు ఈ "అదనపు" ఫీల్డ్‌లను వదిలించుకోవచ్చు మరియు నిర్దిష్ట పట్టికలను పరిష్కరించవచ్చు. నిజమే, ఈ సందర్భంలో అనేక విభాగాల నుండి అన్ని ఎంపికలు అప్లికేషన్ వైపుకు బదిలీ చేయబడాలి.

మూలం: www.habr.com