ProHoster > Blog > Adminisztráció > Messenger adatbázis (1. rész): az alap keretrendszer tervezése

Messenger adatbázis (1. rész): az alap keretrendszer tervezése

Hogyan fordíthatja le az üzleti követelményeket specifikus adatstruktúrákká a messenger adatbázis megtervezésének példájával.

Messenger adatbázis (1. rész): az alap keretrendszer tervezése
A bázisunk nem lesz olyan nagy és elosztott, mint a VKontakte vagy Badoo, de „úgy, hogy volt”, de jó volt - működőképes, gyors és elfér egy szerveren PostgreSQL – így például a szolgáltatás külön példányát telepítheti valahol az oldalon.

Ezért nem térünk ki a sharling, replikációs és geo-elosztott rendszerek kérdéseire, hanem az adatbázison belüli áramköri megoldásokra koncentrálunk.

1. lépés: Néhány üzleti jellemző

Üzenetkezelésünket nem absztrakt módon tervezzük, hanem integráljuk a környezetbe vállalati közösségi hálózat. Vagyis embereink nem „csak leveleznek”, hanem kommunikálnak egymással bizonyos üzleti problémák megoldása keretében.

És mik a feladatai egy vállalkozásnak?.. Nézzük Vaszilij, a fejlesztési osztály vezetőjének példáját.

  • „Nikolaj, ehhez a feladathoz ma kell egy folt!”
    Ez azt jelenti, hogy egyesekkel összefüggésben lehet levelezést folytatni dokumentum.
  • – Kolya, mész ma este Dótába?
    Vagyis akár egy pár beszélgetőpartner is tud egyszerre kommunikálni különféle témákban.
  • – Peter, Nikolay, keresse meg a mellékletben az új szerver árlistáját.
    Tehát egy üzenet lehet több címzett. Ebben az esetben az üzenet tartalmazhat Csatolt fájlok.
  • – Semyon, nézd meg te is.
    És lehetőséget kell adni a meglévő levelezésbe való belépésre új tagot hívni.

Maradjunk most ezen a „nyilvánvaló” szükségletek listáján.

A probléma alkalmazott sajátosságainak és a rájuk adott korlátoknak a megértése nélkül, tervezés hatékony adatbázissémát szinte lehetetlen megoldani.

2. lépés: Minimális logikai áramkör

Eddig minden nagyon hasonlít az e-mail levelezéshez – ez egy hagyományos üzleti eszköz. Igen, „algoritmikusan” sok üzleti probléma hasonló egymáshoz, ezért a megoldási eszközök szerkezetileg hasonlóak lesznek.

Rögzítsük az entitások kapcsolatainak már kapott logikai diagramját. Modellünk érthetősége érdekében a legprimitívebb megjelenítési lehetőséget fogjuk használni ER modellek az UML vagy IDEF jelölések komplikációi nélkül:

Messenger adatbázis (1. rész): az alap keretrendszer tervezése

Példánkban a fájl személye, dokumentuma és bináris „teste” „külső” entitások, amelyek szolgáltatásunk nélkül, függetlenül léteznek. Ezért a jövőben egyszerűen úgy fogjuk felfogni őket, mint néhány „valahol” UUID hivatkozást.

Húz diagramok a lehető legegyszerűbbek - A legtöbb ember, akinek megmutatja őket, nem jártas az UML/IDEF olvasásában. De mindenképpen rajzolj.

3. lépés: A táblázat szerkezetének felvázolása

A tábla- és mezőnevekrőlA mezők és táblák „orosz” elnevezései másként kezelhetők, de ez ízlés dolga. Mert a itt a Tensornál nincsenek külföldi fejlesztők, és a PostgreSQL lehetővé teszi, hogy még hieroglifákkal is adjunk neveket, ha idézőjelek közé zárva, akkor inkább egyértelműen és egyértelműen nevezzük el az objektumokat, hogy ne legyenek eltérések.
Mivel sokan egyszerre írnak nekünk üzenetet, néhányan akár ezt is megtehetik offline módban, akkor a legegyszerűbb lehetőség UUID-ket használjon azonosítóként nem csak a külső entitások, hanem a szolgáltatásunkon belüli összes objektum számára is. Sőt, akár kliens oldalon is előállíthatók - ez segít abban, hogy támogassuk az üzenetküldést, ha az adatbázis átmenetileg nem elérhető, és az ütközés valószínűsége rendkívül alacsony.

Az adatbázisunkban lévő vázlattábla szerkezete így fog kinézni:
Táblázatok : 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
);

Táblázatok: 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
);

A formátum leírásánál a legegyszerűbb, ha elkezdjük a kapcsolódási gráf „letekerését”. nem hivatkozott táblázatokból magukat senkinek.

4. lépés: Ismerje meg a nem nyilvánvaló igényeket

Ennyi, megterveztünk egy adatbázist, amibe tökéletesen írhatsz ill valahogy olvas.

Helyezzük magunkat szolgáltatásunk igénybevevőjének helyébe – mit akarunk kezdeni vele?

  • Utolsó üzenetek
    Ezt időrendi sorrendben a „saját” üzenetek nyilvántartása különféle kritériumok alapján. Hol én vagyok az egyik címzett, hol én vagyok a szerző, hol írtak nekem és nem válaszoltam, hol nem válaszoltak, ...
  • A levelezés résztvevői
    Egyáltalán ki vesz részt ebben a hosszú-hosszú csevegésben?

Szerkezetünk lehetővé teszi mindkét probléma „általánosságban” megoldását, de nem gyorsan. A probléma az első feladaton belüli rendezésnél van nem lehet indexet létrehozni, amely minden résztvevő számára megfelelő (és az összes rekordot ki kell bontania), és a második megoldásához szükséges az összes üzenet kibontása ebben a témában.

A nem szándékolt felhasználói feladatok félkövérek lehetnek kereszt a termelékenységre.

5. lépés: Intelligens denormalizálás

Mindkét problémánkat további táblázatok oldják meg, amelyekben meg fogjuk tenni megkettőzi az adatok egy részét, szükséges, hogy a feladatainknak megfelelő indexeket alakítsunk ki rajtuk.
Messenger adatbázis (1. rész): az alap keretrendszer tervezése

Táblázatok : RU

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

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

Táblázatok: 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)
);

Itt két tipikus megközelítést alkalmaztunk a segédtáblázatok létrehozásakor:

  • Rekordok szorzása
    Egy kezdeti üzenetrekord használatával több követő rekordot hozunk létre különböző típusú nyilvántartásokban a különböző tulajdonosok számára - mind a küldő, mind a címzett számára. De most mindegyik regiszter az indexre esik - elvégre tipikus esetben csak az első oldalt akarjuk látni.
  • Egyedi rekordok
    Minden alkalommal, amikor üzenetet küld egy adott témán belül, elegendő ellenőrizni, hogy létezik-e már ilyen bejegyzés. Ha nem, adja hozzá a „szótárunkhoz”.

A cikk következő részében erről fogunk beszélni particionálás megvalósítása adatbázisunk szerkezetébe.

Forrás: will.com

Hozzászólás