Cronfa ddata Messenger (rhan 2): rhannu "er elw"

Rydym wedi dylunio strwythur ein cronfa ddata PostgreSQL yn llwyddiannus ar gyfer storio gohebiaeth, mae blwyddyn wedi mynd heibio, mae defnyddwyr wrthi'n ei llenwi, ac erbyn hyn mae'n cynnwys miliynau o gofnodion, a... dechreuodd rhywbeth arafu.

• Rhan 1: dylunio'r ffrâm sylfaen
• Rhan 2: adranu “er elw”

Ffaith yw bod Wrth i faint y tabl dyfu, felly hefyd “dyfnder” y mynegeion. - er yn logarithmig. Ond dros amser mae hyn yn gorfodi'r gweinydd i gyflawni'r un tasgau darllen/ysgrifennu prosesu llawer mwy o dudalennau o ddatanag ar y dechreu.

Dyma lle mae'n dod i'r adwy adranu.

Gadewch imi nodi nad ydym yn sôn am rannu, hynny yw, dosbarthu data rhwng gwahanol gronfeydd data neu weinyddion. Oherwydd hyd yn oed rhannu'r data yn rhai gweinyddwyr, ni fyddwch yn cael gwared ar y broblem o fynegeion “chwyddo” dros amser. Mae'n amlwg, os gallwch chi fforddio rhoi gweinydd newydd ar waith bob dydd, yna ni fydd eich problemau bellach yn gorwedd o gwbl yn awyren cronfa ddata benodol.

Byddwn yn ystyried nid sgriptiau penodol ar gyfer gweithredu rhaniad “mewn caledwedd”, ond y dull ei hun - beth a sut y dylid ei “dorri'n dafelli”, a beth mae awydd o'r fath yn arwain ato.

Cysyniad

Gadewch i ni ddiffinio ein nod unwaith eto: rydym am sicrhau heddiw, yfory, ac mewn blwyddyn, bod swm y data a ddarllenir gan PostgreSQL yn ystod unrhyw weithrediad darllen / ysgrifennu yn aros tua'r un peth.

Ar gyfer unrhyw data cronolegol cronolegol (negeseuon, dogfennau, logiau, archifau, ...) y dewis naturiol fel allwedd rhaniad yw dyddiad/amser digwyddiad. Yn ein hachos ni, digwyddiad o'r fath yw eiliad o anfon y neges.

Sylwch fod defnyddwyr bron bob amser gweithio gyda'r rhai “diweddaraf” yn unig data o'r fath - maent yn darllen y negeseuon diweddaraf, yn dadansoddi'r logiau diweddaraf, ... Na, wrth gwrs, gallant sgrolio ymhellach yn ôl mewn amser, ond anaml iawn y maent yn gwneud hyn.

O'r cyfyngiadau hyn mae'n amlwg mai'r ateb neges gorau fyddai adrannau "dyddiol". - wedi'r cyfan, bydd ein defnyddiwr bron bob amser yn darllen yr hyn a ddaeth iddo "heddiw" neu "ddoe".

Os ydym yn ysgrifennu ac yn darllen bron dim ond mewn un adran yn ystod y dydd, yna mae hyn hefyd yn rhoi i ni defnydd mwy effeithlon o gof a disg - gan fod mynegeion pob adran yn ffitio'n hawdd i'r RAM, mewn cyferbyniad â'r rhai “mawr a thew” trwy'r bwrdd.

cam-wrth-gam

Yn gyffredinol, mae popeth a ddywedir uchod yn swnio fel un elw parhaus. Ac mae'n gyraeddadwy, ond ar gyfer hyn bydd yn rhaid i ni ymdrechu'n galed - oherwydd mae'r penderfyniad i rannu un o'r endidau yn arwain at yr angen i “weld” yr endidau cysylltiedig.

Neges, ei briodweddau a rhagamcanion

Ers i ni benderfynu torri negeseuon yn ôl dyddiadau, mae'n gwneud synnwyr hefyd i rannu'r endidau-eiddo sy'n dibynnu arnynt (ffeiliau ynghlwm, rhestr o dderbynwyr), a hefyd yn ôl dyddiad y neges.

Gan mai un o'n tasgau nodweddiadol yw edrych ar gofrestrau negeseuon yn union (heb eu darllen, yn dod i mewn, i gyd), mae hefyd yn rhesymegol eu “tynnu i mewn” i rannu yn ôl dyddiadau negeseuon.

Rydym yn ychwanegu'r allwedd rhaniad (dyddiad neges) i bob tabl: derbynwyr, ffeil, cofrestrfeydd. Nid oes rhaid i chi ei ychwanegu at y neges ei hun, ond defnyddiwch y DateTime presennol.

Pynciau

Gan mai dim ond un pwnc sydd ar gyfer sawl neges, nid oes unrhyw ffordd i'w “dorri” yn yr un model; mae'n rhaid i chi ddibynnu ar rywbeth arall. Yn ein hachos ni, mae'n ddelfrydol dyddiad y neges gyntaf mewn gohebiaeth — hynny yw, moment creu, mewn gwirionedd, y pwnc.

Ychwanegwch yr allwedd rhaniad (dyddiad pwnc) i bob tabl: pwnc, cyfranogwr.

Ond nawr mae gennym ddwy broblem ar unwaith:

• Ym mha adran ddylwn i chwilio am negeseuon ar y pwnc?
• Ym mha adran ddylwn i chwilio am y pwnc o'r neges?

Gallwn, wrth gwrs, barhau i chwilio ym mhob adran, ond bydd hyn yn drist iawn ac yn negyddu ein holl enillion. Felly, er mwyn gwybod ble yn union i edrych, byddwn yn gwneud cysylltiadau/awgrymiadau rhesymegol i adrannau:

• byddwn yn ychwanegu'r neges maes dyddiad pwnc
• gadewch i ni ychwanegu at y pwnc gosod dyddiad neges yr ohebiaeth hon (gall fod yn dabl ar wahân, neu'n gyfres o ddyddiadau)

Gan na fydd llawer o addasiadau i'r rhestr o ddyddiadau negeseuon ar gyfer pob gohebiaeth unigol (wedi'r cyfan, mae bron pob neges yn disgyn ar 1-2 diwrnod cyfagos), byddaf yn canolbwyntio ar yr opsiwn hwn.

Yn gyfan gwbl, roedd strwythur ein cronfa ddata ar y ffurf ganlynol, gan gymryd rhaniad i ystyriaeth:

Tablau: RU, os oes gennych wrthwynebiad i'r wyddor Syrilig yn enwau tablau/caeau, mae'n well peidio ag edrych

-- секции по дате сообщения
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
);

Arbedwch geiniog bert

Wel, beth os na ddefnyddiwn ni opsiwn adranu clasurol yn seiliedig ar ddosbarthiad gwerthoedd maes (trwy sbardunau ac etifeddiaeth neu RHANNU GAN), a “â llaw” ar lefel y cais, byddwch yn sylwi bod gwerth yr allwedd rhannu eisoes wedi'i storio yn enw'r tabl ei hun.

Felly os ydych chi felly Ydych chi'n bryderus iawn am faint o ddata sy'n cael ei storio?, yna gallwch chi gael gwared ar y meysydd “ychwanegol” hyn a mynd i'r afael â thablau penodol. Yn wir, bydd yn rhaid i bob detholiad o sawl adran yn yr achos hwn gael ei drosglwyddo i ochr y cais.

Ffynhonnell: hab.com