Messenger-tietokanta (osa 1): peruskehyksen suunnittelu

Kuinka voit muuntaa liiketoiminnan vaatimukset tietyiksi tietorakenteiksi käyttämällä esimerkkiä messenger-tietokannan suunnittelusta tyhjästä.

• Osa 1: pohjarungon suunnittelu
• Osa 2: osiointi "voittoa varten"

Perustamme ei ole yhtä suuri ja hajautunut, kuten VKontakte tai Badoo, mutta "niin että oli", mutta se oli hyvä - toimiva, nopea ja mahtuu yhdelle palvelimelle PostgreSQL - jotta voit ottaa käyttöön erillisen palvelun esiintymän esimerkiksi jonnekin sivuun.

Siksi emme käsittele sharing-, replikointi- ja geo-hajautettuja järjestelmiä koskevia kysymyksiä, vaan keskitymme tietokannan sisällä oleviin piiriratkaisuihin.

Vaihe 1: Yrityksen yksityiskohtia

Emme suunnittele viestintäämme abstraktisti, vaan integroimme sen ympäristöön yrityksen sosiaalinen verkosto. Toisin sanoen ihmiset eivät "vain kirjeenvaihtaja", vaan kommunikoivat keskenään tiettyjen liiketoimintaongelmien ratkaisemisen yhteydessä.

Ja mitkä ovat yrityksen tehtävät?... Katsotaanpa kehitysosaston johtajan Vasilyn esimerkkiä.

• "Nikolai, tähän tehtävään tarvitsemme paikan tänään!"
  Tämä tarkoittaa, että kirjeenvaihtoa voidaan käydä joidenkin yhteydessä asiakirja.
• "Kolya, oletko menossa Dotaan tänä iltana?"
  Eli jopa yksi keskustelukumppanipari voi kommunikoida samanaikaisesti eri aiheista.
• "Peter, Nikolay, katso liitteestä uuden palvelimen hinnasto."
  Joten yksi viesti voi olla useita vastaanottajia. Tässä tapauksessa viesti voi sisältää Liitetyt tiedostot.
• "Semyon, katso sinäkin."
  Ja pitäisi olla mahdollisuus osallistua olemassa olevaan kirjeenvaihtoon kutsu uusi jäsen.

Pysähdytään nyt tähän "ilmeisten" tarpeiden luetteloon.

Suunnittele ymmärtämättä ongelman sovellettavia erityispiirteitä ja sille annettuja rajoituksia tehokas tietokantakaavion ratkaiseminen on lähes mahdotonta.

Vaihe 2: Minimaalinen logiikkapiiri

Toistaiseksi kaikki toimii hyvin samalla tavalla kuin sähköpostin kirjeenvaihto - perinteinen yritystyökalu. Kyllä, "algoritmisesti" monet liiketoimintaongelmat ovat samankaltaisia ​​toistensa kanssa, joten työkalut niiden ratkaisemiseen ovat rakenteellisesti samanlaisia.

Korjataan jo saatu looginen kaavio entiteettien suhteista. Jotta mallimme olisi helpompi ymmärtää, käytämme alkeellisinta näyttövaihtoehtoa ER mallit ilman UML- tai IDEF-merkintöjen komplikaatioita:

Esimerkissämme tiedoston henkilö, asiakirja ja binääri "runko" ovat "ulkoisia" kokonaisuuksia, jotka ovat olemassa itsenäisesti ilman palveluamme. Siksi näemme ne tulevaisuudessa yksinkertaisesti joinakin UUID-linkkeinä "jossain".

Piirrä kaaviot mahdollisimman yksinkertaisia - Suurin osa ihmisistä, joille näytät ne, eivät ole asiantuntijoita lukemaan UML/IDEF. Mutta muista piirtää.

Vaihe 3: Taulukon rakenteen luonnos

Tietoja taulukoiden ja kenttien nimistäKenttien ja taulukoiden "venäläisiä" nimiä voidaan käsitellä eri tavalla, mutta tämä on makuasia. Koska täällä Tensorissa ei ole ulkomaisia ​​kehittäjiä, ja PostgreSQL antaa meille mahdollisuuden antaa nimiä jopa hieroglyfeinä, jos ne lainausmerkkien sisällä, niin haluamme nimetä objektit yksiselitteisesti ja selkeästi, jotta eroja ei ole.
Koska monet ihmiset kirjoittavat meille viestejä kerralla, jotkut heistä voivat jopa tehdä tämän offline-tilassa, niin yksinkertaisin vaihtoehto on käyttää UUID-tunnisteita ei vain ulkoisille kokonaisuuksille, vaan myös kaikille palvelumme sisällä oleville kohteille. Lisäksi ne voidaan luoda jopa asiakaspuolella - tämä auttaa meitä tukemaan viestien lähettämistä, kun tietokanta ei ole tilapäisesti käytettävissä ja törmäyksen todennäköisyys on erittäin pieni.

Tietokannassamme oleva luonnostaulukkorakenne näyttää tältä:
Taulukot : 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
);

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

Yksinkertaisin asia muotoa kuvattaessa on aloittaa yhteyskaavion "purkaminen". taulukoista, joihin ei ole viitattu itseään kenellekään.

Vaihe 4: Selvitä epäselvät tarpeet

Siinä kaikki, olemme suunnitelleet tietokannan, johon voit kirjoittaa täydellisesti ja jotenkin lukea.

Asetutaanpa itsemme palvelumme käyttäjän kenkiin - mitä haluamme tehdä sillä?

• Viimeiset viestit
  Se kronologisesti lajiteltuna "minun" viestien rekisteri, joka perustuu eri kriteereihin. Missä olen yksi vastaanottajista, missä olen kirjoittaja, missä he kirjoittivat minulle ja minä en vastannut, missä he eivät vastanneet minulle, ...
• Kirjeenvaihdon osallistujat
  Kuka edes osallistuu tähän pitkään, pitkään keskusteluun?

Rakenteemme avulla voimme ratkaista molemmat ongelmat "yleisesti", mutta ei nopeasti. Ongelmana on ensimmäisen tehtävän lajittelu indeksiä ei voi luoda, joka sopii jokaiselle osallistujalle (ja sinun on purettava kaikki tietueet) ja ratkaistaksesi toisen tarvitsemasi purkaa kaikki viestit tässä aiheessa.

Käyttäjän tahattomat tehtävät voivat olla lihavoituja ristiin tuottavuuden kanssa.

Vaihe 5: Älykäs denormalisointi

Molemmat ongelmamme ratkaistaan ​​lisätaulukoilla, joissa teemme kopioida osa tiedoista, joita tarvitaan tehtäviimme sopivien indeksien muodostamiseen.


Taulukot : RU

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

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

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

Tässä olemme soveltaneet kahta tyypillistä lähestymistapaa, joita käytetään aputaulukoiden luomisessa:

• Tietueiden kertominen
  Yhdellä aloitusviestitietueella luomme useita seurantatietueita erityyppisiin rekistereihin eri omistajille - sekä lähettäjälle että vastaanottajalle. Mutta jokainen rekistereistä kuuluu nyt hakemistoon - loppujen lopuksi tyypillisessä tapauksessa haluamme nähdä vain ensimmäisen sivun.
• Ainutlaatuisia ennätyksiä
  Joka kerta kun lähetät viestin tietyn aiheen sisällä, riittää tarkistaa, onko tällainen merkintä jo olemassa. Jos ei, lisää se "sanakirjaamme".

Artikkelin seuraavassa osassa puhumme siitä osioinnin toteutus tietokantarakenteeseen.

Lähde: will.com