Baza e të dhënave të Messenger (pjesa 1): dizajnimi i kornizës bazë

Si mund t'i përktheni kërkesat e biznesit në struktura specifike të dhënash duke përdorur shembullin e dizajnimit të një baze të dhënash të dërguarit nga e para.

• Pjesa 1: dizajnimi i kornizës bazë
• Pjesa 2: seksioni "për fitim"

Baza jonë nuk do të jetë aq e madhe dhe e shpërndarë, si VKontakte ose Badoo, por "ashtu që ishte", por ishte i mirë - funksional, i shpejtë dhe përshtatet në një server PostgreSQL - në mënyrë që të mund të vendosni një shembull të veçantë të shërbimit diku në anën, për shembull.

Prandaj, ne nuk do të prekim çështjet e ndarjes, riprodhimit dhe sistemeve gjeo-shpërndarë, por do të fokusohemi në zgjidhjet e qarkut brenda bazës së të dhënave.

Hapi 1: Disa specifika të biznesit

Ne nuk do ta dizajnojmë mesazhin tonë në mënyrë abstrakte, por do ta integrojmë atë në mjedis rrjeti social i korporatës. Kjo do të thotë, njerëzit tanë nuk "thjesht korrespondojnë", por komunikojnë me njëri-tjetrin në kontekstin e zgjidhjes së problemeve të caktuara të biznesit.

Dhe cilat janë detyrat e një biznesi?.. Le të shohim shembullin e Vasilit, kreut të departamentit të zhvillimit.

• "Nikolai, për këtë detyrë na duhet një arnim sot!"
  Kjo do të thotë se korrespondenca mund të kryhet në kontekstin e disa dokument.
• "Kolya, do të shkosh në Dota këtë mbrëmje?"
  Domethënë, edhe një palë bashkëbiseduesish mund të komunikojnë njëkohësisht në tema të ndryshme.
• "Peter, Nikolay, shikoni në bashkëngjitje listën e çmimeve për serverin e ri."
  Pra, një mesazh mund të ketë disa marrës. Në këtë rast, mesazhi mund të përmbajë Skedarët e bashkangjitur.
• "Semyon, hidhi një sy edhe ti."
  Dhe duhet të ketë një mundësi për të hyrë në korrespondencën ekzistuese ftoni një anëtar të ri.

Le të ndalemi në këtë listë të nevojave "të dukshme" tani për tani.

Pa kuptuar specifikat e aplikuara të problemit dhe kufizimet që i janë dhënë, dizajni efektive Skema e bazës së të dhënave për ta zgjidhur atë është pothuajse e pamundur.

Hapi 2: Qarku logjik minimal

Deri më tani, gjithçka funksionon shumë e ngjashme me korrespondencën me email - një mjet tradicional biznesi. Po, "algoritmikisht" shumë probleme biznesi janë të ngjashme me njëra-tjetrën, prandaj mjetet për zgjidhjen e tyre do të jenë strukturore të ngjashme.

Le të rregullojmë diagramin logjik të marrë tashmë të marrëdhënieve të entiteteve. Për ta bërë modelin tonë më të lehtë për t'u kuptuar, ne do të përdorim opsionin më primitiv të ekranit Modelet ER pa ndërlikimet e shënimeve UML ose IDEF:

Në shembullin tonë, personi, dokumenti dhe "trupi" binar i skedarit janë entitete "të jashtme" që ekzistojnë në mënyrë të pavarur pa shërbimin tonë. Prandaj, ne thjesht do t'i perceptojmë ato në të ardhmen si disa lidhje "diku" nga UUID.

Vizatoni diagrame sa më të thjeshta - shumica e njerëzve që do t'u tregoni nuk janë ekspertë në leximin e UML/IDEF. Por sigurohuni që të vizatoni.

Hapi 3: Skicimi i strukturës së tabelës

