DB av meldingsmessengeren (del 1): design av databasen

Hvordan kan man oversette forretningskrav til konkrete datastukturer ved å designe en database for en meldingsapp fra bunnen av.

• Del 1: Designer rammeverket for databasen
• Del 2: Seksjonerer i sanntid

Vår database vil ikke være så stor og distribuert, som hos VKontakte eller Badoo, men «bare for å ha noe», men det skal være bra – funksjonelt, raskt og få plass på én server PostgreSQL – slik at man kan sette opp en egen tjeneste et annet sted, for eksempel.

Derfor skal vi ikke ta opp spørsmål om sharding, replikering og geo-distribuerte systemer, men fokusere på skjematiske løsninger inne i databasen.

Trinn 1: Litt forretningsspesifikke detaljer

Vi vil designe meldingsutvekslingen ikke abstrakt, men integrere den i konteksten av et bedrifts sosialt nettverk. Det vil si at folk ikke «bare skriver til hverandre», men kommuniserer i sammenheng med å løse spesifikke forretningsoppgaver.

Og hvilke oppgaver har virksomheter?... La oss se på et eksempel med Vasily – lederen for utviklingsavdelingen.

• «Nikolai, vi trenger en patch for denne oppgaven i dag!»
  Dermed kan samtalen foregå i konteksten av en eller annen dokumentet.
• «Kola, la oss spille Dota i kveld?»
  Så selv med ett par samtalepartnere kan kommunikasjonen skje om flere temaer.
• «Petr, Nikolai, se vedlegget for prisen på den nye serveren.»
  Dermed kan en melding ha flere mottakere. I tillegg kan meldingen inneholde vedlagte filer.
• «Semen, og du også, ta en titt.»
  Og det må være mulig å invitere en ny deltaker til en allerede eksisterende samtale Vi stopper foreløpig med denne listen over «åpenbare» behov..

Uten å forstå den praktiske spesifikasjonen av oppgaven og de begrensningene den setter, er det nesten umulig å designe

en effektiv databasestruktur for å løse den. Trinn 2: Minimal logisk plan

Så langt ser den skjematiske fremstillingen veldig lik e-postkorrespondanse ut – et tradisjonelt verktøy for forretning. Ja, «algoritmisk» er mange forretningsoppgaver like, så verktøyene for å løse dem vil være strukturelt like.

La oss fastholde den logiske planen for entitetenes forhold vi allerede har fått. For enkelhets skyld i vår modell vil vi bruke den enkleste varianten av representasjonen

ER-modellen uten å komplisere med UML eller IDEF-notasjoner: uten kompliserte UML- eller IDEF-notasjoner:

I vårt eksempel er persona, dokumentet og det binære «kropp» av filen «eksterne» enheter som eksisterer uavhengig av vår tjeneste. Så vi vil bare oppfatte dem videre som noen lenker «et sted» via UUID.

Tegn diagrammer så enkelt som mulig — de fleste som du vil vise dem til, er ikke eksperter på å lese UML/IDEF. Men — husk å tegne.

Trinn 3: Utkast til tabellstrukturen

Om navnene på tabeller og feltMan kan se på «russiske» navne på felt og tabeller på forskjellige måter, men det er en smaksak. Siden vi i «Tensor» ikke har utenlandske utviklere, og PostgreSQL lar oss gi navn selv i hieroglyfer, hvis de er innesluttet i anførselstegn, så foretrekker vi å navngi objekter klart og entydig for å unngå misforståelser.
Siden mange personer skriver meldinger samtidig, kan noen av dem faktisk gjøre dette i offline-modus, så det enkleste alternativet er å bruke UUID som identifikatorer ikke bare for eksterne enheter, men også for alle objekter innen vår tjeneste. Og de kan genereres til og med på klientsiden — dette vil hjelpe oss å støtte sending av meldinger ved kortvarig databaseutilgjengelighet, og sjansen for kollisjon er ekstremt lav.

Den foreløpige tabellstrukturen i databasen vår vil se slik ut:
Tabeller : RU

CREATE TABLE "Tema"(
  "Tema"
    uuid
      PRIMARY KEY
, "Dokument"
    uuid
, "Navn"
    text
);

CREATE TABLE "Melding"(
  "Melding"
    uuid
      PRIMARY KEY
, "Tema"
    uuid
, "Forfatter"
    uuid
, "DatoTid"
    timestamp
, "Tekst"
    text
);

CREATE TABLE "Mottaker"(
  "Melding"
    uuid
, "Persona"
    uuid
, PRIMARY KEY("Melding", "Persona")
);

CREATE TABLE "Fil"(
  "Fil"
    uuid
      PRIMARY KEY
, "Melding"
    uuid
, "BLOB"
    uuid
, "Navn"
    text
);

Tabeller : 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
);

Det enkleste ved beskrivelsen av formatet er å begynne å «puste liv» i forbindelser fra tabeller som ikke refererer til noen andre.

Trinn 4: Avdekke ikke-åpenbare behov

Vi har designet en database hvor det er lett å skrive og på en eller annen måte lese.

La oss sette oss i brukeren sin plass — hva vil vi ønsker å gjøre med hjelp av tjenesten?

• Siste meldinger
  Dette chronologisk sortert etter ulike kriterier en liste over «mine» meldinger. Der jeg er en av mottakerne, der jeg er forfatter, der jeg har fått en melding, men ikke svart, hvor jeg ikke har fått svar, …
• Deltakere i samtalen
  Hvem deltar i denne lange, lange chatten?

Vår struktur lar oss løse begge disse oppgavene «generelt», men raskt – nei. Problemet er at for sortering i forbindelse med den første oppgaven er det umulig å lage en indeks, som er passende for hver deltaker (og vi må hente ut alle oppføringer), mens for å løse den andre må vi hente ut alle meldinger om emnet.

Uforutsigbare brukeroppgaver kan sette en stor brems på ytelsen.

Steg 5: Fornuftig denormalisering

Begge våre problemer kan løses med ekstra tabeller, hvor vi skal duplisere deler av dataene, som er nødvendige for å lage passende indekser for våre oppgaver.


Tabeller : RU

CREATE TABLE "Meldingsregister"(
  "Eier"
    uuid
, "Registertype"
    smallint
, "DatoTid"
    timestamp
, "Melding"
    uuid
, PRIMARY KEY("Eier", "Registertype", "Melding")
);
CREATE INDEX ON "Meldingsregister"("Eier", "Registertype", "DatoTid" DESC);

CREATE TABLE "TemaDeltaker"(
  "Tema"
    uuid
, "Person"
    uuid
, PRIMARY KEY("Tema", "Person")
);

Tabeller : 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)
);

Her har vi brukt to typiske tilnærminger, som brukes ved opprettelse av hjelpe-tabeller:

• Multiplikasjon av poster
  Vi lager flere konsekvensoppføringer av en enkelt originalmelding i forskjellige registertyper for forskjellige eiere – både for avsender og mottaker. Nå ligger imidlertid hver av registrene på indeks – for i typiske tilfeller ønsker vi vanligvis kun å se den første siden.
• Unikalisering av oppføringer
  Ved hver sending av melding innad i et bestemt tema er det tilstrekkelig å sjekke om en slik oppføring allerede eksisterer. Hvis ikke – legger vi den til vår «ordbok».

I neste del av artikkelen vil vi snakke om implementering av partisjonering inn i strukturen i databasen vår.

Kilde: habr.com