Messengeri andmebaas (osa 2): jaotame "realses ajas".

Me oleme edukalt projekteerinud meie PostgreSQL andmebaasi struktuuri vestluste salvestamiseks, aasta on möödas ja kasutajad täidavad seda aktiivselt, nüüd on seal juba miljoneid kirjeid, ja… midagi hakkas aeglasemalt minema.

• Jagu 1: projekteerime andmebaasi karkassi
• Jagu 2: sektsioneerime „reaalajas”

Asi on selles, et Kuna tabeli maht suureneb, suureneb ka indeksite "sügavus" — kuigi logaritmiliselt. Kuid aja jooksul sunnib see serverit täitma samu lugemise/kirjutamise ülesandeid käsitlema tähtselt rohkem andmelehti, kui alguses.

Siinkohal tuleb appi partitsioneerimine.

Tuleb märkida, et räägime mitte shardimisest, st andmete jaotamisest erinevate andmebaaside või serverite vahel. Sest isegi kui te jagate andmed mõningaid serverite vahel, ei pääse te ajapikku esineva "indeksite paisumise" probleemist. On selge, et kui saate iga päev uue serveri juurutada, siis teie probleemid ei jää seotud konkreetse andmebaasi tasandiga.

Me vaatame mitte konkreetseid skripte, et teostada partitsioneerimist "rauda", vaid lähenemist – mida ja kuidas tuleks "tükeldada" ning mida see soov kaasa toob.

Käsiteema

Kordame meie eesmärki: soovime seda, et täna, homme ja aasta pärast jääks PostgreSQL loetavate andmete hulk igasuguste lugemise/kirjutamise operatsioonide käigus enam-vähem samaks.

Käesolevate jaoks ajal pooltugevdus andmetele (sõnumid, dokumendid, logid, arhiivid, …) on partitsioneerimise võtmekohaks loomulikult sündmuse kuupäev/aeg. Meie puhul on selliseks sündmuseks sõnumi saatmise hetk.

Märkasime, et kasutajad töötavad peaaegu alati ainult "viimastega" selliste andmete – loevad viimaseid sõnumeid, analüüsivad viimaseid logisid,… Ei, loomulikult võivad nad kerida ka ajas tagasi, kuid teevad seda väga harva.

Nendest piirangutest on selge, et parim lahendus sõnumite jaoks oleks "päevaste" sektsioonide loomine — sest peaaegu alati loeb meie kasutaja seda, mis tuli "täna" või "eile".

Kui me päeva jooksul kirjutame ja loeme peamiselt vaid ühes sektsioonis, siis see annab meile ka efektiivsema mälu ja ketta kasutamise — kuna kõik sektsiooni indeksid mahuvad hõlpsasti mällu, erinevalt "suurtest ja paksudest" kogu tabelis.

step-by-step

Üldiselt kõlab kõik, mis eespool öeldud, nagu suur kasum. Ja see on saavutatav, kuid selleks peame korralikult vaeva nägema — sest üks olendite sektsioneerimise lahendus toob kaasa vajaduse «jagada» ka need, mis sellega seotud.

Sõnum, selle omadused ja projektsioonid

Kuna otsustasime sõnumeid kuupäevade põhjal jagada, on mõistlik jagada ka sõltuvad omadused (lisatud failid, adressaatide nimekiri) ja ka sõnumi kuupäeva põhjal.

Kuna üks meie tüüpilisi ülesandeid on sõnumite registrite ülevaatamine (lugemata, sissetulevad, kõik), on loogiline, et need «kaasata» sõnumite kuupäevade põhjal sektsioneerimisse.

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

Teemad

Kuna teema on mitme sõnumi kohta, ei saa seda sama mudeli järgi enam jagada, peame toetuma millelegi muule. Meie puhul sobib ideaalselt esimese sõnumi kuupäev vestluses — seega hetke loomine, tegelikult teema.

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

Kuid nüüd tekib meil kohe kaks probleemi:

• milles sektsioonis otsida sõnumeid teema järgi?
• milles sektsioonis otsida teemat sõnumist?

Saame muidugi jätkata otsimist kõigis sektsioonides, kuid see oleks väga kurb ja nulliks kõik meie kasud. Seetõttu, et teada saada, kus otsida, loome loogilised lingid/viidatud sektsioonid:

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

Kuna eraldi vestlusele sõnumite kuupäevade nimekiri on väike (peaaegu kõik sõnumid langevad 1-2 järgneva päeva sisse), pean peatuma just sellisel variandil.

Kokkuvõttes on meie andmebaasi struktuur selline, arvestades sektsioneerimist:

Tabelid: RU, kui kirillitsast pealkirjades/xmlid/põldudes kõrvalehoidmine, siis pole parem vaadata

-- osakonnad sõnumi kuupäeva järgi
CREATE TABLE "Sõnum_YYYYMMDD"(
  "Sõnum"
    uuid
      PRIMARY KEY
, "Teema"
    uuid
, "KuupäevTeema"
    date
, "Autor"
    uuid
, "KuupäevAeg" -- kasutame kuupäevana
    timestamp
, "Tekst"
    text
);

CREATE TABLE "Saaja_YYYYMMDD"(
  "KuupäevSõnum"
    date
, "Sõnum"
    uuid
, "Isik"
    uuid
, PRIMARY KEY("Sõnum", "Isik")
);

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

CREATE TABLE "SõnumiteRegistr_YYYYMMDD"(
  "KuupäevSõnum"
    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);

-- osakonnad teema kuupäeva järgi
CREATE TABLE "Teema_YYYYMMDD"(
  "KuupäevTeema"
    date
, "Teema"
    uuid
      PRIMARY KEY
, "Dokument"
    uuid
, "Pealkiri"
    text
);

CREATE TABLE "TeemaOsaline_YYYYMMDD"(
  "KuupäevTeema"
    date
, "Teema"
    uuid
, "Isik"
    uuid
, PRIMARY KEY("Teema", "Isik")
);

CREATE TABLE "TeemaSõnumiteKuupäevad_YYYYMMDD"(
  "KuupäevTeema"
    date
, "Teema"
    uuid
      PRIMARY KEY
, "Kuupäev"
    date
);

Säästame raha

Aga kui me ei kasuta klassikalist sektsioonide jagamise varianti väli väärtuste jaotuse põhjal (triggereid ja pärandamist või PARTITION BY), vaid teeme seda "kätega" rakenduse tasemel, siis võib märgata, et sektsioneerimisvõti on juba talletatud tabeli nimetuses.

Seetõttu, kui te olete nii muretsenud salvestatud andmete hulga pärast, siis neist "ülearustest" väljadest võib ka loobuda ja pöörduda otseselt konkreetsete tabelite poole. Tõsi, kõik valikud mitmest sektsioonist tuleb sel juhul rakenduse tasemele viia.

Allikas: habr.com