Messenger datu bāze (1. daļa): bāzes ietvara projektēšana

Kā jūs varat pārvērst biznesa prasības konkrētās datu struktūrās, izmantojot piemēru, kā izveidot Messenger datubāzi no nulles.

• 1. daļa: pamata rāmja projektēšana
• 2. daļa: iedalījums “peļņas gūšanai”

Mūsu bāze nebūs tik liela un izkliedēta, piemēram, VKontakte vai Badoo, bet “tā, ka bija”, bet bija labi - funkcionāli, ātri un iederas vienā serverī PostgreSQL — lai, piemēram, varētu izvietot atsevišķu pakalpojuma gadījumu kaut kur malā.

Tāpēc mēs neskarsim jautājumus par sadalīšanu, replikāciju un ģeogrāfiski sadalītām sistēmām, bet koncentrēsimies uz ķēžu risinājumiem datubāzē.

1. darbība. Dažas uzņēmējdarbības specifikas

Mēs neveidosim savu ziņojumapmaiņu abstrakti, bet integrēsim to vidē korporatīvais sociālais tīkls. Tas ir, mūsu cilvēki nevis “tikai sarakstās”, bet sazinās savā starpā noteiktu biznesa problēmu risināšanas kontekstā.

Un kādi ir biznesa uzdevumi?.. Paskatīsimies uz attīstības nodaļas vadītāja Vasilija piemēru.

• "Nikolaj, šim uzdevumam mums šodien ir nepieciešams ielāps!"
  Tas nozīmē, ka sarakste var tikt veikta dažu kontekstā dokuments.
• "Koļa, vai tu šovakar dosies uz Dotu?"
  Tas ir, pat viens sarunu biedru pāris var sazināties vienlaikus par dažādām tēmām.
• "Pīter, Nikolaj, meklējiet pielikumā jaunā servera cenrādi."
  Tātad, viens ziņojums var būt vairāki adresāti. Šajā gadījumā ziņojumā var būt Pievienotie faili.
• "Semjon, paskaties arī."
  Un vajadzētu būt iespējai iesaistīties esošajā sarakstē uzaicināt jaunu dalībnieku.

Pakavēsimies pie šī “acīmredzamo” vajadzību saraksta.

Neizprotot problēmas pielietoto specifiku un tai dotos ierobežojumus, projektēšana efektīvs datu bāzes shēmu, lai to atrisinātu, ir gandrīz neiespējami.

2. darbība: minimālā loģiskā shēma

Pagaidām viss izdodas ļoti līdzīgi e-pasta sarakstei – tradicionālam biznesa instrumentam. Jā, “algoritmiski” daudzas biznesa problēmas ir līdzīgas viena otrai, tāpēc rīki to risināšanai būs strukturāli līdzīgi.

Labosim jau iegūto entītiju attiecību loģisko diagrammu. Lai mūsu modelis būtu vieglāk saprotams, mēs izmantosim primitīvāko displeja opciju ER modeļi bez UML vai IDEF apzīmējumu sarežģījumiem:

Mūsu piemērā faila persona, dokuments un binārais “ķermenis” ir “ārējas” entītijas, kas pastāv neatkarīgi bez mūsu pakalpojuma. Tāpēc turpmāk mēs tās vienkārši uztversim kā dažas UUID saites “kaut kur”.

Zīmēt diagrammas pēc iespējas vienkāršākas - Lielākā daļa cilvēku, kuriem jūs tos parādīsit, nav UML/IDEF lasīšanas eksperti. Bet noteikti zīmējiet.

3. solis: tabulas struktūras skicēšana

Par tabulu un lauku nosaukumiemLauku un tabulu nosaukumus “krieviski” var traktēt dažādi, taču tas ir gaumes jautājums. Tāpēc ka šeit, Tensorā nav ārzemju izstrādātāju, un PostgreSQL ļauj mums dot vārdus pat hieroglifos, ja tie ielikts pēdiņās, tad mēs labprātāk nosaucam objektus nepārprotami un skaidri, lai nebūtu neatbilstību.
Tā kā daudzi cilvēki mums raksta ziņas vienlaikus, daži no viņiem to pat var darīt bezsaistē, tad vienkāršākais variants ir izmantot UUID kā identifikatorus ne tikai ārējām entītijām, bet arī visiem objektiem mūsu pakalpojuma ietvaros. Turklāt tos var ģenerēt pat klienta pusē – tas mums palīdzēs atbalstīt ziņojumu sūtīšanu, ja datu bāze īslaicīgi nav pieejama un sadursmes iespējamība ir ārkārtīgi zema.

Tabulas uzmetuma struktūra mūsu datubāzē izskatīsies šādi:
Tabulas : 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
);

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

Vienkāršākā lieta, aprakstot formātu, ir sākt “attīt” savienojuma grafiku no tabulām, uz kurām nav atsauces sevi nevienam.

4. darbība: noskaidrojiet neskaidras vajadzības

Tas ir viss, mēs esam izveidojuši datu bāzi, kurā varat rakstīt perfekti un kaut kā lasīt.

Iekārtosimies sava pakalpojuma lietotāja vietā – ko mēs ar to vēlamies darīt?

• Pēdējās ziņas
  Tā hronoloģiski sakārtots “manu” ziņojumu reģistrs, kas balstīts uz dažādiem kritērijiem. Kur es esmu viens no adresātiem, kur es esmu autors, kur viņi man rakstīja un es neatbildēju, kur viņi man neatbildēja, ...
• Korespondences dalībnieki
  Kurš vispār piedalās šajā garajā, garajā tērzēšanā?

Mūsu struktūra ļauj mums atrisināt abas šīs problēmas "vispārīgi", bet ne ātri. Problēma ir saistīta ar šķirošanu pirmā uzdevuma ietvaros nevar izveidot indeksu, piemērots katram dalībniekam (un jums būs jāizvelk visi ieraksti), un, lai atrisinātu otro, kas jums nepieciešams izvilkt visus ziņojumus par šo tēmu.

Neparedzēti lietotāja uzdevumi var būt treknrakstā krusts ar produktivitāti.

5. darbība: viedā denormalizācija

Abas mūsu problēmas atrisinās papildu tabulas, kurās mēs to darīsim dublēt daļu datu, nepieciešams uz tiem veidot mūsu uzdevumiem piemērotus rādītājus.


Tabulas : RU

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

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

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

Šeit mēs esam izmantojuši divas tipiskas pieejas, ko izmanto, veidojot palīgtabulas:

• Ierakstu reizināšana
  Izmantojot vienu sākotnējo ziņojuma ierakstu, mēs veidojam vairākus pēcpārbaudes ierakstus dažāda veida reģistros dažādiem īpašniekiem – gan sūtītājam, gan adresātam. Bet katrs no reģistriem tagad ietilpst rādītājā - galu galā, tipiskā gadījumā mēs vēlamies redzēt tikai pirmo lapu.
• Unikāli ieraksti
  Katru reizi, kad nosūtāt ziņojumu konkrētas tēmas ietvaros, pietiek pārbaudīt, vai šāds ieraksts jau neeksistē. Ja nē, pievienojiet to mūsu “vārdnīcai”.

Nākamajā raksta daļā mēs par to runāsim sadalīšanas ieviešana mūsu datu bāzes struktūrā.

Avots: www.habr.com