Cronfa ddata Messenger (rhan 1): dylunio'r fframwaith sylfaen

Sut gallwch chi drosi gofynion busnes yn strwythurau data penodol gan ddefnyddio'r enghraifft o ddylunio cronfa ddata negeswyr o'r dechrau.

• Rhan 1: dylunio'r ffrâm sylfaen
• Rhan 2: adranu “er elw”

Ni fydd ein sylfaen mor fawr a gwasgaredig, fel VKontakte neu Badoo, ond “fel y bu”, ond roedd yn dda - swyddogaethol, cyflym a ffitio ar un gweinydd PostgreSQL - fel y gallwch chi ddefnyddio enghraifft ar wahân o'r gwasanaeth rhywle ar yr ochr, er enghraifft.

Felly, ni fyddwn yn cyffwrdd â materion rhannu, dyblygu a systemau geo-ddosbarthu, ond byddwn yn canolbwyntio ar atebion cylched y tu mewn i'r gronfa ddata.

Cam 1: Rhai manylion busnes

Ni fyddwn yn dylunio ein negeseuon yn haniaethol, ond byddwn yn eu hintegreiddio i'r amgylchedd rhwydwaith cymdeithasol corfforaethol. Hynny yw, nid yw ein pobl yn “gohebu yn unig,” ond yn cyfathrebu â'i gilydd yng nghyd-destun datrys rhai problemau busnes.

A beth yw tasgau busnes?... Edrychwn ar enghraifft Vasily, pennaeth yr adran ddatblygu.

• “Nikolai, ar gyfer y dasg hon mae angen clwt heddiw!”
  Mae hyn yn golygu y gellir cynnal gohebiaeth yng nghyd-destun rhai dogfen.
• “Kolya, wyt ti’n mynd i Dota heno?”
  Hynny yw, gall hyd yn oed un pâr o gydryngwyr gyfathrebu ar yr un pryd ar wahanol bynciau.
• “Peter, Nikolay, edrychwch yn yr atodiad am y rhestr brisiau ar gyfer y gweinydd newydd.”
  Felly, gall un neges gael nifer o dderbynwyr. Yn yr achos hwn, gall y neges gynnwys Ffeiliau wedi'u hatodi.
• “Semyon, edrychwch hefyd.”
  A dylai fod cyfle i ymgymryd â gohebiaeth sy'n bodoli eisoes gwahodd aelod newydd.

Gadewch i ni aros ar y rhestr hon o anghenion “amlwg” am y tro.

Heb ddeall manylion cymhwysol y broblem a'r cyfyngiadau a roddir iddi, dylunio effeithiol sgema cronfa ddata i'w datrys bron yn amhosibl.

Cam 2: Cylchdaith Rhesymeg Lleiaf

Hyd yn hyn, mae popeth yn gweithio allan yn debyg iawn i ohebiaeth e-bost - offeryn busnes traddodiadol. Ydy, mae llawer o broblemau busnes yn “algorithmig” yn debyg i’w gilydd, felly bydd yr offer ar gyfer eu datrys yn strwythurol debyg.

Gadewch i ni drwsio'r diagram rhesymegol a gafwyd eisoes o berthnasoedd endid. Er mwyn gwneud ein model yn haws ei ddeall, byddwn yn defnyddio'r opsiwn arddangos mwyaf cyntefig modelau ER heb gymhlethdodau nodiannau UML neu IDEF:

Yn ein hesiampl, mae person, dogfen a “chorff” deuaidd y ffeil yn endidau “allanol” sy'n bodoli'n annibynnol heb ein gwasanaeth. Felly, byddwn yn eu gweld yn y dyfodol fel rhai dolenni “rhywle” gan UUID.

Tynnu llun diagramau mor syml â phosibl - nid yw'r rhan fwyaf o'r bobl y byddwch yn dangos iddynt yn arbenigwyr mewn darllen UML/IDEF. Ond byddwch yn siwr i dynnu.

Cam 3: Braslunio strwythur y bwrdd

