የሜሴንጀር ዳታቤዝ (ክፍል 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
);

ቆንጆ ሳንቲም ያስቀምጡ

ደህና, ብንጠቀምስ ክላሲክ ክፍፍል. በመስክ እሴቶች ስርጭት (በቀስቃሽ እና ውርስ ወይም ክፍል በ) ላይ በመመስረት ፣ ግን “በእጅ” በመተግበሪያው ደረጃ ፣ የመከፋፈያ ቁልፍ ዋጋ ቀድሞውኑ በሠንጠረዡ ስም ውስጥ እንደተከማች ማየት ይችላሉ።

ስለዚህ እንደዚያ ከሆንክ የተከማቸ የውሂብ መጠን በጣም ይጨነቃሉ, ከዚያ እነዚህን "ተጨማሪ" መስኮችን እና አድራሻውን በተለይም የተወሰኑ ጠረጴዛዎችን ማስወገድ ይችላሉ. እውነት ነው, በዚህ ጉዳይ ላይ ከበርካታ ክፍሎች የተውጣጡ ሁሉም ምርጫዎች ቀድሞውኑ ወደ ማመልከቻው ጎን መተላለፍ አለባቸው.

ምንጭ: hab.com