Sõnumite andmebaas (jag. 1): projekteerime andmebaasi karkassi

Kuidas saame äri nõudmisi tõlkida konkreetseteks andmestruktuurideks, kasutades näitena andmebaasi projekteerimist „nullist” sõnumite jaoks.

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

Meie andmebaas ei saa olema nii ulatuslik ja jaotatud, nagu VKontakte'il või Badoo, vaid „et lihtsalt oleks”, aga oleks hästi — funktsionaalselt, kiiresti ja mahtuks ühele serverile PostgreSQL — et oleks võimalik kuskil külgselt teenuse eraldi eksemplari käivitada, näiteks.

Seega ei puuduta me shardimise, replikatsiooni ja geograafiliselt jaotatud süsteemide teemasid, vaid keskendume andmebaasi sisemistele skeemilahendustele.

Samm 1: Veidi äri-spetsiifikat

Meie sõnumite vahetust ei projekteeri me abstraktselt, vaid integreerime selle keskkonda ettevõtte sotsiaalvõrgustikku. See tähendab, et inimesed ei tee lihtsalt teksti vahetust, vaid suhtlevad omavahel teatud äriülesannete lahendamise kontekstis.

Aga millised äriülesanded võivad olla?.. Vaatame Vasili näitel — arendusosakonna juhi kaudu.

• „Nikolai, selle ülesande kohta on patch täna juba vajalik!”
  See tähendab, et vestlus võib toimuda mingisuguse dokumentide.
• „Kola, läheme õhtul Dota'sse?”
  See tähendab, et isegi ühe paarilise vahel võib samaaegselt käia suhtlemine erinevatel teemadel.
• „Pjotr, Nikolai, vaadake manustes uus serveri hind.”
  Nii, ühel sõnumil võib olla mitu adressaati. Selle juures võib sõnum sisaldada manustatud faile.
• „Semen, vaata sa ka.”
  Ja peaks olema võimalus juba olemasolevasse vestlusesse uut osalist kutsuda.

Peatume praegu sellel „ilmse” vajaduste nimekirjal.

Ilma rakenduse spetsiifika ja selle seatud piirangute mõistmiseta on peaaegu võimatu projekteerida efektiivset andmebaasi skeemi selle lahendamiseks.

Samm 2: Minimaalne loogiline skeem

Skeem on muu hulgas väga sarnane e-kirjavahetusele — traditsiooniline äri läbiviimise instrument. Tõepoolest, paljude äriülesannete „algsed” lahendused sarnanevad teineteisele, seega on ka nende lahendamiseks kasutatavad vahendid struktuurilt sarnased.

Kinnitan juba saavutatud loogilise skeemi suhete kohta. Meie mudeli arusaamise lihtsustamiseks kasutame kõige primitiivsemat varianti ER-mudeli kuvamiseks ER-mudel ilma UML või IDEF mudeliteta:

Meie näites on isik, dokument ja faili binaarne "keha" "välistena" entiteetid, mis eksisteerivad ka ilma meie teenuseta. Seega võtame need edaspidi lihtsalt mõne linkina "kusagile" UUID alusel.

Joonistage skeeme nii lihtsasti kui võimalik — enamik neist, kellele te neid näitate, ei ole UML/IDEF lugemise eksperdid. Kuid — kindlasti joonistage.

Samm 3: Loome tabelite struktuuri

Tabelite ja väljade nimedestVõib olla erinevaid arvamusi „vene“ nime kohta väljadele ja tabelitele, aga see on maits küsimus. Kuna meie "Tensoris" pole välismaalasi arendajaid, ja PostgreSQL võimaldab meil nimetada isegi hieroglüüfidena, kui need on tsitaatides, siis eelistame nimetada objekte üheselt arusaadavalt, et ei tekiks segadust.
Kuna sõnumeid kirjutavad mitmed inimesed korraga, võivad mõned neist seda teha off-line režiimis, siis kõige lihtsam variant on kasutada UUID-sid identifikaatoritena mitte ainult väliste entiteetide, vaid ka kõigi objektide jaoks meie teenuses. Ning nende genereerimist saab teha isegi kliendi poolel — see aitab meil toetada sõnumite saatmist lühiajalisel DB kättesaamatuse ajal, samas kui kokkulangevuse tõenäosus on äärmiselt väike.

