மெசஞ்சர் தரவுத்தளம் (பகுதி 2): "லாபத்திற்காக" பகிர்வு

கடிதங்களைச் சேமிப்பதற்காக எங்கள் PostgreSQL தரவுத்தளத்தின் கட்டமைப்பை வெற்றிகரமாக வடிவமைத்துள்ளோம், ஒரு வருடம் கடந்துவிட்டது, பயனர்கள் அதை தீவிரமாக நிரப்புகிறார்கள், இப்போது அதில் உள்ளது மில்லியன் கணக்கான பதிவுகள், மற்றும்... ஏதோ மெதுவாக தொடங்கியது.

• பகுதி 1: அடிப்படை சட்டத்தை வடிவமைத்தல்
• பகுதி 2: "லாபத்திற்காக" பிரிவு

புள்ளி ஆகிறது அட்டவணை அளவு வளரும் போது, ​​குறியீடுகளின் "ஆழம்" அதிகரிக்கும். - மடக்கையாக இருந்தாலும். ஆனால் காலப்போக்கில் இது அதே படிக்க/எழுதுதல் பணிகளைச் செய்ய சர்வரை கட்டாயப்படுத்துகிறது பல மடங்கு அதிகமான பக்கங்களைச் செயலாக்குகிறதுஆரம்பத்தில் இருந்ததை விட.

இது மீட்புக்கு வருகிறது பிரித்தல்.

நாம் பகிர்வதைப் பற்றி பேசவில்லை, அதாவது வெவ்வேறு தரவுத்தளங்கள் அல்லது சேவையகங்களுக்கு இடையில் தரவை விநியோகிக்கிறோம் என்பதை நான் கவனிக்கிறேன். ஏனெனில் தரவுகளை பிரிப்பதும் கூட பல சேவையகங்கள், காலப்போக்கில் குறியீட்டு "வீக்கம்" சிக்கலில் இருந்து நீங்கள் விடுபட மாட்டீர்கள். ஒவ்வொரு நாளும் ஒரு புதிய சேவையகத்தை இயக்குவதற்கு உங்களால் முடிந்தால், உங்கள் சிக்கல்கள் ஒரு குறிப்பிட்ட தரவுத்தளத்தின் விமானத்தில் இனி இருக்காது என்பது தெளிவாகிறது.

"வன்பொருளில்" பகிர்வை செயல்படுத்துவதற்கான குறிப்பிட்ட ஸ்கிரிப்ட்களை நாங்கள் கருத்தில் கொள்வோம், ஆனால் அணுகுமுறையே - என்ன, எப்படி "துண்டுகளாக வெட்டப்பட வேண்டும்", அத்தகைய ஆசை எதற்கு வழிவகுக்கிறது.

கருத்து

நமது இலக்கை மீண்டும் ஒருமுறை வரையறுப்போம்: இன்று, நாளை மற்றும் ஒரு வருடத்தில், எந்த வாசிப்பு/எழுதுதல் செயல்பாட்டின் போதும் PostgreSQL ஆல் படிக்கப்படும் தரவுகளின் அளவு ஏறக்குறைய ஒரே மாதிரியாக இருப்பதை உறுதிசெய்ய விரும்புகிறோம்.

எதற்கும் காலவரிசைப்படி திரட்டப்பட்ட தரவு (செய்திகள், ஆவணங்கள், பதிவுகள், காப்பகங்கள், ...) பகிர்வு விசையாக இயற்கையான தேர்வு நிகழ்வு தேதி/நேரம். எங்கள் விஷயத்தில், அத்தகைய நிகழ்வு செய்தியை அனுப்பும் தருணம்.

பயனர்கள் எப்போதும் என்பதை நினைவில் கொள்க "சமீபத்திய"வற்றுடன் மட்டுமே வேலை செய்யுங்கள் அத்தகைய தரவு - அவர்கள் சமீபத்திய செய்திகளைப் படிக்கிறார்கள், சமீபத்திய பதிவுகளை பகுப்பாய்வு செய்கிறார்கள்,... இல்லை, நிச்சயமாக, அவர்கள் காலப்போக்கில் மேலும் பின்னோக்கிச் செல்லலாம், ஆனால் அவர்கள் இதை மிகவும் அரிதாகவே செய்கிறார்கள்.

இந்தக் கட்டுப்பாடுகளில் இருந்து, சிறந்த செய்தி தீர்வாக இருக்கும் என்பது தெளிவாகிறது "தினசரி" பிரிவுகள் - எல்லாவற்றிற்கும் மேலாக, எங்கள் பயனர் "இன்று" அல்லது "நேற்று" தனக்கு வந்ததை எப்போதும் படிப்பார்.

