Messengeri andmebaas (osa 2): jaotame „reaalajas“

Meie PostgreSQL andmebaasi struktuur on edukalt projekteeritud suhtluse salvestamiseks. Aasta on möödunud, ja kasutajad täidavad seda aktiivselt, seal on juba miljoneid kirjeid, ja… midagi on hakanud veidi aeglaselt töötama.

• Osa 1: projekteerime andmebaasi karkassi
• Osa 2: sektsioneerime «elus»

Asi on selles, et koos tabeli mahu suurenemisega suureneb ka indeksite «sügavus» — kuigi logaritmiliselt. Kuid aja jooksul nõuab see serverilt sama lugemise/kirjutamise ülesande täitmiseks oluliselt rohkem andmelehti, kui alguses.

Siinkohal tuleb appi sektsioneerimine.

Tahan märkida, et teema ei ole sharding, see tähendab andmete jaotamine erinevate andmebaaside või serverite vahel. Sest isegi kui jagate andmed mitu serverite vahel, ei pääse te probleemi «indeksite paisumise» eest aja jooksul. Selge on, et kui saate endale lubada iga päev uue serveri kasutusele võtta, siis on teie probleemid juba hoopis teised kui konkreetse andmebaasi tasandil.

Keskendume mitte konkreetsetele skriptidele sektsioneerimise rakendamiseks «rauda», vaid lähenemisele — mida ja kuidas tuleks «tükeldada», ja milleni selline soov viib.

Kontseptsioon

Määratleme meie eesmärgi uuesti: tahame tagada, et nii täna, homme kui ka aasta pärast jääb PostgreSQL andmete loetavus igasuguste lugemise/kirjutamise operatsioonide puhul enam-vähem samaks.

Igasuguste ajalooliselt kogutud andmete (teated, dokumendid, logid, arhiivid, …) loomulikuks sektsioonivõtme valikuks on sündmuse kuupäev/aeg. Meie puhul on selliseks sündmuseks teate saatmise hetk.

Tuleb märkida, et kasutajad töötavad peaaegu alati ainult „viimastega” sellistest andmetest — nad lugesid viimaseid teateid, analüüsivad viimaseid logisid,… Loomulikult võivad nad kerida ka kauem tagasi, kuid nad teevad seda väga harva. selliste andmetega — loetakse viimaseid sõnumeid, analüüsitakse viimaseid logisid,… Ei, loomulikult saavad nad ka ajas tagasi kerida, kuid nad teevad seda väga harva.

Nendest piirangutest on ilmselge, et teate puhul on optimaalseks lahenduseks „päevased” sektsioonid — kuna meie kasutaja loeb peaaegu alati seda, mis on talle tulnud „täna” või „eile”.

Kui me kirjutame ja loeme päeva jooksul praktiliselt ainult ühes sektsioonis, siis annab see meile ka efektiivsema mälu ja ketta kasutuse. — kuna kõik sektsiooni indeksid mahuvad hõlpsasti operaatorisse, erinevalt 'suurtest ja paksudest' kogu tabelis.

samm-sammult

Üldiselt kõlab kõik eelnev kui üks pidev kasum. Ja see on saavutatav, kuid selle nimel peame korralikult pingutama — sest lahenduse sektsioneerimine ühe olendi jaoks toob kaasa vajaduse 'lõhkuda' seotud.

Teade, selle omadused ja projektsioonid

Kuna otsustasime jagada sõnumeid kuupäevade järgi, on mõistlik jagada ka nendega seotud olendi omadusi (lisatud failid, adressaatide loetelu), ja ka sõnumi kuupäeva järgi..

Kuna üks meie tüüpiline ülesanne on sõnumite registrite vaatamine (lugemata, sissetulevad, kõik), on loogiline, et tõmmata need ka sõnumite kuupäevade järgi sektsioneerimise alla.

Lisame sektsioneerimise võtme (sõnumi kuupäeva) kõikidesse tabelitesse: adressaadid, fail, registrid. Sõnumisse ei ole vaja lisada, vaid kasutada olemasolevat DateTime.

Teemad