Meie andmebaasi must struktuur näeb välja järgmine:
Tabelid: RU

CREATE TABLE "Teema"(
  "Teema"
    uuid
      PRIMARY KEY
, "Dokument"
    uuid
, "Nimi"
    text
);

CREATE TABLE "Sõnum"(
  "Sõnum"
    uuid
      PRIMARY KEY
, "Teema"
    uuid
, "Autor"
    uuid
, "KuupäevAeg"
    timestamp
, "Tekst"
    text
);

CREATE TABLE "Adressaat"(
  "Sõnum"
    uuid
, "Isik"
    uuid
, PRIMARY KEY("Sõnum", "Isik")
);

CREATE TABLE "Fail"(
  "Fail"
    uuid
      PRIMARY KEY
, "Sõnum"
    uuid
, "BLOB"
    uuid
, "Nimi"
    text
);

Tabelid: EN

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

Lihtsaim viis formaadi kirjeldamiseks on "näidata" suhete graafikut tabelitest, mis ei viita ise kellelegi.

Samm 4: Selgitame välja mitte-eeldatavad vajadused

Kõik, oleme projekteerinud andmebaasi, kuhu saab suurepäraselt kirjutada ja kuidagi lugeda.

Asetame end meie teenuse kasutaja asemele — mida me tahaksime selle abil teha?

• Viimased sõnumid
  See on ajaliselt järjestatud erinevate kriteeriumite järgi ülevaade "minu" sõnumitest. Kus ma olen üks adressaatidest, kus ma olen autor, kus minule kirjutati, aga ma ei vastanud, kus mulle ei vastatud, ...
• Vestluse osalised
  Kes üldse osaleb selles pika-pika jututoas?

Meie struktuur võimaldab lahendada mõlemad need ülesanded "üldiselt", kuid kiiresti — ei. Probleem on see, et esimeses ülesandes sortimise jaoks ei saa luua indeksi, mis sobiks igale osalejale (ja tuleb välja võtta kõik kirjed), aga teise lahendamiseks on vaja välja võtta kõik sõnumid teema kohta.

Etteplaneerimata kasutajaülesanded võivad tõsiselt madaldada jõudlust.

Samm 5: Mõistlik denormaliseerimine

Mõlemad meie probleemid aitavad lahendada täiendavad tabelid, kuhu me dubleerime osa andmeid, vajalikud sisseehitatud indeksite loomiseks meie ülesannetele sobivalt.


Tabelid: RU

CREATE TABLE "SõnumiteRegister"(
  "Omandaja"
    uuid
, "RegisterTüüp"
    smallint
, "KuupäevAeg"
    timestamp
, "Sõnum"
    uuid
, PRIMARY KEY("Omandaja", "RegisterTüüp", "Sõnum")
);
CREATE INDEX ON "SõnumiteRegister"("Omandaja", "RegisterTüüp", "KuupäevAeg" DESC);

CREATE TABLE "TeemaOsaline"(
  "Teema"
    uuid
, "Isik"
    uuid
, PRIMARY KEY("Teema", "Isik")
);

Tabelid: EN

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

Siin rakendasime kaks tüüpilist lähenemisviisi abitablejate loomisel:

• Kirjete paljundamine
  Loome ühe algse sõnumi kohta kohe mitu tulemust erinevates registrites erinevatele omanikele — nagu saatjale, nii ka saajale. Ent iga register katab nüüd indeksi — kuna tüüpilises olukorras tahame näha ainult esimest lehte.
• Kirjete unikaalsus
  Iga sõnumi saatmise korral teatud teema raames piisab, kui kontrollida, kas selline kirje juba eksisteerib. Kui ei — lisame selle oma "sõnastikku".

Järgmises artikli osas räägitakse jaotamise rakendamisest meie andmebaasi struktuuri.

Allikas: habr.com