பகலில் கிட்டத்தட்ட ஒரு பகுதியில் மட்டும் எழுதிப் படித்தால், இதுவும் நமக்குத் தருகிறது நினைவகம் மற்றும் வட்டின் திறமையான பயன்பாடு - அனைத்து பிரிவு குறியீடுகளும் ரேமில் எளிதில் பொருந்துவதால், அட்டவணை முழுவதிலும் உள்ள "பெரிய மற்றும் கொழுப்பு" க்கு மாறாக.

படி படியாக

பொதுவாக, மேலே கூறப்பட்ட அனைத்தும் ஒரு தொடர்ச்சியான லாபம் போல் தெரிகிறது. இது அடையக்கூடியது, ஆனால் இதற்காக நாம் கடினமாக முயற்சி செய்ய வேண்டும் - ஏனென்றால் நிறுவனங்களில் ஒன்றைப் பிரிப்பதற்கான முடிவு, அதனுடன் தொடர்புடையவற்றை "பார்க்க" வேண்டிய அவசியத்திற்கு வழிவகுக்கிறது.

செய்தி, அதன் பண்புகள் மற்றும் கணிப்புகள்

செய்திகளை தேதிகளின்படி குறைக்க முடிவு செய்ததால், அவற்றைச் சார்ந்திருக்கும் (இணைக்கப்பட்ட கோப்புகள், பெறுநர்களின் பட்டியல்) மற்றும் செய்தியின் தேதியிலும்.

எங்களின் வழக்கமான பணிகளில் ஒன்று செய்திப் பதிவேடுகளைத் துல்லியமாகப் பார்ப்பதால் (படிக்காதது, உள்வரும், அனைத்தும்), செய்தித் தேதிகளின்படி பகிர்வதில் "அவற்றை இழுப்பது" தர்க்கரீதியானது.

அனைத்து அட்டவணைகளிலும் பகிர்வு விசையை (செய்தி தேதி) சேர்க்கிறோம்: பெறுநர்கள், கோப்பு, பதிவேடுகள். நீங்கள் அதை செய்தியில் சேர்க்க வேண்டியதில்லை, ஆனால் ஏற்கனவே உள்ள தேதி நேரத்தைப் பயன்படுத்தவும்.

இழைகள்

பல செய்திகளுக்கு ஒரே தலைப்பு இருப்பதால், அதை ஒரே மாதிரியில் "கட்" செய்ய வழி இல்லை; நீங்கள் வேறு எதையாவது நம்பியிருக்க வேண்டும். எங்கள் விஷயத்தில் இது சிறந்தது கடிதத்தில் முதல் செய்தியின் தேதி - அதாவது, படைப்பின் தருணம், உண்மையில், தலைப்பின்.

அனைத்து அட்டவணைகளிலும் பகிர்வு விசையை (தலைப்பு தேதி) சேர்க்கவும்: தலைப்பு, பங்கேற்பாளர்.

ஆனால் இப்போது நமக்கு ஒரே நேரத்தில் இரண்டு சிக்கல்கள் உள்ளன:

• தலைப்பில் செய்திகளை நான் எந்தப் பிரிவில் தேட வேண்டும்?
• செய்தியிலிருந்து எந்தப் பிரிவில் தலைப்பைப் பார்க்க வேண்டும்?

நிச்சயமாக, எல்லாப் பிரிவுகளிலும் நாம் தேடுவதைத் தொடரலாம், ஆனால் இது மிகவும் வருத்தமாக இருக்கும், மேலும் நமது வெற்றிகள் அனைத்தையும் மறுத்துவிடும். எனவே, சரியாக எங்கு பார்க்க வேண்டும் என்பதை அறிய, பிரிவுகளுக்கு தருக்க இணைப்புகள்/சுட்டிகளை உருவாக்குவோம்:

• செய்தியில் சேர்ப்போம் தலைப்பு தேதி புலம்
• தலைப்பில் சேர்ப்போம் செய்தி தேதி அமைக்கப்பட்டது இந்த கடிதம் (ஒரு தனி அட்டவணையாக இருக்கலாம் அல்லது தேதிகளின் வரிசையாக இருக்கலாம்)

ஒவ்வொரு தனிப்பட்ட கடிதத்திற்கும் செய்தி தேதிகளின் பட்டியலில் சில மாற்றங்கள் இருக்கும் என்பதால் (எல்லாவற்றிற்கும் மேலாக, கிட்டத்தட்ட எல்லா செய்திகளும் 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