Hifadhidata ya Mjumbe (sehemu ya 1): kubuni mfumo msingi

Jinsi unavyoweza kutafsiri mahitaji ya biashara katika miundo mahususi ya data kwa kutumia mfano wa kubuni hifadhidata ya wajumbe kutoka mwanzo.

• Sehemu ya 1: kubuni sura ya msingi
• Sehemu ya 2: sehemu "kwa faida"

Msingi wetu hautakuwa mkubwa na kusambazwa, kama VKontakte au Badoo, lakini "hivyo kwamba ilikuwa", lakini ilikuwa nzuri - kazi, haraka na inafaa kwenye seva moja PostgreSQL - ili uweze kupeleka mfano tofauti wa huduma mahali fulani upande, kwa mfano.

Kwa hivyo, hatutagusa masuala ya mifumo ya kugawanyika, urudufishaji na usambazaji wa kijiografia, lakini tutazingatia suluhu za saketi ndani ya hifadhidata.

Hatua ya 1: Baadhi ya maelezo mahususi ya biashara

Hatutatuni ujumbe wetu kidhahiri, lakini tutauunganisha kwenye mazingira mtandao wa kijamii wa kampuni. Hiyo ni, watu wetu "hawalingani tu," lakini wanawasiliana katika muktadha wa kutatua shida fulani za biashara.

Na ni kazi gani za biashara? .. Hebu tuangalie mfano wa Vasily, mkuu wa idara ya maendeleo.

• "Nikolai, kwa kazi hii tunahitaji kiraka leo!"
  Hii ina maana kwamba mawasiliano yanaweza kufanywa katika muktadha wa baadhi hati.
• "Kolya, unaenda Dota jioni hii?"
  Hiyo ni, hata jozi moja ya interlocutors inaweza kuwasiliana wakati huo huo juu ya mada mbalimbali.
• "Peter, Nikolay, angalia kwenye kiambatisho cha orodha ya bei ya seva mpya."
  Kwa hivyo, ujumbe mmoja unaweza kuwa wapokeaji kadhaa. Katika kesi hii, ujumbe unaweza kuwa na Faili zilizoambatishwa.
• "Semyon, angalia pia."
  Na kuwe na fursa ya kuingia katika mawasiliano yaliyopo mwalike mwanachama mpya.

Wacha tukae kwenye orodha hii ya mahitaji "dhahiri" kwa sasa.

Bila kuelewa uainishaji uliotumika wa shida na mapungufu uliyopewa, tengeneza ufanisi schema ya hifadhidata ya kutatua ni karibu haiwezekani.

Hatua ya 2: Mzunguko Ndogo wa Mantiki

Kufikia sasa, kila kitu kinafanya kazi sawa na mawasiliano ya barua pepe - zana ya kawaida ya biashara. Ndio, "algorithmically" shida nyingi za biashara ni sawa kwa kila mmoja, kwa hivyo zana za kuzitatua zitakuwa sawa kimuundo.

Wacha turekebishe mchoro wa kimantiki uliopatikana tayari wa uhusiano wa chombo. Ili kurahisisha kielelezo chetu kueleweka, tutatumia chaguo la awali zaidi la kuonyesha Mifano ya ER bila matatizo ya nukuu za UML au IDEF:

Katika mfano wetu, mtu, hati na "mwili" wa jozi wa faili ni huluki za "nje" ambazo zipo kwa kujitegemea bila huduma yetu. Kwa hivyo, tutaziona kwa urahisi katika siku zijazo kama viungo vingine "mahali fulani" na UUID.

Chora michoro rahisi iwezekanavyo - watu wengi utakaowaonyesha si wataalamu wa kusoma UML/IDEF. Lakini hakikisha kuchora.

Hatua ya 3: Kuchora muundo wa meza

Kuhusu meza na majina ya uwanjaMajina ya "Kirusi" ya mashamba na meza yanaweza kutibiwa tofauti, lakini hii ni suala la ladha. Kwa sababu ya hapa Tensor hakuna watengenezaji wa kigeni, na PostgreSQL inaruhusu sisi kutoa majina hata katika hieroglyphs, kama wao iliyoambatanishwa katika nukuu, basi tunapendelea kutaja vitu bila utata na kwa uwazi ili kusiwe na tofauti.
Kwa kuwa watu wengi hutuandikia ujumbe mara moja, baadhi yao wanaweza hata kufanya hivi nje ya mtandao, basi chaguo rahisi zaidi ni tumia UUID kama vitambulisho sio tu kwa vyombo vya nje, lakini pia kwa vitu vyote ndani ya huduma yetu. Zaidi ya hayo, zinaweza kuzalishwa hata kwa upande wa mteja - hii itatusaidia kusaidia kutuma ujumbe wakati hifadhidata haipatikani kwa muda, na uwezekano wa mgongano ni mdogo sana.

Muundo wa jedwali la rasimu katika hifadhidata yetu utaonekana kama hii:
Jedwali: 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
);

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

Jambo rahisi zaidi wakati wa kuelezea umbizo ni kuanza "kufungua" grafu ya uunganisho kutoka kwa meza ambazo hazijarejelewa wenyewe kwa mtu yeyote.

Hatua ya 4: Tafuta mahitaji yasiyo dhahiri

Hiyo ndiyo yote, tumeunda hifadhidata ambayo unaweza kuandika kikamilifu na kwa njia fulani soma.

Hebu tujiweke katika viatu vya mtumiaji wa huduma yetu - tunataka kufanya nini nayo?

• Ujumbe wa mwisho
  Ni kupangwa kwa mpangilio sajili ya ujumbe "wangu" kulingana na vigezo mbalimbali. Ambapo mimi ni mmoja wa wapokeaji, ambapo mimi ndiye mwandishi, ambapo waliniandikia na sikujibu, ambapo hawakunijibu, ...
• Washiriki wa mawasiliano
  Nani hata anashiriki katika soga hii ndefu na ndefu?

Muundo wetu unatuwezesha kutatua matatizo haya yote "kwa ujumla," lakini si haraka. Shida ni kwamba kwa kupanga ndani ya kazi ya kwanza haiwezi kuunda index, yanafaa kwa kila mmoja wa washiriki (na itabidi utoe rekodi zote), na kutatua ya pili unayohitaji. toa ujumbe wote juu ya mada hii.

Kazi zisizotarajiwa za mtumiaji zinaweza kuweka ujasiri msalaba juu ya tija.

Hatua ya 5: Smart Denormalization

Shida zetu zote mbili zitatatuliwa na meza za ziada ambazo tutatatua nakala ya sehemu ya data, muhimu kuunda juu yao fahirisi zinazofaa kwa kazi zetu.


Jedwali: RU

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

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

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

Hapa tumetumia njia mbili za kawaida zinazotumiwa wakati wa kuunda meza za msaidizi:

• Kuzidisha rekodi
  Kwa kutumia rekodi moja ya awali ya ujumbe, tunaunda rekodi kadhaa za ufuatiliaji katika aina tofauti za rejista kwa wamiliki tofauti - kwa mtumaji na kwa mpokeaji. Lakini kila moja ya rejista sasa iko kwenye index - baada ya yote, katika hali ya kawaida, tutataka kuona ukurasa wa kwanza tu.
• Rekodi za kipekee
  Kila wakati unapotuma ujumbe ndani ya mada maalum, inatosha kuangalia kama ingizo kama hilo tayari lipo. Ikiwa sivyo, ongeza kwenye "kamusi" yetu.

Katika sehemu inayofuata ya makala tutazungumzia utekelezaji wa kugawa katika muundo wa hifadhidata yetu.

Chanzo: mapenzi.com