Kuna teema on mitu sõnumit, siis ei ole seda samas mudelis võimalik 'lõhkuda', tuleb tugineda millelegi muule. Meie puhul sobib ideaalselt esimese sõnumi kuupäev vestluses — see on teema loomise hetk.

Lisame sektsioneerimise võtme (teema kuupäeva) kõigisse tabelitesse: teema, osaleja.

Kuid nüüd seisame silmitsi kahe probleemiga:

• millises sektsioonis otsida teema sõnumeid?
• millises sektsioonis otsida sõnumi teemat?

Muidugi, võiksime jätkata otsimist kõigis sektsioonides, kuid see oleks väga kurb ja kaotaks kõik meie saavutused. Seetõttu, et teada, kus konkreetselt otsida, loome loogilised lingid/viidatud sektsioonidesse:

• lisame sõnumisse teema kuupäeva välja
• lisame teemale sõnumite kuupäevade komplekti selle vestluse (saab eraldi tabelina või kuupäevade massiivina)

Kuna iga konkreetse vestluse sõnumite kuupäevade nimekirja modifikatsioonid jäävad väheseks (peaaegu kõik sõnumid satuvad 1-2 külgnevale päevale), eelistan just sellist varianti.

Kokkuvõtteks, meie andmebaasi struktuur omandas järgmise ilme sektsioneerimise arvesse võttes:

Tabelid: RU, kui viha on kirillitsa tabelite/valdkondade nimedes, siis parem mitte vaadata.

-- sektsioonid, mis põhinevad sõnumi kuupäeval
CREATE TABLE "Sõnum_YYYYMMDD"(
  "Sõnum"
    uuid
      PRIMARY KEY
, "Teema"
    uuid
, "TeemaKuupäev"
    date
, "Autor"
    uuid
, "KuupäevAeg" -- kasutame kuupäeva
    timestamp
, "Tekst"
    text
);

CREATE TABLE "Adressaat_YYYYMMDD"(
  "SõnumiKuupäev"
    date
, "Sõnum"
    uuid
, "Isik"
    uuid
, PRIMARY KEY("Sõnum", "Isik")
);

CREATE TABLE "Fail_YYYYMMDD"(
  "SõnumiKuupäev"
    date
, "Fail"
    uuid
      PRIMARY KEY
, "Sõnum"
    uuid
, "BLOB"
    uuid
, "Nimi"
    text
);

CREATE TABLE "SõnumiteRegistr_YYYYMMDD"(
  "SõnumiKuupäev"
    date
, "Omandaja"
    uuid
, "RegistriTüüp"
    smallint
, "KuupäevAeg"
    timestamp
, "Sõnum"
    uuid
, PRIMARY KEY("Omandaja", "RegistriTüüp", "Sõnum")
);
CREATE INDEX ON "SõnumiteRegistr_YYYYMMDD"("Omandaja", "RegistriTüüp", "KuupäevAeg" DESC);

-- sektsioonid, mis põhinevad teema kuupäeval
CREATE TABLE "Teema_YYYYMMDD"(
  "TeemaKuupäev"
    date
, "Teema"
    uuid
      PRIMARY KEY
, "Dokument"
    uuid
, "Pealkiri"
    text
);

CREATE TABLE "TeemaOsaleja_YYYYMMDD"(
  "TeemaKuupäev"
    date
, "Teema"
    uuid
, "Isik"
    uuid
, PRIMARY KEY("Teema", "Isik")
);

CREATE TABLE "SõnumiteTeemaKuupäevad_YYYYMMDD"(
  "TeemaKuupäev"
    date
, "Teema"
    uuid
      PRIMARY KEY
, "Kuupäev"
    date
);

Kasutame kokkuhoiuks

Aga kui me ei kasuta klassikalist sektsioonimise varianti väärtuste jaotuse alusel (triggereid ja pärimise või PARTITION BY kaudu), ning "käsitsi" rakenduse tasemel, võib märgata, et jaotusklausi väärtus on juba salvestatud tabeli enda nime.

Seega, kui te olete nii murelik salvestatud andmete mahu pärast, siis neist "ülemäärastest" väli on võimalik loobuda ja pöörduda konkreetsete tabelite poole. Tõsi, kõik valikud mitmest sektsioonist tuleb sel juhul rakenduse küljele viia.

Allikas: habr.com