Rreth emrave të tabelave dhe fushaveEmrat "rusë" të fushave dhe tabelave mund të trajtohen ndryshe, por kjo është çështje shije. Sepse këtu në Tensor nuk ka zhvillues të huaj dhe PostgreSQL na lejon të japim emra edhe në hieroglife, nëse ata të mbyllura në thonjëza, atëherë preferojmë t'i emërtojmë objektet në mënyrë të qartë dhe të qartë në mënyrë që të mos ketë mospërputhje.
Meqenëse shumë njerëz na shkruajnë mesazhe menjëherë, disa prej tyre madje mund ta bëjnë këtë jashtë linje, atëherë opsioni më i thjeshtë është përdorni UUID si identifikues jo vetëm për subjektet e jashtme, por edhe për të gjitha objektet brenda shërbimit tonë. Për më tepër, ato mund të gjenerohen edhe në anën e klientit - kjo do të na ndihmojë të mbështesim dërgimin e mesazheve kur baza e të dhënave është përkohësisht e padisponueshme dhe gjasat për një përplasje janë jashtëzakonisht të ulëta.

Struktura e draftit të tabelës në bazën tonë të të dhënave do të duket kështu:
Tabelat: RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

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

Gjëja më e thjeshtë kur përshkruani një format është të filloni "zbërthimin" e grafikut të lidhjes nga tabelat që nuk janë referuar veten për askënd.

Hapi 4: Gjeni nevojat jo të dukshme

Kjo është e gjitha, ne kemi krijuar një bazë të dhënash në të cilën mund të shkruani në mënyrë të përsosur dhe disi lexoni.

Le ta vendosim veten në vendin e përdoruesit të shërbimit tonë - çfarë duam të bëjmë me të?

• Mesazhet e fundit
  Ajo të renditura kronologjikisht një regjistër i mesazheve "my" bazuar në kritere të ndryshme. Ku jam një nga marrësit, ku jam autori, ku më kanë shkruar dhe nuk jam përgjigjur, ku nuk më janë përgjigjur, ...
• Pjesëmarrësit e korrespondencës
  Kush madje merr pjesë në këtë bisedë të gjatë e të gjatë?

Struktura jonë na lejon t'i zgjidhim të dyja këto probleme "në përgjithësi", por jo shpejt. Problemi është se për renditjen brenda detyrës së parë nuk mund të krijojë indeks, i përshtatshëm për secilin prej pjesëmarrësve (dhe do t'ju duhet të nxirrni të gjitha të dhënat), dhe për të zgjidhur të dytin që ju nevojiten nxjerr të gjitha mesazhet në këtë temë.

Detyrat e padëshiruara të përdoruesit mund të jenë të theksuara kryq mbi produktivitetin.

Hapi 5: Denormalizimi i zgjuar

Të dy problemet tona do të zgjidhen me tabela shtesë në të cilat do të zgjidhemi kopjoni një pjesë të të dhënave, të nevojshme për të formuar mbi to indekse të përshtatshme për detyrat tona.


Tabelat: RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

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

Këtu kemi aplikuar dy qasje tipike të përdorura gjatë krijimit të tabelave ndihmëse:

• Shumëzimi i të dhënave
  Duke përdorur një regjistrim fillestar të mesazheve, ne krijojmë disa regjistrime vijuese në lloje të ndryshme regjistrash për pronarë të ndryshëm - si për dërguesin ashtu edhe për marrësin. Por secili prej regjistrave tani bie në indeks - në fund të fundit, në një rast tipik, ne do të dëshirojmë të shohim vetëm faqen e parë.
• Rekorde unike
  Sa herë që dërgoni një mesazh brenda një teme specifike, mjafton të kontrolloni nëse një hyrje e tillë ekziston tashmë. Nëse jo, shtoni atë në "fjalorin" tonë.

Në pjesën tjetër të artikullit do të flasim për zbatimi i ndarjes në strukturën e bazës sonë të të dhënave.

Burimi: www.habr.com