Databasen för meddelandeappen (del 1): vi designar ramverket för databasen

Hur man kan översätta affärskrav till specifika datastrukturer med exemplet att designa en databas för en meddelandetjänst "från grunden".

• Del 1: designa databasen
• Del 2: partitionera i realtid

Vår databas kommer inte att vara lika stor och distribuerad, som på VKontakte, eller Badoo, utan "bara för att ha", men det ska vara bra — funktionellt, snabbt och få plats på en server. PostgreSQL — så att man kan köra en separat instans av tjänsten någonstans på sidan, till exempel.

Därför kommer vi inte att beröra frågor om sharding, replikering och geografiskt distribuerade system, utan fokusera på schematiska lösningar inom databasen.

Steg 1: Lite affärsspecifika uppgifter

Vi kommer att designa vår meddelandetjänst inte abstrakt, utan integrera den i omgivningen av ett företags sociala nätverk.. Det vill säga att människor inte bara "chattar", utan kommunicerar med varandra i kontext av att lösa vissa affärsproblem.

Och vilka uppgifter finns det i affärsvärlden? Låt oss titta på exemplet med Vasily — chefen för utvecklingsavdelningen.

• "Nikolaj, en patch behövs för den här uppgiften idag!"
  Det betyder att kommunikationen kan ske i kontext av någon Inkomststrukturen för PhD-studenter och Post-Docs på EPFL.
• "Kola, ska vi spela Dota ikväll?"
  Det vill säga även en enda konversation kan pågå om olika ämnen..
• "Petr, Nikolaj, kolla i bilagan för priset på den nya servern."
  Så, ett meddelande kan ha flera mottagare.Samtidigt kan ett meddelande innehålla bifogade filer..
• "Semen, och du kolla också."
  Och det ska finnas en möjlighet att bjuda in en ny deltagare till en redan existerande konversation..

Låt oss stanna vid denna lista av "uppenbara" behov för tillfället.

Utan förståelse för tillämpningens specifika uppgifter och givna begränsningar är det praktiskt taget omöjligt att designa en effektiv databasstruktur för dess lösning.

Steg 2: Minimal logisk struktur

Strukturellt liknar det fortfarande ett e-postkonversation — ett traditionellt verktyg för att driva affärer. Så ja, "algoritmiskt" liknar många affärsproblem varandra, och därför kommer även verktygen för att lösa dem att vara strukturellt liknande.

Låt oss dokumentera den logiska strukturen av relationerna mellan enheterna som vi har fått. För att underlätta förståelsen av vår modell kommer vi att använda den mest primitiva varianten av att visa ER-modeller utan kompliceringar av UML eller IDEF-notation:

I vårt exempel är persona, dokumentet och den binära "kroppen" av filen - dessa är "externa" enheter som existerar på egen hand, oberoende av vår service. Så vi kommer helt enkelt att betrakta dem som några länkar "någonstans" via UUID.

Rita scheman så enkelt som möjligt — de flesta av dem du visar dem för är inte experter på att läsa UML/IDEF. Men — rita absolut.

Steg 3: Skissa ut tabellstrukturen

Om tabell- och fältnamnMan kan ha olika åsikter om "ryska" namn på fält och tabeller, men det är en smakfråga. Eftersom vi i "Tensor" inte har utländska utvecklare, och PostgreSQL tillåter oss att använda namn som kan vara hieroglyfer, om de är omgivna av citattecken, så föredrar vi att namnge objekt tydligt för att undvika missförstånd.
Eftersom många personer skriver meddelanden samtidigt, kan en del av dem faktiskt göra detta i offline-läge, så det enklaste alternativet är — att använda UUID som identifierare inte bara för externa enheter, utan även för alla objekt inom vår tjänst. Dessutom kan de genereras även på klientsidan — detta hjälper oss att stödja sändningen av meddelanden vid kortvarigt otillgänglighet av databasen, och risken för kollisioner är extremt låg.

Den preliminära tabellstrukturen i vår databas kommer att se ut så här:
Tabeller : RU

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

CREATE TABLE "Meddelande"(
  "Meddelande"
    uuid
      PRIMARY KEY
, "Tema"
    uuid
, "Författare"
    uuid
, "DatumTid"
    timestamp
, "Text"
    text
);

CREATE TABLE "Adressat"(
  "Meddelande"
    uuid
, "Persona"
    uuid
, PRIMARY KEY("Meddelande", "Persona")
);

CREATE TABLE "Fil"(
  "Fil"
    uuid
      PRIMARY KEY
, "Meddelande"
    uuid
, "BLOB"
    uuid
, "Namn"
    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 enklaste när man beskriver formatet är att börja "utveckla" relationen från tabeller som inte refererar till någon annan.

Steg 4: Förstå de otydliga behoven

Det är klart, vi har designat en databas som man kan skriva bra i och på något sätt läsa.

Låt oss sätta oss i stället för användaren av vår tjänst – vad skulle vi vilja göra med hjälp av den?

• Senaste meddelandena
  Detta chronologiskt sorterade en register över "mina" meddelanden där jag är mottagare, där jag är avsändare, där jag har fått ett meddelande men inte svarat, där jag inte fått något svar, …
• Deltagare i konversationen
  Vem deltar överhuvudtaget i den här långa chatten?

Vår struktur kan lösa båda dessa uppgifter "övergripande", men snabbt – nej. Problemet är att för att sortera i den första uppgiften är det omöjligt att skapa ett index, som passar för varje deltagare (och vi måste hämta alla poster), och för att lösa den andra krävs det att hämta alla meddelanden i ämnet.

Oförutsedda användaruppgifter kan sätta en djup brun färg på prestandan.

Steg 5: Förnuftig denormalisering

Båda våra problem kan lösas med hjälp av extra tabeller där vi kommer att duplicera en del av de data, som behövs för att skapa lämpliga index för våra uppgifter.


Tabeller : RU

CREATE TABLE "MeddelandeRegister"(
  "Ägare"
    uuid
, "RegisterTyp"
    smallint
, "DatumTid"
    timestamp
, "Meddelande"
    uuid
, PRIMARY KEY("Ägare", "RegisterTyp", "Meddelande")
);
CREATE INDEX ON "MeddelandeRegister"("Ägare", "RegisterTyp", "DatumTid" DESC);

CREATE TABLE "TemaDeltagare"(
  "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)
);

Här har vi använt två typiska tillvägagångssätt vid skapandet av hjälptabeller:

• Multiplikation av poster
  Vi skapar för varje ursprunglig meddelandepost flera följdposter i olika typer av register för olika ägare – både för avsändaren och för mottagaren. Men nu ligger varje register på ett index – eftersom vi typiskt sett vill se bara första sidan.
• Unikalisering av poster
  Vid varje meddelande som skickas inom ett specifikt ämne är det tillräckligt att kontrollera om en sådan post redan existerar. Om inte – lägger vi till den i vår "ordbok".

I nästa del av artikeln kommer vi att prata om implementering av partitionering i strukturen av vår databas.

Källa: habr.com