Ynglŷn ag enwau tablau a chaeauGellir trin enwau “Rwsia” caeau a thablau yn wahanol, ond mater o chwaeth yw hwn. Gan fod y yma yn Tensor nid oes unrhyw ddatblygwyr tramor, ac mae PostgreSQL yn caniatáu inni roi enwau hyd yn oed mewn hieroglyffau, os ydynt wedi'i amgáu mewn dyfyniadau, yna mae'n well gennym enwi gwrthrychau yn ddiamwys ac yn glir fel nad oes unrhyw anghysondebau.
Gan fod llawer o bobl yn ysgrifennu negeseuon atom ar unwaith, efallai y bydd rhai ohonynt hyd yn oed yn gwneud hyn all-lein, yna yr opsiwn symlaf yw defnyddio UUIDs fel dynodwyr nid yn unig ar gyfer endidau allanol, ond hefyd ar gyfer pob gwrthrych o fewn ein gwasanaeth. Ar ben hynny, gellir eu cynhyrchu hyd yn oed ar ochr y cleient - bydd hyn yn ein helpu i gefnogi anfon negeseuon pan nad yw'r gronfa ddata ar gael dros dro, ac mae'r tebygolrwydd o wrthdrawiad yn hynod o isel.

Bydd y strwythur tabl drafft yn ein cronfa ddata yn edrych fel hyn:
Tablau : 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
);

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

Y peth symlaf wrth ddisgrifio fformat yw dechrau “dad-ddirwyn” y graff cysylltiad o dablau nad oes cyfeiriad atynt eu hunain i neb.

Cam 4: Darganfod anghenion nad ydynt yn amlwg

Dyna ni, rydym wedi dylunio cronfa ddata lle gallwch chi ysgrifennu'n berffaith a rywsut darllen.

Gadewch i ni roi ein hunain yn esgidiau defnyddiwr ein gwasanaeth - beth ydym ni eisiau ei wneud ag ef?

• Negeseuon olaf
  Mae'n wedi'u didoli'n gronolegol cofrestr o negeseuon “fy” yn seiliedig ar feini prawf amrywiol. Lle rydw i'n un o'r derbynwyr, lle fi yw'r awdur, lle maen nhw'n ysgrifennu ataf ac nid oeddwn yn ateb, lle nad oeddent yn fy ateb, ...
• Cyfranogwyr yr ohebiaeth
  Pwy sydd hyd yn oed yn cymryd rhan yn y sgwrs hir, hir hon?

Mae ein strwythur yn caniatáu inni ddatrys y ddwy broblem hyn “yn gyffredinol,” ond nid yn gyflym. Y broblem yw bod ar gyfer didoli o fewn y dasg gyntaf methu creu mynegai, sy'n addas ar gyfer pob un o'r cyfranogwyr (a bydd yn rhaid i chi dynnu'r holl gofnodion), ac i ddatrys yr ail un sydd ei angen arnoch echdynnu pob neges ar y pwnc hwn.

Gall tasgau defnyddiwr anfwriadol fod yn feiddgar croes ar gynhyrchiant.

Cam 5: Denormaleiddio Smart

Bydd ein dwy broblem yn cael eu datrys gan dablau ychwanegol y byddwn yn eu cynnwys dyblygu rhan o'r data, angenrheidiol i ffurfio arnynt indecsau addas i'n gorchwylion.


Tablau : RU

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

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

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

Yma rydym wedi defnyddio dau ddull nodweddiadol a ddefnyddir wrth greu tablau ategol:

• Lluosi cofnodion
  Gan ddefnyddio un cofnod neges gychwynnol, rydym yn creu sawl cofnod dilynol mewn gwahanol fathau o gofrestrau ar gyfer perchnogion gwahanol - ar gyfer yr anfonwr ac ar gyfer y derbynnydd. Ond mae pob un o'r cofrestrau bellach yn disgyn ar y mynegai - wedi'r cyfan, mewn achos nodweddiadol, byddwn am weld y dudalen gyntaf yn unig.
• Cofnodion unigryw
  Bob tro y byddwch yn anfon neges o fewn pwnc penodol, mae'n ddigon i wirio a yw cofnod o'r fath yn bodoli eisoes. Os na, ychwanegwch ef at ein “geiriadur”.

Yn y rhan nesaf o'r erthygl byddwn yn siarad am gweithredu rhaniad i mewn i strwythur ein cronfa ddata.

Ffynhonnell: hab.com